Hacker News new | ask | show | jobs
by norswap 4388 days ago
My take on a few languages you mentioned. I'll try to stay as neutral as possible, but some things are bound to be controversial.

- C#: Microsoft's answer to Java, supposedly does some things better (Java seems to be catching up some), but cross-platform support is so-so.

- Go: I don't understand Go. It seems to be conceived as an improvement over C, and it gets many things right (and a few things wrong, like error handling). Unfortunately, it gets the most important things wrong: performance and low-level access, which are the only reason anyone uses C nowadays. If you don't need C's performance, you get languages that are much nicer and faster than Go (like Java or C#). As a result, it drew Python programmer rather than C programmer, because Go is still faster than Python, and feels quite similar to basic uses of it. Also Go seems to draw people who have drunk too much of the anti-OO kool-aid.

- Swift: A bit too new to tell. Objective-C was a notable improvement on C without incurring the complexity of C++. It suffers of a bit of Go syndrome, but Apple forces you to use it, so there's no debate to be had. Swift is an improvement over Objective-C. It seems to be that this heritage lead to some shoehorning and there are maybe clunky angles to how some things were designed (i.e. the type system).

- C++: many people have said it, C++ is very powerful but it's way too easy to break everything in a subtle manner without realizing it. The problem of C++ is that it has a very large set of core features, which can all interact in ways that are hard-to-predict if one is not a language lawyer. C++ is the opposite of elegance in language design. Despite this, it is used because it is fast and gets stuff done (good expressiveness). And if you run into strange feature interaction, you can always work your way around them by making the design a bit more ugly, thereby avoiding to have to gaze into the pit of hell.

- Rust: very interesting because it promises more safety when doing low-level work, while retaining performance. I'm still waiting for the development dust to settle to give it an in-depth look.

- Smalltalk: the language itself is nice enough, kind of like a Ruby that would have been pushed to the level in terms of meta-programming. The environment, however is awful. The "image" in which you work completely traps you, and has a super poor UX despite the inclusion of very powerful introspection/debugging tools. At any rate, Ruby is mostly good enough, and you rarely need the added meta-stuff from Smalltalk.

- Erlang: genuinely useful for its use case, distributed systems. This is a language where the intended use was really woven in the language design, to great effect. For the rest, it's a bit like ML without types. Personally, I see no good reason for leaving out types, so that tends to annoy me a bit.

- PHP: Many things (mostly bad) have been said about it, and many of them true. However, its success is not undeserved in the sense that it was a very easy language to get started with, from the fact that it could be embedded inside the html directly (allowing for nifty cut-and-pasting) to the availability of easy-to-configure servers. It also has top-notch documentation.

- Common Lisp: The problem of Common Lisp is that it feels old. Many things seem antiquated, especially the library ecosystem. It's very hard to tell if there are good libraries, because the ecosystem is so scattered. Some libraries may not have been worked on for some time, but still be adequate, but that's hard to tell beforehand. There is few endorsement/sponsorship of libraries/tools by organizations or companies; most artifacts are the product of the work of some lone hacker (at least, that's how it feels). Maybe quicklisp is solving the problem, but then again, it's in "beta" since 2012. As for the language itself, well it is quite nice with all the macros and stuff, albeit I once again miss types (mostly for documentation purpose, as Lisp can sometimes be quite cryptic). Typed Lisps exist btw, such as Shen.

- Javascript: Javascript reminds me of Lua, in the sense that both languages have a quite small set of basic features that turn out to be remarkably expressive. There are obvious problems however in Javascript, which are mostly the consequences of how fast the language was produced. Under the circumstances, it turned out admirably well. Javascript became popular because that's what was supported by the browsers, and this looped into a spiral of support/development.

4 comments

> Erlang: genuinely useful for its use case, distributed systems. This is a language where the intended use was really woven in the language design, to great effect. For the rest, it's a bit like ML without types. Personally, I see no good reason for leaving out types, so that tends to annoy me a bit.

I believe there's an interview with Joe Armstrong (creator of Erlang) where he mentions that the one thing he'd wished he'd added to Erlang was a type system at the jump. I'm not a 100% sure on that, though.

In Learn You Some Erlang for Great Good they talk about the lack of types in erlang [1]. Apparently some Haskell folks wanted to make a type system for Erlang, so they called up Joe Armstrong and asked what he thought. (this is all a really cursory outline; check the sources for better info)

Joe Armstrong recounts the story and says that Philip Wadler told him "he had a one year’s sabbatical and was going to write a type system for Erlang and “were we interested?” Answer —'Yes.'"

Philip went on to write a paper [2] about the type system they wrote, but obviously it never really got traction. More info in The History of Erlang [3]

I don't really have a particular point to this, other than it's interesting and maybe of some historical interest to folks looking into PL's and how they end up getting made.

[1] http://learnyousomeerlang.com/types-or-lack-thereof [2] http://homepages.inf.ed.ac.uk/wadler/papers/erlang/erlang.pd... [3] http://webcache.googleusercontent.com/search?q=cache:ZHq_V41... (google cached version; couldn't find another version right off hand)

Your statement about Java or C# being "much nicer and faster" than Go is just plain wrong (Well if that's true then what's the reason to use Go?). In fact it falls in the same vein as Java or C# in performance, but it has the advantage of being native code. It isn't made to be a C contender. It's designed to be the simplest language to learn, the easiest to deploy, compile as fast as scripts, coding half as nice as Python and runs as fast as Java. Currently it excels at Cloud / server development.
Very good overview, so let me just nitpick this:

    PHP: [...] It also has top-notch documentation.
It has not. It is accessible, it has always been easy to find everything in it, but it is very far from thourough. You need to hunt for user comments for implementation details in the interpreter that actually influences your script's behavior.

With that said, I've sort of came to peace with PHP and use it willingly at work. (JavaScript is the industry's arch enemy now.)

I'm saving norswap's excellent survey and assessments to share with others. Fair, honest, and captures the essentials quite well.