There are many, many people who use C and rarely or never use C++. Most embedded work is done in C, the Linux and BSD kernels are in C, etc. There are a variety of reasons for this, with audit-ability and debug-ability being two big ones. Code space is also a reason, although there are ways to make C++ mostly behave the way you want it to on all but the teensy tiniest platforms (although the resulting code is sometimes a questionable upgrade over just writing the thing in C). A great number of language interpreters are also written in C rather than C++ (cpython being one of them) - easier bindings are one reason for this.
As another datum, where I went to school the intro to CS data structures and algorithms courses were taught in C++ and the operating systems course was taught in C. In my day to day work I use C and a tiny bit of assembly (more reading than writing).
I don't know any data scientists, or even what one is really, but here's the EE explanation: the Fourier transform maps a signal in the time domain to the frequency domain, and vice versa. So if you have a sine wave in the time domain [say something at 3khz: y = sin(3000x)], the Fourier transform would turn that into a pair of Dirac deltas (spikes that are infinitely thin but have an area of one) at omega = +-3000. Or, if you had a pulse, the Fourier transform would map that to a sinc [sinc(x) = sin(x)/x].
The Fourier transform is related to the Laplace transform, which maps signals in the time domain to those in the "S domain", a domain where locations are normally described with complex coordinates which contains information both on frequency of the periodic components of the signal as well as any transients (starting conditions, in layman's terms).
Great analysis, although I'm curious how the idea that doing a bunch of 64 bit ops in order to accomplish byte arithmetic came about to begin with - was the function in question not written by a firmware guy?
"Being professional" is not about all agreeing to the same ideology, but consistent standards of behavior are the core of professionalism. If we cannot agree that screaming "SHUT THE FUCK UP!" and calling people brain-damaged and "worthless piece[s] of shit" (as Linus has done elsewhere; the specific example in the OP isn't as bad) is inconsonant with professionalism, the concept has lost all meaning. There are ways to express disagreement or that someone's actions are wrong without namecalling, screaming, profanity (which is not always problematic in many environments, but can get off the rails) or dressing them down publicly.
Linus isn't a drill sergeant and his poor imitation thereof when he power trips doesn't get his point across any better than just saying "X was a bad decision, don't do it again for reasons Y and Z".
On the one hand, OCaml is a very interesting language and I welcome a good book about it in the vein of Real World Haskell. On the other hand, it is the height of treason for O'Reilly to make a book with a camel on the cover that isn't about Perl :v
I don't think that's an entirely fair take on the situation. There was a great series of comments on Russ Cox's blog in late 2009[1] by longtime Boost contributor and general brainiac Rivorous about the benefits of generic programming a la Stepanov and pervasive value semantics, which were noted but not engaged in any meaningful way.
> I mean when you get a rate that high, it seems like it must be just a relatively heavy element, and a metal, like Gold, and relatively unreactive (just carrying ions and such).
This is the opposite of the truth. Lithium is not dense at all (~.53g/cm^3), especially for a metal, and as a Group 1 metal is extroardinarily reactive - if you cut lithium it will oxidize as you watch, and if you expose it to water is will explode into flaming chunks.
> I imagine they don't get to 100% because they just don't bother to heat it high enough to melt things in there with a ridiculously high melting point and risk creative copper fumes and whatnot (from some metals evaporating). i.e. it's still easy, they just don't want to.
No. Lithium has a very low melting point (roughly 180C/355F).
Furthermore, your contention that a process with an efficiency of 93% should be easy to bring to 100% is so off base I don't even know where to begin. Squeezing out the last few percentage points is the hardest part!
It would be easier (for me at least, but I suspect others as well) to take Bitcoins seriously if the backbone of the Bitcoin economy weren't the Magic The Gathering Online Exchange, which apparently is crippled by loads of less than 40 transactions/sec.
Real Software Engineering, by Glenn Vandenburg. Not a perfect talk (especially the conclusions IMO), but a very good exploration of how some of the common beliefs in the field of software "engineering" came to be, and how something resembling actual engineering practice might be beneficial and practical.
Abstract: "Software engineering as it's taught in universities simply doesn't work. It doesn't produce software systems of high quality, and it doesn't produce them for low cost. Sometimes, even when practiced rigorously, it doesn't produce systems at all.
That's odd, because in every other field, the term "engineering" is reserved for methods that work.
What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this session, we'll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being "anti-engineering" (as they are often described), actually represent the best of engineering principles applied to the task of software development."
The 10x figure is pseudoknowledge - something we "all know" that isn't actually true (or that at least we have no good reason to believe to be true), cf. http://vimeo.com/9270320 . In brief: the study that it is ultimately derived from had a tiny sample size (on the order of 30, to wit), and for several reasons the experimental design would have invalidated its results outside the very narrow original focus of the study (which was the relative productivity of batch processing vs. interactive processing on the computing systems of 1968) even if the sample size had been larger.
I'm interested in what the accuracy, stability and precision of this barometer are. For the use case that they were put into that phone (and the price point it implies), I am unsure whether data reported from these phones will be useful for PressureNet.
Longer explanation: in the parlance used for pressure measurement, a barometer is a low-pressure absolute gauge (although what they pack in the phone is a sensor or transducer rather than a full gauge for obvious reasons). In order to measure absolute pressure, it needs to pack a good source of vacuum to be used as one of the differential inputs. And it needs to do it real small and real cheap. I suspect they're using a piezoresistive or capacitative sensor for this pressure range, which both have a significant tempco, and they almost certainly can't do a valid temp-comp on the part for cost reasons (you can sort of bullshit it by characterizing the lead unit and applying that to everything based on a curve fit, but the results are not great).
Sensors in this form factor and for this price point might be accurate to within +- 2.5%, which is not terribly useful for a barometer for weather purposes.
I hate sites that intercept '/', which I normally use for searching text on a page. If I wanted to use your search function I'd click in the box. I'm looking at you, Gmail and Bitbucket!
This intentional use of the definition of a word from one context in another context is equivocation, a form of dishonesty that it makes little sense to tolerate.
In the domain I work in (firmware for digital instruments and industrial systems), knowing assembly isn't necessary for performance reasons so much as for sanity reasons - a lot of vendor compilers for embedded devices are incredibly flaky, and if you can't inspect the generated assembly you'll never know what the hell is going on in cases where the code doesn't behave the way you expected it to.
Heck, even when I have the privilege to be treading a more well-worn path (eg. ARM/GCC), it's helpful to be able to tell what the compiler is transforming (on a less charitable day I'd say "munging") my code into.
I see that the equity stake that YC gets is variable from 2-10%, presumably based on valuation. I had thought it was a fixed 7% stake; is this new or had I not noticed it before?
This is a slightly worse version of the behavior that prompted JWZ's first rant about bugtrackers in open source software (cf. http://www.jwz.org/doc/cadt.html ).
How do you consider Lebanon to be homogeneous? The religious divide there is so deep and long-standing that it is enshrined in law, with power in the government divided along confessional lines.
As another datum, where I went to school the intro to CS data structures and algorithms courses were taught in C++ and the operating systems course was taught in C. In my day to day work I use C and a tiny bit of assembly (more reading than writing).