Hacker News Reader

"But people in the fields of computer vision, artificial intelligence, machine learning, concurrent data-structures and others – very smart, very forward thinking people – would pick Java or C/C++ nine times out of ten, and not only because these languages are better suited to their task performance-wise, but because they have other, more important things to think about. If your challenge is not translating a business model into code, but solving a real algorithmic or technical problem, then the programming language really doesn't matter, and you're better off sticking with the one(s) you know best."

This is so true. They often use something like MATLAB or R, but that doesn't affect your essential point, which is a great one and worth thinking about. How much of what you encode is original/cutting edge thought vs routine (CRUD apps) say.

That said, that particular blade cuts both ways. There is nothing (other than inertia) stopping the "one(language) you know best" being something reasonably advanced, with decent, if not ubiquitous libraries and tooling, like Scala or Clojure or OCaml, or even Common Lisp. Why would you want to use an 'inferior' language if you know a better one? So in the end this argument may just devolve to "Most engineers in charge of implementing systems are more comfortable with Java/C++ than Clojure/OCaml".

Something of medium complexity, between the basic CRUD web app and pioneering projects like Watson, like the (Twitter)Storm library for e.g ,is much easier to do in Clojure than in Java, though it uses many java libraries (e.g: Apache Zookeeper) under the hood.

So we have $baselang for basic webapps, $coollang for medium complexity efforts, and back to $baselang for truly cutting edge work, where thinking effort outweighs coding effort. An odd dynamic, if true.

" IBM's Watson would not have come about sooner if its engineers had chosen Haskell over Java."

This is a strong claim :-)

Even IBM Watson might be easier in Haskell,(it actually uses Java, with "significant chunks" in C++ and Prolog [1]) but someone actually needs to build something like this first. FP proponents should probably focus on building existence proofs of cool systems than resort to argument (imho).

[1] http://blog.reddit.com/2011/02/ibm-watson-research-team-answ...

I consider MATLAB the thinking, or drawing board stage, to be followed by final implementation in Java or C++.

True, but the complication is that people building the final production system /choosing the implementation language, OS etc (engineers) are not usually the people who use MATLAB or R.(Computer Vision Researchers, say).

There might be a few (rare) people who can do cutting edge research and do production grade engineering, but I'd be surprised if this were the default for the average team member, even for a system like Watson.

That fits my interviewing experience for computer vision. Tons of people that work in MATLAB or OpenCV, throwing it over the wall to 'production'. That's not terribly appealing when you are already limiting what you can do because your CPU/GPU is running at 100%. Not too many that can actually engineer a working, performant solution.

You're fooling yourself if you think it gets that far! The grant runs out and you end up putting the MATLAB version in front-line action, complete with entire pages of code commented out: FIXME.

> Why would you want to use an 'inferior' language if you know a better one?

I really hate this idea because it implies that one language is completely inferior to another in every way. For example, I have heard: "Why use C when you can use C++?" The two languages often serve different purposes. There are few languages that give you as much control over performance and memory management as C. C is lightweight enough to go onto basic 8-bit microcontrollers with 64kb of memory. That is not to say that C is the ultimate language or anything, but that different languages have different strengths/weaknesses. Another simple example would be C# which is great if you have no need to deploy to anything other than windows. In conclusion the answer to your question is that someone had a particular need which was best suited to one language and thus are more comfortable in it which is why they want to use it for their next project.

"Inferior" is probably really bad wording. Let's say "more advanced". If you know C++ you will have no problem accommodating with C if it better fits your need. If you know Scala you can still program in Java if your stuck with it for whatever reason.

> If you know C++ you will have no problem accommodating with C if it better fits your need.

While I understand what you mean, the two are completely different. The lack of OOP in C means that you have to have a different set of programming methodologies to accomplish what you would have done with classes. So, while knowing C++ helps, it isnt the same as if your 'main' language were C.

Furthermore, one of C's strengths is it predictability. The way that is accomplished in C is different than C++.

I write both C and C++ on a regular basis. The set of idioms used in C is radically different from what you'd find in C++ (even though a lot of C code is valid C++). When I first started working on C projects written professionally (after quite a bit of experience with C++), I was seriously thrown off by things like reinterpreting structs to treat the first element as a parent structure (essentially emulating inheritance in pure C code).

"I really hate this idea because it implies that one language is completely inferior to another in every way."

Since I never said or implied that (you did notice the quote marks ?) you must have plucked this idea out of thin air and then went on a rant ;-)

I feel precisely the opposite way. I used to work on developing network algorithms. Our simulations used C++. It was phenomenally unproductive, because in addition to the inherent difficulty of the problem, you had to deal with the limitations of the language. Its a pain to debug C++ in a straightforward "move bits around" app. Its even more painful to get distracted by stack smashing bugs when you're trying to figure out the emergent behavior of a complex algorithm.

Which language would you have preferred? Most other languages where such bugs would be handleded by the language tend to be a lot slower. (I'm saying that as a Perl developer who occasionally has to write C because Perl won't cut it for a decent algorithm.)

There are a host of languages > 20% as fast as C (Common Lisp, Haskell, Java). I would have preferred Common Lisp but would have settled for Java. Once you're within a factor of 2-3 of C, speed rapidly becomes less important than other things except in limited circumstances. I wouldn't write an h264 decoder in Lisp, but short of that...

Ah, thanks for the answer. I was mostly curious since i work with things where algorithms need to perform in realtime, so even a factor of 2-3 is unacceptable.

Neither my intuition nor experience lead me to the same conclusion as you.

My intuition says that complex algorithms get even more advantage from more expressive languages. Java and C++ are usually not counted among the more expressive languages.

My experience on two* different projects in very complex domains...one where we used Java and another Clojure was that the Clojure code was more approachable and modeled the domain in an easier to understand way.

Just my 2 cents.

* One project was in the field of power systems, modeling and predicting power flow through the distribution end a power network.

* The other project was doing personalized treatment recommendations based on analysis of genetic data.

Yes the Lisp > Blub argument is usually presented with the assumption that the opposing argument is that Blub > Lisp or at least that Blub = Lisp. In fact the argument is actually that Blub provides access to a vast ecosystem of algorithms written by world class programmers, each specialized in their particular domain, and therefore it's actually mathematics and algorithms (via Blub) > Lisp and self-implementation of those algorithms; or you could restate that as the efforts of scores of world class programmers > than my own efforts. Perhaps Clojure settles that gap by linking a Lisp to the JVM ecosystem, but historically that wasn't the case in these arguments.

Might I add that a good tool, a good programming language, let's you think about other things than implementation detail. It let's you express things in a more direct and concise manner.

Very smart, very forward thinking people might choose Java or C/C++ because they don't want the extra effort of learning/using a new programming language. But it certainly doesn't mean it's the better choice. Lisp was for example developed explicitly for the use in artificial intelligence by John McCarthy, a very forward thinking and smart person who greatly advanced the field of AI.

I would say that when your problem is a one-of-a-kind, you'd rather think about the problem at hand and think of the implementation as little as possible.

> But it certainly doesn't mean it's the better choice.

If picking something else had the same cost, then you're absolutely right. But if implementing the production code is 6 months out of a 5 year project, even a language that is 10x more productive but takes 3 months to be proficient in (let alone to master), then it's just not worth it.

> I would say that when your problem is a one-of-a-kind, you'd rather think about the problem at hand and think of the implementation as little as possible.

Yes, but this line of reasoning may lead to Clojure, for example, in the application case and to, say, Java in the algorithm case. In the latter you play around in MATLAB for a long time; translating it later to Java is often a very technical process.

"But people in the fields of computer vision, artificial intelligence, machine learning, concurrent data-structures and others – very smart, very forward thinking people – would pick Java or C/C++ nine times out of ten"

This may be a reflection of the fact that people who write code, but are not really programmers, lack sufficient domain knowledge (in the field of programming) to choose anything other than the "default" choice. It's harder to go off the beaten path when one knows little about the surroundings. That doesn't mean the path is optimal though.

C++ gives you fine grained control over the machine, which is something these fields often need (I am in the computer vision/AI segment). When you are using Intel Intrinsics, MKL, etc., just to get enough performance to barely do the job, you can't afford to throw that control away to garbage collection, reference counting, and all that. I use higher level languages for the things they are great for - the 'batteries included' features of Python, for example, or the functional+high availability of Erlang. And they are great languages for what they are designed to be used for.

Not every C/C++ programmer (I say with considerable understatement) is an obsolete, corporate hack unaware of the state of the art in computer languages and tools. We wrote your compilers, your languages, your VMs, your toolsets, your OS, your math libraries, your, well, you get the idea :)

Two points:

1) The issue at hand is about the choice between mainstream languages vs. niche languages. Your reply does not address this and sidetracks into a discussion about native languages vs. high-level languages.

2) Even assuming every decision to use C++ was an optimal one, what about the decision to use Java?

This may be a reflection of the fact that people who write code, but are not really programmers, lack sufficient domain knowledge (in the field of programming) to choose anything other than the "default" choice.

While this could sometimes be the case, that's mostly because they have other things to think about. Spending time on choosing and learning new languages (with their libraries and communities) can be rightly considered a manufacturing optimization. That's really important to people whose job it is to manufacture at scale, but not necessarily to those dreaming up new components. These are two different jobs. When you deal with manufacturing, you're expected to spend a lot of energy on picking the absolute best tools. But if you're handcrafting something completely different from most of what's out there, your tools and process don't matter as much. The path doesn't need to be optimal if you're the first to take it to a new destination. If you don't know if you can even get to where you're going – or if there's anything there at all – spending money on the best shoes is a premature and unnecessary optimization.

I think reducing a million lines of code by a factor of two is a huge win. Reducing it by half and having the extra type checking in Haskell would be even better. Heck, I'd also take the super fast complilation in Go with the equivalent million lines. Bottom line is that when you're dealing with that much code, those little wins do add up.

It is usually applications that have so many lines of code. Also, as others have mentioned, availability and quality of existing libraries matters a lot. It is better to link to a 1 MLOC library rather than write and debug 100KLOC yourself. Finally, tools (debuggers, profilers) often matter more than the language.

Also, these wins come at a cost (learning curve, immature implementation), which isn't worth it if more than 90% of your time is spent at the drawing board anyway.

Yes.. It reminds me of a recent interview with matz:

"The ones who do not challenge themselves to create new things are often falling behind - they learn a hip new language today and try a new web framework tomorrow, but still lack the foresight to invent and to improve."

My experiences would tend to agree with you; I worked at The MathWorks (makers of MATLAB) for a while, and I was a little surprised when I noticed that the hard-core devs who developed the guts of the language (parsers, JIT, data structures, math libs) worked purely in C++ often using EMACS or VI, and only rarely would launch a dev MATLAB GUI. I suppose it makes sense that if you're working deep in the internals, all that matters is properly handling all the possible inputs that your function can receive and not really how those inputs get there - that's the job of other teams further up the call chain :) I still found it an interesting lesson.

But people in the fields of computer vision, artificial intelligence, machine learning, concurrent data-structures and others – very smart, very forward thinking people – would pick Java or C/C++ nine times out of ten, and not only because these languages are better suited to their task performance-wise, but because they have other, more important things to think about.

Yes and no. There are a few things to keep in mind.

First, these fields have a lot of finesse for which there's no substitute for years of trial-and-error. What's the right learning rate for a neural network? (There isn't one; real NN implementations have varying strategies for adapting the LR, but even picking the right one of those requires knowledge both of how NNs work, and the data itself, since noisier data means there won't be monotonic learning progress unless one trains over the whole set-- and that's usually impractical.) What this means is that programmers tend to have a longer lifespan and you don't see as much tech churn.

Also, most machine learning programmers use different languages for exploration and production. For the former, Python, R and Matlab seem to be the favorites. For the latter, C and Java are the traditional incumbents, though I could see Scala or Clojure breaking in. Making Clojure performant isn't elegant, but (a) it's not worse than writing Java or C++, and (b) the same is true of Common Lisp. Typically, though, production machine learning doesn't (or shouldn't) have a high LOC-count, especially because most ML projects are there to do things that would sprawl into unmaintainable complexity if done by hand (e.g. speech recognition).

Clojure won't replace C for low-level system programming that requires manual memory management, but even in machine learning, that doesn't apply to most of the work-- remember: half your time will be spend looking for patterns or exploring methods, many of which won't work-- unless you're working at a very large scale. For most of ML, the performance-intensive part is linear algebra, and you usually will end up using wrappers around Lapack (which is in Fortran) for that.

What I would say about the higher end of programming is that engineers care more about "the right tool for the job" and less about "the tool I like best". They're less wedded to one technology stack, so they're willing to use Java if it's the right language for their problem. They're definitely not your typical Java jockeys, though.

ML is a great example since, as you mention your bottlenecks are likely solved by hanging your hat on Lapack and getting out. The complexity of the application derives from data manipulation and feature selection. The first is a definite win for higher-level languages and the second... might be, but is really too large a hodgepodge of techniques to say.

I'm personally beginning to find that Haskell is really nice for this situation because it helps me separate stupid-programming-bugs from improper-algorithm-implementation-bugs very efficiently. This saves a lot of time when I'm looking at the output of a high-dimensional, non-deterministic program and wonder what might have gone wrong.

And I've written some Clojure ML code that was quite close to Java speeds several years ago. For ML, you're either going to get the answer immediately or be waiting a while. As long as your constants for language choice aren't 2x-5x it's not a big deal. When everything is Fortran anyway, the constants aren't 2x-5x.

Machine learning is also, by a big margin, the most common of the areas I've mentioned and is therefore best positioned to benefit from "mass production" efficiency tools. It is moving from the master shop to the factory floor.

I kind of disagree with this. I think there are huge needs for "better language" kinds of improvements with ML that gives insight into how various pieces in a pipeline get combined, how tuning happens, how feature generation relates to input data. I don't consider ML to be terrifically repeatable today due to a lot of non-standard low-level tweaking that goes on at the top levels of work there.

I think it's definitely moving, but I don't think it's nearly as mechanized as, say, AES is, given that the tradeoffs one needs to balance are significantly more complex. You can't just Machine Learn something as much as people may try.

Just a tip - LAPACK and BLAS are available for OpenCL now. No need to link against Fortran, and you get to use the GPU.

http://developer.amd.com/tools-and-sdks/cpu-development/amd-...

That's a great thing to know-- and I wish I could give it 20 upvotes.