KaeseEs

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).

Are there any articles out there detailing this? I've never heard this part of either story.

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.

[1]http://research.swtch.com/generic

> 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.

Organometallic reagents like dimethyl mercury have their own entry in the same series of blog posts as the OP, cf. http://pipeline.corante.com/archives/2009/10/23/things_i_won...

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.

Link: http://www.youtube.com/watch?v=NP9AIUT9nos

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!

Yes, hate the player.

Unethical behavior does not become fine because it is popular.

Stop norming abuse.

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.

Harvard is not going to bake ethics or morals into students during their time there, try or not.

Additionally, your blithe assertion that "but everyone was doing it!" is a valid defense is... unsettling.

The graph shows a 1000-ish percent increase in tuition since 1978, the 439% number later on the page is the cost (not tuition) increase since 1982. Measuring different things from different starting points.

This is entirely wrong. North Carolina and later Pennsylvania were nailed years ago for similarly unconstitutional schemes favoring in-state companies and had to similarly solve them with retroactive taxes on their own citizens. The only options acceptable to the feds when a state is found to have systematically screwed over the citizens of the other 49 states like this are retroactive correction in one direction or the other - there is no option to stop doing it now and keep the ill-gotten gains from the past.

That's a difference of $450, not $4,500.

I'm quite surprised that idTech4 was using _any_ malloc implementation aside from the initial allocation of the memory pool that it would use for its actual runtime allocator.

Another negative trend that's clearly happened in this thread is drive-by voting: all of your interlocutor's posts have negative points, whereas the only posts in the thread that deserved any downvotes were the initial post (the only legitimate instance of the poorly-named 'middlebrow dismissal' that I can see) and the one where you put words in his mouth at the end ("Oh, so they're liars now?"). Postulate: very few people read anything but the first post and its reply, and upon doing so most upvoted all of your posts in the thread and downvoted all of your interlocutor's. Intelligent discussion indeed.

Here's where the analogy falls apart - civil engineering does not provide for coordinated efforts among thousands of construction workers. Construction management does. Any large building project will involve a civil or structural engineering firm, which designs the building or structure, and a construction firm, which builds it.

The construction firm is your compiler toolchain. The benchmark to meet is how long it took to design the Empire State Building, not how long it took to put it together.

It is flatly untrue that you cannot use the C++ STL if you don't use exceptions. std::nothrow exists for exactly that reason.

Lisp implementations have had excellent GCs that are broadly better than the JVM for years.