Comment by aftbit | Hacker News Reader

Comment by aftbit | Hacker News Reader

I think this misses a very key point - subject matter. Some languages are well-suited to do particular things and comparatively poorly suited to other tasks.

For example, Erlang is great when you need to do lots of concurrent operations with guarantees about safety and uptime, but not really what I'd write a CSV parsing program or email client in.

C is very easy to link against on almost every platform and language, so basic libraries are often written in C.

Javascript (in the form of nodejs) is great for writing simple web servers because most of its standard library is asynchronous by default. Compare Python (with Tornado or similar) where lots of popular libraries cannot easily be used in an event loop.

I could go on forever, and you might disagree with me about a particular details, but the general point stands. If you took an expert Erlang programmer and gave her a day to write a spreadsheet application, you'd get a worse result than the same day spent by a C# programmer.

I agree. The (fictional?) person asking the questions was asking for universal productivity improvements, and I think we are long past that point. There are essentially no scenarios where programming in assembly is more productive than programming in C, but those kinds of open/shut comparisons don't work well for the long-tail environment that we live in now. People are building new languages to solve specific types of problems better.

I would add SQL to your examples of subject specific languages. Great language in a very specific application that lots of developers know and are familiar with but would never write a web server with it even though it is arguably turning complete[1]. In my experience using SQL as an example also sidesteps a few flame wars around languages that are nearer and dearer to people's hearts.

[1] http://stackoverflow.com/questions/900055/is-sql-or-even-tsq...

Yeah, the effect of libraries is huge and ignored by this analysis. There's a good reason we see so many web apps written in ruby/python/node and so few in C++.

Very much agreed. Beyond that there is the tooling around a language (besides just the compiler): debuggers, IDEs, static analysis, memory analyzers, decompilers, performance analyzers, etc. Each of these help during specific parts of a programmer's job. The article focused on the language + compiler, but much of the infrastructure around a language is hugely important in how much time different parts of the job take.

Also C++ still has atrocious cycle time with medium to large projects.

If you look at feedback times, PHP is the new Smalltalk. (Yuck.)

https://root.cern.ch/cling

also related to that is the community. not saying it is or is not, but maybe C++ is wonderful for machine learning, but so much of the community is doing it in python and R. i'm probably not likely to find help when stuck writing a histogram kernel in c++ on SO for example

People say this a lot, but I can't think of many projects that fit nicely into a single language. Most projects have certain pieces that are well suited for one language or another - so the game is usually finding which language best fits most of your project (or the trickiest part of it), which tends to be a pure guessing game.

At the end of the day you're probably best off using whichever language you know most, unless you're doing it for learning purposes, or it's one of those rare ones where it really does fit into a specific language.

It's not uncommon to mix multiple languages in a single project. Actually, I see a lot of people use c or c++ alongside Lua (by embedding the interpreter) - especially in videogames.

The other option is to split the project into multiple services. Implement the backend service in e.g. c, and then do the front-end/GUI in, say, Python. This model is seen a lot with things like media players (e.g. mpd).

If that Erlang developer knew Elixir, and threw together a simple Phoenix web app which pulled the optional Node.js/npm dependencies, you could definitely throw together a spreadsheet in a few hours, with added uptime/reliability guarantees.

That being said, your overall point certainly stands. I wouldn't write an OS in Fortran, or a game in Ruby, etc.

A better example would be to compare the Erlang programmer, the C programmer, and a good SQL DBA. CSV/spreadsheets is a poor example (least of all because I think you're wrong, but that's neither here nor there).

DSLs can give you tremendous amplification when you play to their strengths.

In other words, the future isn't 10,000 languages all equally good, but 10,000 languages suited for 10,000 problems that will reduce the comparable workload by 1/2 or more, depending on the case. That's a much more interesting conclusion to the article...

Domain-specific languages were around for decades. You have SQL for databases, bash or zsh or powershell for interactive work, R, or Julia, or Mathematica for math-heavy work, etc. General-purpose languages of course can be used in these areas, but usually only in a more cumbersome way.

Why did you assume an expert Erlang programmer to be a female?

Edit: I always use "he/she" or "her/him"

https://en.wikipedia.org/wiki/Generic_antecedent#Approaches_...

It's just an alternative to using "he" (or "they", which still feels a bit awkward) to describe a hypothetical person. Either flip a coin to choose their gender, or always use "she" to counter-balance (a little) all the times writers default to "he".

I know two people who present a non-sex-specific identity to the world, and both have a preference for being called "they". Most friends and family respect that preference. Even those who find a non-binary construction of gender a challenging concept, "they" isn't proving awkward (just hard to remember sometimes).

I do think "they" will prevail, certainly more easily than than xe or thon or other invented options. So I actually use it, though there's still a part of my brain that flashes a red light each time, and I have to consciously ignore that.

I do think using "she" as the hypothetical example for roles people think of as male is still useful; it hopefully makes people question their knee-jerk response a bit.

As the wiki said that usage of they has been around since the time of Shakespeare so it's not super modern, just coming back.

Using the names and pronouns with someone that they prefer is the polite thing to do, even if you don't "get" it. :)

Reply on news.ycombinator.com