Reading code is essential to growth as a programmer. I do it all the time, often for pleasure. But reading snippets without context, like you're suggesting, is a common source of bugs in my experience.
So often when working on a legacy codebase, I'll track down a bug to some bit of code that makes no sense, and then search for that code and find it on Stack Overflow or similar. Even examples from documentation can be dangerous taken out of context; I can think of numerous times I encountered this with snippets that had been copied directly from MSDN without understanding.
Given that poorly-understood code reuse was implicated in many of our industry's greatest disasters, maybe the legality isn't what our concern should be here.
Yep, seems to be pitch class notation with T and E replaced with a and b. People interested in this kind of orthogonality should definitely check out Introduction to Post Tonal Theory by Joseph Straus. Even outside of the serial contexts people traditionally associate with that notation, there are interesting things that can be done with it.
We were able to update the paper on the ACM website: https://dl.acm.org/citation.cfm?id=2837654, although looking at it now, they did not update the title. I'll see if they can fix that.
There is very exciting news coming up with printing floating point. Ulf Adams from Google will be presenting a new algorithm called Ryu that appears to be super fast, simple, and perfectly accurate. Assuming the claims are correct, Ryu ought displace all of the current algorithms.
Thanks! My comment was not meant as a criticism of your work (I still like the paper, and do appreciate that you went to the effort of putting the amended results online), but more of the CS conference publishing model.
I wouldn't scrutinize it too much as the benchmarking approach is wildly inaccurate, but I'm curious about that too. I might investigate it later. (I am the author of the post.) This was also run on a pretty ancient AMD machine, which isn't terribly representative of modern branch prediction hardware.
Well, it's been happening since the '80s when several OSes were written in ostensibly garbage-collected languages. So it might be a little late to complain.
Since the average professional software engineer has more experience than our average subject,
the effect sizes reported may be overstated for some populations
I did this about a year ago after being self-employed for about 6 years. One of the biggest reasons was actually the social aspects of working; I rarely worked with other people, or if I did, not for long.
There are plenty of downsides to going back to being an employee, though. I wouldn't do it if it weren't with the right people. At the time, I took a pay cut to do it, but it worked out and I'm happy with my decision, because I got what I wanted: to work with great people and build relationships with them. And the reduced stress from not having to hustle all the time has been good.
Since you're self-employed, take your time and really find an employer that suits you. You have a lot of leverage in negotiations since you know you don't _need_ any given job you interview for.
I've gone through more than one cycle before of building up a set of clients from scratch, so I know that I can always go back to freelancing if I want to. I wouldn't be too worried about getting stuck as an employee unless you let your skills stagnate.
An underlying point to this article that is still true is that C isn't inherently fast -- you have to work together with the compiler to make sure it generates what you want.
Why is this even worth pointing out? Well, in many languages communities (Common Lisp is a good example), the speed argument comes up, and it's pointed out that carefully working with the compiler (declares in all the right places and so on) makes the implementation competitive, and this is often dismissed as "too much work", ignoring the fact that even in C, there's no free lunch.
When one recognizes that good performance often requires a dialogue with the compiler, one starts to recognize that a criteria for performant language implementations is not "it's just like C" but rather "it's possible to tell the compiler to make this fast".
This makes many alternate languages viable choices for high-performance work (and eliminates some!), at least based on the current state of their implementations.
Imagine if as much work had gone into their compilers as has gone into the production C and Fortran compilers of today.
Except that the default, basic, recommended style for writing in C and writing in some other language X often produces very reasonably fast code in C, and horribly slow code in X. Which was the whole reason people advanced the argument that you need to use contortions to get X to generate code that even approaches the speed of normal, uncontorted C.
Except for the little fact that in the 80's and 90's most hobby coders still managed to write better Assembly than C compilers for home computers were able to generate.
C compilers are fast in modern times, because of the amount of industry money spent in writing C optimizers since the industry adopted it.
I agree, although I think this is mostly cultural.
If we're only talking about single-threaded, CPU-bound code, this is basically true of any imperative language without fancy data structures: even a fairly naive native compiler will produce "pretty fast" code in our modern times where the standard for pretty fast is pretty low.
It seems intuitive that the further a language is from the machine, the harder the compiler has to work to make that language's idiomatic constructs efficient on a machine.
The kicker here is that C is no longer so close to the machine. It's still a PDP-11, and today's machine is not. This idea is what I think is still useful about the original article, for all its other faults.
I admire compilers like MLton that actually deliver on the promise of higher-level languages without the usual performance compromises for abstraction. Hopefully we'll see more of this as time goes on, as well as more languages like Sequoia that are close to the new machine.
I imagine this is why so many game studios choose to use a mix of the two. C or C++ is used to write the engine code, which is kept just as simple as possible and is in charge of doing all the fiddly bits with the hardware. Unless you're on an embedded system with limited resources though (where the size of your code can actually matter) everything else is usually done in some sort of scripting language with its own reasonably fast JIT. This is possibly sub-optimal, but it enables really fast iteration on the parts of the code that need to change and go through rapid test cycles.
Deciding when to spend the energy and resources to optimize that one routine is the result of good benchmarks and code profiling. Identify your bottlenecks, and optimize the hell out of those. For everything else though, you need to ship a product, and the human effort is largely wasted on a less-called routine that makes the character blink every 173rd frame.
Yeah, but there is no "fast JIT" on iOS and PS4 (not sure about X1) at least because they forbid creating memory pages with "Executable" bit, so usually AOT compilation is still ftw in game dev.
So often when working on a legacy codebase, I'll track down a bug to some bit of code that makes no sense, and then search for that code and find it on Stack Overflow or similar. Even examples from documentation can be dangerous taken out of context; I can think of numerous times I encountered this with snippets that had been copied directly from MSDN without understanding.
Given that poorly-understood code reuse was implicated in many of our industry's greatest disasters, maybe the legality isn't what our concern should be here.