5 ms·
Fair point. Actually, you've nailed it. C++, for example, isn't some horrible language without purpose. It has a niche that it fills well (although I'd prefer C
by michaelochurch 15y ago
Fair point. Actually, you've nailed it. C++, for example, isn't some horrible language without purpose. It has a niche that it fills well (although I'd prefer C) but most C++ jobs aren't in that niche.
My experience is that language adjustment is up to a 0.5-point drop (the scale is here: http://michaelochurch.wordpress.com/2012/01/26/the-trajectory-of-a-software-engineer-and-where-it-all-goes-wrong/ http://michaelochurch.wordpress.com/2012/01/26/the-trajector... ) in an engineer's ability. This is on a 3.0 scale where most engineers are between 1.0 and 2.0, so that's a huge change. Compensation tends to be linear in proficiency but exponential in value-add. 0.5 points is about $50,000 in market pay but a 2-4x (depending on the type of company) difference in productivity.
Sometimes it is worth the drop, such as when one's learning a dramatically new and more effective approach, or solving a fresh class of problem (e.g. real-time software, which is done in C). That isn't the case with enterprise, "pattern"-afflicted Java. Instead of solving the problem appropriately and well because I know how to do it, I have solve problems inappropriately and badly because I don't know the crappy idioms that people invented because they don't have appropriate tools.
On that scale above, I put myself around a 1.7. If I set foot in a typical C++ or Java shop, I'd drop to 1.2 or 1.3. Which means I'd risk falling to the level of a junior programmer and being typecast that way. Which means I wouldn't get the benefit of the doubt if I say, "This project wouldn't be complete shit if we'd done it in an FP language" (in some nicer words, of course). Your first 6 months determine whether you have technical credibility or not. If you don't, you can't blame the tools, even if bad tools are (as they often are) the cause of the problem. The unenlightened tend to think of all tools as equally good (all languages are Turing complete). No, not so. A 3x difference in CPU performance may not matter for most problems, but the 3x difference in human performance that hinges on whether one uses the wrong tools certainly does.
The drop to 1.2 is something I'd tolerate if moving to something genuinely interesting, knowing it'd only take a year to pop back up to the same or even higher level. An example might be high-performance C++ in weather forecasting, bioinformatics, or artificial intelligence. I'd gladly become a junior again for a year for that kind of stuff. On the other hand, most enterprise Java/C++ bullshit isn't really worth learning, not for a creature that has 60 years left to live instead of 600,000 (#ShitYouCantSayAtWork).
So yes, my language bigotry is more directed at the typical C++ or Java job than at the language itself.
- tseabrooks 15y agoI don't think I'd take an enterprise job. However, When someone mentions C++ my assumption is we're talking about fairly low level programming. Java though, I tend to think of as being strongly enterprise-y. I assume my reaction to C++ is that way because my C++ experience is entirely in embedded software / consumer electronics (Strongly C-driven but way more C++ than you might imagine).
- jbooth 15y agoI'd suggest that you're being a bit ideologically biased against Java. Ain't no easier language to do concurrent programming, aside from Clojure (jvm), Scala (jvm) and I hear Erlang (don't know much about it). Every serious project in Clojure or Scala that I've seen ignores their concurrency stuff and goes straight to Java. It turns out that if you implement a bunch of Callables and ExecutorServices with LinkedBlockingQueues or SynchronousQueues.. it's basically functional programming. Don't get too hung up on the syntax.
- gtani 15y agoconcurrency stuff You're talking about at least 3 distinct models: direct thread management, with improved locking routines (java.util.concurrent, see recent Prismatic thread on HN), actors/green threads (Akka and erlang BEAM), and STM/guarded read/writes (clojure, and you should read about Microsoft's attempt to graft STM onto C#, Joe Duffy's blog)
- jbooth 15y agojava.util.concurrent's entire point is to make direct thread management unnecessary. Note the list of classes I mentioned didn't include Thread. Actors and STM are great thought experiments but real-world production stuff tends to always circumvent them for the java.util.concurrent stuff.
- dxbydt 15y ago>Actors and STM are great thought experiments but real-world production stuff tends to always circumvent them for the java.util.concurrent stuff. Its a mixed picture, if you want to be honest. There are places like bofa where I've pushed into production a cvar processing module on 500,000 loans which uses only actors. No low level tinkering with util.concurrent, no Threadpool setting, no Executors, no synchronized anywhere in my code. In the past at GS, I wrote concurrent code where I explicitly specified the number of threads & we had a ThreadPool manager & internally it used the util.concurrent classes. At LinkedIn, I believe they started with actors & switched parts of it to Doug Lea's framework ( which was the sort of the foundation of util.concurrent). I have seen financial shops where they do half & half - the quants seem to like actors but the swing programmers like to have control on threadcounts, & they tend to do things like naming threads & creating parent-child relationships so swing can paint reliably & they can debug threads by name when it doesn't. I did the same in the past when most of my work was on the swing side, creating custom blotters to show trade tickets & the like. But now I primarily do quant model building work with actors & no more util.concurrent stuff. If you want to construct a lattice model to price structured options on a 100 different strikes per month for 5 years in advance, you can find no better friend than an actor. Actors are certainly not a thought experiment, very much a reality.