Hacker News new | past | comments | ask | show | jobs | submit login
Poll: What are your liked and disliked programming languages?
996 points by wting on Oct 10, 2013 | hide | past | favorite | 463 comments
This is a combination of these two polls:

That resulted in this chart:

Since that poll is ~18 months old, I thought an update is in order.

This poll also adds a few new choices: F#, Go, R, and Rust.

Vote as many choices as you'd like.

Note: By voting for a language you are not up voting this poll. Please up vote this poll to keep it alive.

Python - Like
2482 points
PHP - Dislike
1954 points
C - Like
1901 points
JavaScript - Like
1824 points
Java - Dislike
1745 points
Ruby - Like
1289 points
SQL - Like
1166 points
C++ - Dislike
1153 points
JavaScript - Dislike
1141 points
Go - Like
1132 points
C# - Like
1131 points
Visual Basic - Dislike
1091 points
Haskell - Like
929 points
CoffeeScript - Dislike
846 points
Actionscript - Dislike
840 points
Lisp - Like
824 points
Java - Like
817 points
C++ - Like
807 points
Ruby - Dislike
796 points
Clojure - Like
787 points
Objective-C - Dislike
768 points
Perl - Dislike
759 points
CoffeeScript - Like
688 points
Scheme - Like
646 points
Assembly - Like
626 points
Shell - Like
626 points
Lua - Like
602 points
ColdFusion - Dislike
596 points
PHP - Like
593 points
Scala - Like
563 points
Objective-C - Like
552 points
Erlang - Like
529 points
Perl - Like
504 points
Shell - Dislike
495 points
Cobol - Dislike
473 points
C# - Dislike
465 points
SQL - Dislike
460 points
Rust - Like
433 points
Python - Dislike
389 points
Go - Dislike
366 points
Scala - Dislike
345 points
OCaml - Like
322 points
Groovy - Dislike
285 points
R - Like
282 points
F# - Like
274 points
C - Dislike
271 points
Delphi - Dislike
259 points
Fortran - Dislike
258 points
Assembly - Dislike
254 points
Smalltalk - Like
245 points
Haskell - Dislike
238 points
Forth - Like
236 points
Pascal - Like
236 points
R - Dislike
232 points
D - Like
229 points
Pascal - Dislike
225 points
Tcl - Dislike
224 points
Clojure - Dislike
216 points
Lisp - Dislike
189 points
Other - Like
182 points
Actionscript - Like
178 points
Delphi - Like
165 points
Erlang - Dislike
158 points
Ada - Like
146 points
D - Dislike
141 points
Visual Basic - Like
135 points
Ada - Dislike
132 points
Groovy - Like
130 points
Fortran - Like
126 points
Tcl - Like
126 points
Scheme - Dislike
122 points
OCaml - Dislike
119 points
Other - Dislike
117 points
Lua - Dislike
116 points
Rust - Dislike
114 points
Forth - Dislike
108 points
Smalltalk - Dislike
101 points
F# - Dislike
100 points
Rexx - Dislike
93 points
Rexx - Like
40 points
ColdFusion - Like
36 points
Cobol - Like
30 points

And the award of least significant poll of the week goes to...

Seriously, you won't get anything meaningful out of this, people will vote for the language they like and then bash the usual suspects (PHP, actionscript, C++,...). Also they will browse the first 20 entries or so and then get bored and skip to the end.

I'm sure the people who "dislike cobol" (7 people at the moment) have intimate knowledge of the language in production in order to cast such a vote.

It's just a popularity contest and a bad one at that.

Also: "Other - Dislike: 5 points". Enough said.

Polls like these are meant to be subjective and to encourage discussion. Dismissing them because they're not scientific kind of misses the point.

Also I see no reason why this is any more subjective than it claims—it's not asking for which language is some ill-defined notion of "best" but instead which ones people "like".

I think it's perfectly reasonable to dislike a language you've never used. You can't claim it's a "bad" language (for reasons perhaps even above not having a definition for "bad") but I can't claim that you don't dislike it.

That fact that people are disliking languages they've never used is one of the reasons I'd agree the poll is meaningless. Sure, it's reasonable to dislike a language for whatever reason, but that doesn't mean that the results of such a free form poll can be interpreted in any meaningful way.

You can dislike a language for a number of reasons that have little to do with using it while still being meaningful. e.g. community behaviour, community style, and relative number of security flaws in products that use that language.

Who cares, it's interesting. It's cool to just to gauge the general sentiment of the languages on HN.

There are several ways to find meaning in the results. I claim it is a(some what sloppy, non scientific) measurement of PL bias in the HN community.

There's going to be the common blabber and hating on the usual suspects but polls like this tend to be good ways to bring up a general topic and let everyone discuss. Maybe it would've been better in a AskHN but at least here we get a list to reference (and for people to get angry at what's missing, people love getting angry). Also, it gives a view of what this specific community in this specific thread feels and adds to the context when reading other threads.

I don't think it usually creates interesting discussion. Just a billion of comments with no replies along the line of "XXX is great!" "YYY sucks!".

Everybody talks and nobody listens. It's just pointless popularity contest.

You have no idea what you're talking about. XXX is terrible. The new release of YYY has solved a lot of the problems that most people complain about.

None of the ideas in YYY are new. It's a mundane and vulgar rehash of things we already had in the ZZZ in 80s but done badly. OK, so the world's largest sites run YYY -- that's pure luck, not science. Or the fault corporate HR drones that don't know better asking for YYY skills. Or a massive conspiracy. Or maybe programmers just are dumber now than 10 years ago.

How can YYY even be taken seriously when not supporting homobubonic retroviral proto-smurfs? In fact, I've just written a nice tutorial on smurfs in ZZZ and how smurfs are just like smurfs -- once you are past that, writing a complex application like a "20 questions" game should not be a problem.

Don't get me started on dynamic versus static smurfing!

You forgot to say "I don't get why anyone is surprised by..", to get the full HN bingo card.

Polls like this are the equivalent of asking a builder if he likes wood, metal, concrete, plywood, slate, etc. Or if he likes a saw more than a hammer.

Which only a complete moron would do.

That's only a valid comparison if you're really big into polyglot programming AND believe that all languages are great in their own special way.

My thought exactly. Actually I was think - "geez, these people are such hipsters". Everyone loves the "cool" languages - Scala, Haskell, etc. But of course the lame languages suck (Java). Though I was pleasantly surprised to see the love for C#. It's a very nice language and you'd think being from MS it wouldn't be "cool".

That's a dismissive attitude. I think the love shown to C# is example enough that there may be more to the results than hipster-ism. C# is great, and the vast majority of Java programmers are aware of that. I mean, holy shit - no lambadas? Lack of reified types? The Java ecosystem is amazing (build tools, libraries, the JVM, IDE's), but the language itself is depressingly stagnant and unpleasant to work with in comparison to similarly-placed languages.

But perhaps the cool languages of today are cool precisely because they offer real advantages. Maybe they're advantageous only in our unique historical moment. That has yet to be seen. If their popularity fades over time, that won't mean they were simply hipster fads. It could just as easily mean they met significant needs at one point in time, but the needs changed, or we developed better tools that met those same needs.

As long as we can agree that Java is cool whatever this poll says ;-)

Based on this poll Java is not cool and most likely doesn't offer real advantages...

Yeah, that one perplexed me. I don't think anyone can deny Java's usefulness. I guess a lot of the hate is from people who find Java useful but still annoying. For my part, I don't think it's bad at all. When I use Java, I miss conveniences like `people.map { |p| [p.name, p.address] }`. But in exchange for typing more characters, Java gives me a huge ecosystem, good docs, effortless cross-platform coding, and pretty much the only hassle-free GUI API.

Why not use Clojure or another JMV language and get the same ecosystem at similar or less characters?

    (map (juxt :name :address) people)

Maturity and longevity, mostly. For really serious projects, I prefer to mitigate my risk by picking something that's been mainstream for a long time and isn't likely to die off. I'm not saying Clojure, Scala, JRuby, etc. are going to die off. Just that it's too early to tell.

Also, it's not exactly the same ecosystem. Yes, you can use all the Java libraries. But the ecosystem also includes the dev environment/build system, the written material, and the peopleware associated with the language. You don't automatically import all of these from Java just because you're using the JVM.

Scala enables you to keep most of the Java ecosystem (API, docs, cross-platform, and swing is even nicer in scala), and you can do `people.map { p => (p.name, p.address) }`, granted that the IDEs have to get a plugin installed before they are as helpful, but both Eclipse and IntelliJ has awesome scala plugins.

I don't see so much hate in the current results for languages that offer few or no real advantages. It seems to me that most of the hate is directed at languages that are often mandated by external forces, whether those be bosses, target platforms or simply lack of alternatives within a niche.

What's the concern? Is there any reason why disliking a language for reasons of fashion is bad?

I personally think that I'd maybe prefer not to work with someone who likes (and argues) for languages due to fashion... but I'm also a by-day-and-night Haskell developer, so I imagine that invalidates my opinion in some ways.

Fashion-based-programming leads to endless re-invented wheels and more effort going into running round in circles than looking a bit into history and learning from it. Ruby and Python seem to live in parallel, separate worlds. Oh look, here comes Node.js where everything's written again, this time in JS.

I'm not arguing for monoculture but it's a bit sad to see isolated communities not working together.

Haskell is an example of a language which a good reason to exist: solid unique PL qualities and is also highly applicable to specific problems.

I like Ruby and have been programming heavily in it for the last year.

However I still think Java and C are really good languages. I appreciate the niceties of both strongly-typed compiled languages, along with the 'coolness' factor of the dynamic languages.

And who can't love VB for getting shit done (at least back in the day). Though I can see if we are just focusing on the language.

My biggest problem with VB was inconsistency. There were multiple flavors floating around with subtle incompatibilities, so you couldn't always reuse code without modifications. Also, it did some weird things with types. Like error messages along the lines of "Type mismatch: expected string, but got string."

If VB6/VBA weren't coupled to the god awful IDEs and completely unversionable/patchable binary formats of their applications, it would be a pretty decent programming language.

It's persisted - absurdly - in spite of those crippling issues.

The VB6 IDE was Ok for 1998, but 1998 was a long time ago.

I still use VB6/VBA to get shit done, but only because I have a bunch of code & tools I've already written in or for it. I can see how it would be pretty useless to most people.

Registry-free COM has solved all of the versioning issues for me.

Language-wise, I find it's limitations to be its strength - kind of like ouilipo for programming.

Just curious, why are people bashing Actionscript? The language itself is based on Javascript and Javascript isn't getting so much hate. I know everyone hates Flash now... maybe I just still have a soft spot in my heart for programming Flash-based games back in the day.

I marked dislike on Actionscript because of AS3. Actionscript is basically Javascript, but with Actionscript 3 they added type annotations for static typing features. IMO, it did not fit in well with the language, and the integration between the two worlds (static vs dynamic typing) was poorly handled.

1/ Because it's at the top of the list and people are more likely to cast a vote

2/ Because most people (myself included) don't know actionscript but think Actionscript == Flash and downvote based on that.

There needs to be some way to differentiate people that hate a language for some external reason (anti-MS, anti-Apple, anti-Flash) or those who hate it from having used it. I suspect Java has more dislikes from actual users, where Actionscript and Perl get their dislikes from people who have never gone full time in either language.

Based on the numbers that I see, JavaScript is disliked more than ActionScript. When you take into account people's general dislike for anything flash related and how few people know anything about the language I think it did ok. What would be interesting would be to see a poll of the different versions of ECMAScript proposals and see what the public thinks of the real language differences between each. Classes are coming and structs are proposed and many of the things that ActionScript has had for a while are also leaking into JavaScript like rest arguments, and proxy objects. Overall I think ES6 is clearer and more flexible and I'm cool with omitting types unless you are doing things like types arrays and so on. ActionScript will go away over time and over time JavaScript environments will catch up even if they are still way behind in many respects today.

> Based on the numbers that I see, JavaScript is disliked more than ActionScript

Not now: AS has an 84% dislike rate to JS' 39%.

Classes without any kind of type checking are worthless imho. I would have prefered implicit interfaces instead of classes.

Actionscript has basically no error checking. It'll check for syntax errors and that about it - every other error manifests as a strange bug or "why the F* is nothing happening!?!" Then you spend an hour tracking it down and discover the cause was some trivial thing that any normal language would have simply raised a compiler error for in the first place.

And on top of that, its libs are very callback-heavy even in places where a synchronous option should have been available, so even very basic sequential code sometimes gets turned into a messy chain of callbacks.

That's why I made a beeline for the "ActionScript - Dislike" button.

Are you serious? When's the last time you used ActionScript, 2004? Modern AS3 compiled using the FlexSDK is a proper development environment with compile-time errors for types and all. Combined with a debug player, you get both compile-time and runtime errors.

It certainly has a hell of a lot more error checking going on than something like JavaScript by the virtue of being a statically typed language first with dynamic stuff second.

That's not to say that obscure bugs don't exist in the runtime as with every other runtime ever, but don't misrepresent something you don't seem to be well versed in.

The same reason everyone was down on Javascript 10 years ago: The development tools, APIs, and runtime were unpleasant. Unfortunately for flash developers it doesn't look actionscript will be following in Javascript's footsteps.

Also, in most cases, is it the actual programming language we hate or is it the code we've seen written by people who had no concept of the language that we hate?

Or maybe people have only programmed in one particular implementation of a programming language, e.g. Rubinius, Codehaus Groovy, or IBM Cobol.

What other Groovy implementations are there?

Since like|dislike is orthogonal to bad|good (how do you really define any one of the four anyway?) this poll can capture a decent sampling of current opinions about languages, from a fairly relevant subset of <the world>, and present at least a little more info than just dry feature comparisons. My two cents.

I voted "COBOL - dislike" because I actually work with it (although it was missspellt "Cobol").

Well, the like/dislike are totally subjective things. I can't tell if I like or dislike most of the languages of the list because I don't use them or, in some cases, I don't use them enough to have a strong opinion.

For me it's a perfect answer to the question "Why there are so many programming languages ? ".

It's quite silly asking such a subjective question, but aren't most polls just that, subjective?

Human experience is subjective. It makes no sense to make an objective poll.

Sampling bias and memory issues aside, you can make an objective poll. "Have you ever eaten oatmeal?"

I can only speak for myself, but I marked languages I liked that I've used enough to say like/dislike. The only one I disliked was ruby, which is something I've done enough in to know one way or the other. Overall I ended up with a bunch of likes and only one dislike.

All programming languages claim to be better than that "Other" language!

Not all.

Lisp doesn't claim to be better (it is often argued that it's worse). But what Lisp does right, it's meta programming, therefore letting the plain programmer improve the language himself.

So while as you suggest, all programming language will have warts and stumbling blocks, possibly deal breaker problems, that you can't do anything about, in Lisp, you can always and usually very easily overcome them yourself, with a little meta programming.

Lisp is not the best programming language, but what you make of lisp is the best programming language for you and your domain.

What if the "deal breaker problem" is all of the parentheses? ;)

No one who seriously gives Lisp a chance ends up disliking it because of the parens. It's about as reasonable as disliking C/C++ because of semi-colons. It's a superficial thing to criticize because you obviously haven't actually given the language a shot.

Given all the weird syntax people put up with in other languages I don't really get the complaint.

You are absolutely correct. That being said, I "disliked" COBOL as I used to be a mainframe programmer. It's a foul, foul language, but ironically, owes much of its success to that (long story).

The like:dislike ratio is a metric with some information, as well as the absolute numbers of votes (for mindshare).

oh I would just be as happy to label anything case sensitive as something I don't like. Easy as that.

>Seriously, you won't get anything meaningful out of this, people will vote for the language they like and then bash the usual suspects (PHP, actionscript, C++,...)

Why do you insist that is not meaningful? Of course they will vote for the language they like, that is the purpose of the poll. Obviously people can vote from ignorance, but that goes both ways. Just as some people "dislike" cobol despite a lack of experience with it, so too do people "like" PHP despite a lack of experience with it.

I think you mean "like" PHP despite experience with it.

The point is that the opinion of someone who has used a language and platform is of inherently more value when judging said platform than the opinion of someone who is coming from a position of total ignorance. In this sense your statement is a logical fallacy.

Actually not in a case like this.

This is not a pool for finding what is the "Best Language" (best language for what ?), but a pool to find what languages programmers like or dislike.

That is a matter of personal taste and opinion and there is not a wrong or a right answer.

Obviously if you have never seen or used or looked at the language you shouldn't vote on what other people say, but you don't really need to know the ins and out to make a personal decision.

I never held that there was a right or wrong answer, however the purpose of a poll is to infer value to the people reading it (otherwise the OP might as well write it on a piece of paper and put it in a drawer).

The definition of "like" the verb is "To find agreeable, enjoyable, satisfactory". The key word in that definition is find. How can someone "like" (in the true meaning of the word) something, or for that matter "dislike" something, if they have never "found" (/used) that something in the first place.

Therefore it is incorrect to say that you personally like or dislike something if you have not had direct exposure to that something. At most it would be correct to say that others in your peer/social group like or dislike something.

Your statement is a non-sequitur. In no sense does that make my statement a logical fallacy.

My statement is absolutely relevant to yours. Also, see my comment above. The technical definition of "like" requires someone to have "found" (/used in this context) the thing that they are "liking". Therefore it is incorrect to say you actually dislike something from a position of 0 exposure to it.

This may seem like petty semantics however it is no worse than preaching to others from a position of ignorance.

>Also they will browse the first 20 entries or so and then get bored and skip to the end.

Why would I need to browse down the list? Nobody here has used every language in existence. You hit ctrl-F and cast your vote on your favorite and least favorite.

Agreed. Unfortunately its posts like these that have become the norm here.

There will be obvious winners and losers, but I'm interested in the long tail results.

The poll quantifies a community's thoughts as only the vocal minority comment while the majority lurks. It provides a snapshot for comparison with other communities or even to Hacker News 18 months ago.

Language threads will provide more insightful commentary, but a general poll is useful for macro trend discussion.

I think it's very interesting to see some changes in the Hacker News community. For example, CoffeeScript's like/dislike ratio seems to be much lower now that 18 months ago. I bet some articles had an important impact in its popularity. Same would happen with MongoDB for example. It'd be nice to run this kind of poll every month, and try to correlate with specific articles that changed the mindset of the community.

For me at least I liked the concept of CoffeeScript, but had a couple issues with the implementation. I was originally very interested in it, but after experimenting with it for a little while decided not to use it as I felt it didn't really gain anything over using a particular style/subset of javascript itself.

I like C# more than Java because:

- The .NET Framework is a straightforward way to solve a problem vs pattern oriented solutions. This is not about the programming language itself but how the people in that community think about a problem

- C# evolved more than Java and it was more pragmatic. There are no operators in Java.

- I really like the diversity and maturity of third party Java libs. That's why I use IKVM when I need to use a lib from Java in .NET and why I use Jython. Examples here: http://blog.databigbang.com/tag/ikvm/ and here: http://blog.databigbang.com/tag/jython

I don't like Javascript, I would like to replace it with a standard VM to run other programming languages like Python.

I like C++ for performance oriented applications and when good libraries are available. For example I like CryptoPP.

I like Objective-C and their additions like Grand Central Dispatch. I like XCode.

I love Python: it's straightforward to build stuff.

I don't like PHP but many times I prefer to build some web scripts using PHP.

I like Pascal for teaching algorithms. More than C, because is less ambiguous.

I don't like C anymore except for firmware.

Collections in Java are awful. Guava helps a bit, but it's still poor man's substitute. No LINQ, no lambdas (and the upcoming Java streams API is ugly as well), no delegates, no events. Verbosity. C# is a very nice language, only WPF sucks big time.

Used WPF a couple of times, not that bad at all? What exactly do you think can be improved? Are there alternatives to it?

XAML is the awful part of WPF. The reasoning behind it is understandable, but this whole "declarative ui" thing brings with itself a whole bunch of abstractions, like resource dictionaries, styles etc, that you wouldn't need if you do your ui in code. And sometimes code-only wpf is the only way to get good performance from it.

Still much, much better than HTML. Or, how I love WPF containers... Have to deal with the ugly div-row-span hack that is BootStrap at the moment.

Basic binding works wonderfully, and the MVVM pattern is a good idea, but it just doesn't seem to work that well in practice. Some basic things seem overly difficult to do. I feel like there's a WPF way of doing things, but there is no reference for what that is.

For example: I had a DataGrid, and I was trying to figure out how to respond to the KeyUp event on a specific row, but only when it was the Delete key. I ended up having to create a custom dependency property in order to do that. 80 lines of code and a new class with 7 members later, I was able to reference that in my view and connect it to a method in my viewmodel. It works, but my lord it took me hours of googling and trying different things out for what seems like should be very simple functionality.

See http://stackoverflow.com/a/4120034/168719 - that's the highest rated answer for the question "What is the simplest way to bind a group of 3 radiobuttons to a property of type int for values 1, 2, or 3?" Do I really need to say more :) Or http://blog.wouldbetheologian.com/2009/07/why-wpf-databindin... or http://paulstovell.com/blog/six-years-of-wpf - he also raises an important point: WPF never made any significant progress. I'm under impression that I've once seen a better article that sums it all up (consistently with my own experience), but I can't find it now, so these will have to do

For me, WPF isn't the problem. I love MVVM, data binding, etc.

The problem is XAML. More like FML, amirite?

myeah it's a bit messy sometimes. But I yet have to encounter an UI design system that isn't? (ok, didn't try that many, and for example Labview is pretty nice since it gives you a working GUI with tons of features in no time, but for backend it's a disaster)

It's quite good. Very well suited for the job of creating enterprise apps, also good for other desktop apps. Let's you build a typical grids-and-fields GUI much quicker and with much less pain than "modern" HTML-JS-MVC hackiness.

Here are two things:

* It can be really clumsy to get programmatic hold of anonymous controls like buttons inside of list items

* Styling is clumsy

I forgot LINQ! I think nobody is using WPF for new project? I like that UI application feels native in C#/Windows.

Just started using WPF for a home project here. :-)

The .NET Framework is a straightforward way to solve a problem vs pattern oriented solutions. This is not about the programming language itself but how the people in that community think about a problem

There are plenty of people who overengineer their .NET solutions. They wouldn't dream of starting a project without including the Unity Application Block, for example. It may be a symptom of Enterprise Syndrome rather than a specific language community.

C#'s namespaces also make more sense to me than Java's packages.

Java packages is one of a few things that I like in Java more than in C#.

What's a "pattern-oriented solution"? As opposed to what?

Many libs in Java require to think about patterns instead of giving you a straightforward way to accomplish your goals.

Do you have more concrete examples of "pattern oriented solutions" that exist in Java and not in C#? Are you trying to say that C# is so expressive that it doesn't need, for instance, factories?

Meh, I will guess that is the usual suspects: like XML libraries, anything JEE, ORM, ... Those are the things for which Java provide an API (sometimes a default implementation) and you chose your implementation between competing ones.

The result is a mess of factories of generator of creator. Also, over the years best practice have evolved, meaning you get a variety of such mechanism in the JDK itself. With a single vendor, DotNet avoid a lot of that shit.

Then there is a huge variety of OSS libraries that integrate with each other. So you get another layer of pattern on top of the JDK. OSS libraries are extremely popular in java, much more than in the DotNet world, so that contribute to the sentiment.

Another usual suspect is a fashionable "Spring hate" or "Hibernate hate", ... Dependency injection, ORM and other patterns became mainstream on java and are very often used.

Even less hated "pattern" like mocking and unit testing started there too. A lot of projects still use older style less modern implementation of those.

EDIT: Also a lot of libraries are mature and implement the entirety of the specification they provide support for. Since java is mainly used for enterprise application, the most google-able libraries to solve problem X is generally the enterprisy one. For example if you search how to serialise to and from XML, you end up with Jaxb as the preferred solutions. You will not hear as much about XStream which is a more limited but much more straightforward approach.

I was clear enough in my opinion. I don't think it's an issue related to the programming language but how the community works. As ern said there are people in the .NET following this approach with stuff like the entity framework.

For further information you can read: http://c2.com/cgi/wiki?PatternAbuse

Saddened to see a high number of ColdFusion dislike votes. As a CFML developer who routinely bears the brunt of gleeful derision, allow me to point out what you're missing out on.

Yes, ColdFusion was a bit awful in its early days, but to be fair, it was pretty much the first of its breed, predating PHP, JSP, and ASP.

Modern CFML is a JVM-native language and framework that runs in a Java servlet engine. There are three first-class from-scratch implementations, two of which are fully open source. To cut a long story short, the best one is called Railo, and yes, it's one of the open source ones.

Modern CFML running on Railo is an awesome environment to work in: PHP-like hackability, native JVM performance, first-class java library integration, all on a 100% pure open source software stack. Think of it as JSP for genuinely rapid development.

I swear if Railo wasn't associated with the stigma of ColdFusion, it would be up there in the pantheon of fashionable web languages. It's Groovy with batteries included. It's Ruby On Rails for people who wish their code ran faster and realise that ORMs are inherently stupid. (Or there's Hibernate integration for those who haven't realised this yet.)

My first job included a significant amount of ColdFusion and CFScript. Having worked professionally in probably 10 languages since then, and speaking from personal experience, I feel comfortable in saying that ColdFusion is a terrible platform and deserves all scorn that can be heaped upon it.

As a CF developer (among many other languages) for bordering 15 years now I have come to accept the blanket rejection of the platform. I had to smile at the stats above because I have to wonder if the number of people who have marked "dislike" have even used it (or at least any time recently)

As I write this there are about 2200 votes apiece for both PHP and Python, two languages most people will have an opinion on, so lets make an assumption that's somewhat representative of the voters to date. Also at the moment there are 500-ish down votes for Coldfusion. From my experience it seems suspect that 1 in 5 developers, or even 1 in 6, has worked with Coldfusion enough to have an opinion on it outside of external influence. This type of trend probably also applies to other languages, in both directions.

That said, on Coldfusion, it's far from perfect but it also gets a pretty unfair judging in my personal opinion. Just my 2c.

realise that ORMs are inherently stupid.

That's quite the claim... Care to expand on why you think ORMs are "inherently stupid"?

Because you can't cleanly map objects to sets nor sets to objects. Sure, if you want to pretend an RDBMS is an object store you certainly can, but you'll be forced to have an incredibly stupid schema, and will miss out on much of the benefits of a good RDBMS.

Turning a powerful SQL database engine into an object storage emulator is just sad.

If your underlying data suits objects better than sets, consider using something that's designed for the job, like one of the many non-SQL database systems.

  Although it may seem trite to say it, Object/Relational Mapping
  is the Vietnam of Computer Science. It represents a quagmire which
  starts well, gets more complicated as time passes, and before long
  entraps its users in a commitment that has no clear demarcation
  point, no clear win conditions, and no clear exit strategy.

Well worth reading.




Unfortunately I didn't have time to read these articles in depth, nor do I have the time to write a detailed answer now - sorry. But it seems to me that the situation has changed since these articles were written, at least concerning the tools I know best (which are .NET and C#).

We now have built-in support for data (sets) manipulation in C# and Entity Framework makes things like db.Customers.First().FirstName with syntax support totally real. Many of the premises these essays seem to be based on (like "the languages in play lack any real specialized data structures") are just not true anymore.

Also, I would like to know more about why using an ORM like EF would force me to "have an incredibly stupid schema".

Turning a powerful SQL database engine into an object storage emulator is just sad.

Now that I can agree with, but I would consider that to be a (subtly, perhaps) different position than:

"ORMs are inherently stupid".

IF you have the option of choosing a native object store for persisting objects, then - by all means - choose it. But in cases where an RDBMS is the data store of choice for whatever reason, and you still have to store your objects there one way or another, I'd prefer using an ORM like Hibernate over hand-rolling all the low-level SQL/JDBC code to marshall objects back and forth between the DB.

I think ORMs are "inherently stupid" (or: "quite likely to be leaky as abstractions") because they don't necessarily share a theory with the underlying databases ("something like but not exactly relational algebra") and I don't think many people spend time proving that the OO-like theories can be properly embedded into something-like-relational-algebra.

Not saying you can't get work done with them, but it does mean that they're likely to leak.

also without an ORM do you just hand roll all your object graphs? I'm picturing a sea of builders and factories which amount to a hand rolled ORM anyway. Or are you practicing stringly typed programming? Ultimately in any strongly typed language you're either going to make/use some kind of mapper or else abandon typing and use maps/dicts which raises the question of why you're using a strongly typed language in the first place.

First, you can have strongly typed languages that aren't object oriented. Instead of using maps/dics, you could use records.

The thing I don't like about ORMs as they are typically handled is that you map objects to tables up front, and those are the things you can query for.

Using something like Linq, you can more easily treat your database as relational, and still return strongly typed objects. These objects can be the thing you wanted to return from the query, which is not necessarily mapped directly to the entities in the database.

I like this approach more, since you still get one of the main advantages of a relational database: you can get the data in the shape you want, not in the shape it's stored.

Could you explain this a bit more in depth if you have a chance? This is extremely interesting, but I'm not familiar with terminology associated with strongly typed languages. What do you mean by using records instead of maps?

You can think of a record like a C struct. It's key value pairs, but the keys and their types are chosen at compile time. There are no methods or anything on them, they are just data.

An example from OCaml:

type person = { first_name: string; last_name: string; age: int }

In a language that has some form of anonymous records (like C#'s anonymous object) and structural typing, this would let you work with relations in your language, much in the way you'd use them in SQL.

I personally like treating data as data. It should be immutable, and therefore there is no state to hide, which means there isn't much value in your types being objects.

It also allows for nice things like pattern matching to work with your data.

You still need some kind of mapper though to go from the SQL results to your record type, even if it's using convention such as the records fields are named the same as the table columns you're pulling from. I'm not arguing that for instance Hibernate is awesome, just that you need something to fill that gap, and you can do a lot worse than Hibernate, particularly within the limitation imposed by Java. Personally I prefer something like this ( http://hackage.haskell.org/package/esqueleto- ), but will usually settle for Hibernate or similar in less powerful languages like Java.

> you can get the data in the shape you want, not in the shape it's stored.

If you build a database view, you can often trick an ORM into thinking its a table.

most ORMs have a query language too, it's not just "Linq". Orms are good for development purposes and you can always do raw SQL queries within ORMs at some point.

The thing that's nice about Linq is the integration. You can directly reference variables in the things you're querying, and then either fill in an instance of an existing class, or generate an anonymous object.

For example:

  var query = from c in customers
              join o in orders on c.ID equals o.ID
              select new {
                Address = c.MailingAddress
Of course, anonymous objects in C# can be a pain in the ass, since you can't usefully return them from a method. Something like Scala's structural types would solve that problem.

I don't really like C# that much as a language, but I do like the Linq approach.

Thanks for mentioning Railo. The problem with CFML is that Coldfusion(tm) gives Coldfusion a bad name. Some 'legacy' apps that ran on CF were recently switched from Adobe Coldfusion to Railo and it is like night and day... way better memory utilization, hugely advanced caching options and the speed is crazy... like as fast as PHP and other languages I've worked with.

As someone who has only associated cold fusion with people laughing, thanks. I'll be sure to look into as an option before I start my next side project.

To be fair, I'd only actively recommend CFML if it fits your requirements -- if you want something hackable like PHP, perhaps the flexibility of being able to load and use any old Java library, and don't want your language to be opinionated on client side frameworks.

Otherwise I tend not to recommend, mostly because there's a lot of old bad CFML code out there, and it's frankly embarrassing.

An interesting fact about Railo/CFML is that the recently lauded Distrokid[1] site that got rave reviews from many HNers was built in Railo[2].

[1] https://news.ycombinator.com/item?id=6519175 [2] https://news.ycombinator.com/item?id=6519743

I liked ColdFusion as a whole but really disliked using it in a professional context - most other developers just seemed to have a bad understanding of how ColdFusion specific variable scoping worked.

No mention of CFScript

I like C++. I dislike C++.

No seriously. For everything good about a language there's usually something that's not so good and is completely frustrating. That's why there's so many programming languages, they're all awful and excellent at the same time, asking a favourite is like saying 'do you prefer being hugged whilst on fire, or being hugged by someone on fire'.

Sounds like a Stockholm syndrome. :-) No worries, I have that with Haskell.

Just yesterday, my colleagues were describing having Stockholm syndrome with Java. Went something like: "It's really easy to make fun of, but the more you use it, the more you start to feel bad for it."

I guess that liking or not, depends on how much you like the features, to forget/forgive/disregard it's drawbacks. For example, Python has drawbacks ... but, I do LOVE the language, is just such I joy to code in Python, that I just dont care that much about its problems. For me, is the same for C and Lua But, for C++, is the oposite. I do like some of its features, but, overall, I really hate the language. Too much headaches and pitfalls. And it's the same for javascript. But, hey, it's a personal opinion. I do really respect brendan eich as a developer, even lot liking javascript.

I was thinking the same thing about simultaneously liking and disliking JavaScript.

I feel the exact same way about Javascript.

In my very uninformed, and novice opinion, which you should entirely disregard, it is my probably incorrect estimation that the Rust developers are in maybe over their heads. I don't like saying negative things about an interesting idea, good engineers who mean well, so I don't like this so please someone convince me why I'm wrong.

A few things:

The multiple ways to manage memory seem completely messy to me, the various ways to box values and what not and what the implications are. It's not pretty, it's not elegant, but then sometimes things aren't. I'm complaining about prettiness over usefulness somewhere else in this thread. But the box memory model thing left me feeling like it was a convoluted solution that could end up in confusion.

No SSL stuff. Not much encryption stuff. And worse of all in their mozilla IRC channel those guys said writing such things should be left to experts, that people should always use the C libraries with rust. Being able to make HTTPS requests would be a pretty important feature for a browser like Servo I'd think. It's true security features should be vetted, and cryptography requires expertise, but on the other hand look at Go. They wrote a lot of their own cryptography code in go, and it seems to work pretty damn well.

The pace of development. Given the state of the network io library, the many packages required to get to a useful state, it seems like it's going to be about a decade or so before Rust is even usable. Which is fine, it's not a race. But overall I just get the feeling that I'm not sure Rust is what it aspires to be.

Anyway. I hope Rust does do well. I like the idea, I like the people working on it. Maybe I shouldn't have committed to forming any kind of opinion still so early in its development.

> And worse of all in their mozilla IRC channel those guys said writing such things should be left to experts, that people should always use the C libraries with rust.

>It's true security features should be vetted, and cryptography requires expertise, but on the other hand look at Go. They wrote a lot of their own cryptography code in go, and it seems to work pretty damn well.

The issue here is that people who try to roll their own cryptography solution fail at it and introduce insecurities on their own almost all of the time. Think about the amount of bugs in any reasonably complex solution that the layman comes up with. Now imagine what happens when you set the layman off to implement a solution to a problem already solved by experts that can totally destroy your business if not written perfectly.

If we wrote our own cryptographic algorithms for HIPAA compliance where I'm at, I'm pretty sure we'd eventually have to shut down the company due to mass violations due to improperly implemented complex algorithms.

I can't speak to the reference counting and garbage collection libraries (which are likely the items to which you are mainly referring), but I found Rust's approach to the more mundane memory management scenarios to be enormously refreshing.

When writing Rust, you simply tag those variables that the current thread of execution is responsible for free()ing when they go out of scope. The compiler enforces correctness and can tell when you've tried to use a variable that's no longer available. There's no such thing as an invalid memory reference and so long as you avoid using a GC library, there's no overhead whatsoever. When the compiler's happy, you can rest assured that your program is free from entire classes of subtle bugs that can lie in wait for years before you get your first segfault.

The Rust team has admittedly put very little time into optimizations at this stage. However, Rust's manual memory management combined with LLVM's existing optimizations have put its performance on par with C in several (simple) benchmarks. In others, it can be found somewhere between C and Go. That's quite a feat for so young a language.

Forgive my gushing. I'm very excited to finally have C speed and high level language features without segfaults.

> The multiple ways to manage memory seem completely messy to me, the various ways to box values and what not and what the implications are. It's not pretty, it's not elegant, but then sometimes things aren't. I'm complaining about prettiness over usefulness somewhere else in this thread. But the box memory model thing left me feeling like it was a convoluted solution that could end up in confusion.

Rust is also the only industry language I'm aware of that gives you memory safety without garbage collection. We have some changes in the works to reduce the cognitive burden of the pointer types before 1.0 (most notably putting GC in the library).

If you firmly believe either (a) memory safety is not worth it or (b) garbage collection is superior to manual memory management in all circumstances, then Rust is not for you. That's fine! I don't want Rust to be the end-all-be-all language for all projects, and I love language diversity. But it's precisely this feature—low-level, runtimeless programming without segfaults or memory-related security vulnerabilities—that makes a lot of people interested in Rust.

> No SSL stuff. Not much encryption stuff. And worse of all in their mozilla IRC channel those guys said writing such things should be left to experts, that people should always use the C libraries with rust.

The opinion of the security community, including tptacek on Twitter, has been unanimously in favor of this decision. We consulted with our security team before deciding this. There is literally no reason to write security code in Rust, except for memory safety; the FFI in Rust is extremely well-integrated and you can call C code like it's Rust code (in fact, there's even work being done to optimize across C and Rust!)

> Being able to make HTTPS requests would be a pretty important feature for a browser like Servo I'd think.

Servo will be able to do HTTPS requests, of course. The plan is to do it via NSS.

> The pace of development. Given the state of the network io library, the many packages required to get to a useful state, it seems like it's going to be about a decade or so before Rust is even usable.

The fact that it requires several packages to get useful things working is a deliberate design decision. Rust's philosophy is small, composable modules—it's like Node in this regard.

We don't have SSL yet, and the I/O needs work, but the new scheduler, which involved a complete rewrite of the entire I/O subsystem, is literally 3 months old. I don't see how you can extrapolate from that to the idea that it'll take 10 years to make an SSL connection.

> Rust is also the only industry language I'm aware of that gives you memory safety without garbage collection.

Python uses refcounting, and has a GC only for cycle breaking. You can turn it off in many cases and have deterministic behavior. Among compiled languages, Vala has no GC but safe references. It uses refcounting, too, but AFAIK also deduces when an object will not leak out of the scope (and thus the refcounting can be elided). But Vala is also somewhat a niche language, constructed around the GObject/Gtk object model.

That being said, the way rust handles memory looks really interesting. I definitely have to try it out these days.

Reference counting is a form of garbage collection. There are many industry languages that offer safety without tracing garbage collection, but not without any garbage collection.

Thanks for the response. I do hope Rust becomes what it wants to be. :)

I haven't made up my mind yet about whether or not I find Rust's memory management ideas convoluted. But the Rust people seem to be the only ones working on this important problem at all and contributing some innovative ideas.

Looking at this long list of programming languages, I see two approaches used by the vast majority of popular implementations: Conventional tracing garbage collectors that cause pauses up to minutes, and naive reference counting which is slow, concurrency hostile and error prone.

Obviously, don't know every implementation of every language on the list. So please tell me I'm wrong. I would love to be!

> No SSL stuff. Not much encryption stuff. And worse of all in their mozilla IRC channel those guys said writing such things should be left to experts, that people should always use the C libraries with rust.

Over in D language land, we've actively discouraged people from rolling their own encryption libraries. We strongly recommend people use standard, vetted libraries like openssl if they are serious about needing encryption. D can interface directly to C libraries.

I don't see it as a language issue at all. It's more like there are so many subtle issues with doing encryption right that one should be standing on the shoulders of giants rather than starting over.

I hope it's okay to vote Like and Dislike for javascript

Watch out, or PG will make it so that you see nothing but javascript stories for the next year:



I had to do that for SQL

I did the same for C++. I hate many aspects of the language, and it feels really ugly compared to newer languages like C#, or even D, but it's still my language of choice for some projects (mostly because the tools are mature and almost everywhere).

I would have done that for XSLT if it had been on the list.

Forgive my ignorance, but I inherited a wad of xslt fairly recently, and it seems frustrating and verbose to me.

What do you like about it? Can you point me to some examples of good code?

XSLT is a purely functional language so inherits much of the general set of likes/dislikes that go with them.

    <xsl:if test="x">template</xsl:test>
is basically this in Lisp:

    (if eval(x) (apply-template template) nil)
And <xsl:for-each> is equivalent to map in Lisp. It's a functional projection, not an imperative loop, even if the syntax looks like that of an imperative language.

Functional purity gives you the usual advantages: execution that can be testable and fast and parallelizable and predictable in space and time usage and secure in presenting little attack surface for injections and overflows and such. XSLT is exactly what it claims to be, a declarative way of transforming tree structures.

The problem with XSLT in enterprise land is that real world business requirements don't fit well into that. Real world applications involve things like iteratively computed subtotals or comparing separate records together or picking up user preferences for formatting or other sorts of conditional logic. All of which is a poor fit for XSLT and leads to really complicated XPath hacks.

And your average enterprisey programmer comes from imperative languages and thinks and codes in imperative terms, often not even realizing XSLT is a functional language. So it's no surprise that real-world XSLT ends up as muddy balls of crap.

That was very informative, thanks.

One thing about XSLT is that when it is bad it is really really bad.

It can be fairly elegant, especially if you know the difference between apply-templates and call-template and are happy with all of the feature of XPath. But I suspect that is fairly rare....

Me too. I use it daily, and am both amazed and confounded by it. Powerful and frustrating.

Just did the same thing, we're all in this together, though 7-8 yeas ago it would've been a straight dislike. It's power is growing, be wary.

Same here, it's quite unavoidable if you started out with javascript coding and matured with it.

Damn Java has a 1:2 like to dislike ratio. Why do people hate on Java? I'm totally biased because it is the first language I learned and I use it daily but seriously, why the dislike? It is powerful, portable, stable, hard to shoot yourself in the foot with, and tons of standard libraries. Also the libraries (standard or 3rd party) rarely violate the rule of least surprise. I can nearly always guess the right way to do something if I don't know about an object in a library.

Sure it has warts like all other languages -- memory hog, weird design patterns, bulky code -- but a lot of those can be easily avoided or worked with.

Sorry for the rant. I've just never had someone give me a straight answer as to why Java is so disliked. It usually has something to do with design patterns (FactorySingltonParentFactory.helper.blahblahblah) but that's just preference and is hardly the common case with Java code.

For me, it's the sheer verbosity. You can't just say "import module; module.function()" without having more boilerplate than code.

Also, "hard to shoot yourself in the foot" can sometimes mean "hard to do mystical stuff when you really, really want to". 99% of the time, regardless of language, you should be writing clear, idiomatic code. 1% of the time, though, you want some voodoo (that you can encapsulate so that no one else really has to understand it), and when that time comes you want the language to get out of the way.

For example, almost no one needs to write metaclasses in Python. It's just not something most people will ever have a nonzero desire or need to do. But, suppose you're writing an ORM or a templating system or something else were it might be darn handy to create a lot of methods at instantiation time. In those cases, it's incredibly convenient to be able to do the magical stuff at all. You only have to get it right once, then all the downstream users can benefit from a much simplified and cleaner experience.

I don't want to shoot my foot. Sometimes, though, I might want to shoot a snake crawling across it. I prefer to use languages that keep things safe in general but allow shoot-footing when you really, really need it.

I get that it is verbose but I kind of like that. It makes reading code less ambiguous. I understand that is just preference though.

As for your import example you can totally do that:

> import java.util.Collections; Collections.sort(someList);

You just have to make use of static methods. I do understand though that a lot of the standard library is not designed like this so your point is taken.

I don't dislike Java as a language I learned OOP with it, actually, Java made programming exciting for me when I was learning. But what I really dislike are some tools around Java, maybe this is totally subjective, but I don't like its most common IDEs (NetBeans, Eclipse, JDeveloper), I dislike the look and feel of its default desktop GUI libraries (Swing, AWT) (I know I know, who the hell still develops desktop apps these days?), but what I really dislike(almost hate) are the web frameworks from Oracle.

I'm sure there must be several great tools out there that replace those that I don't like, but I haven't had the time to explore.

> It usually has something to do with design patterns (FactorySingltonParentFactory.helper.blahblahblah)

That sums it up for me, basically. I could add that this is a manifestation of the tendency to make things more complex than they need to be which is pervasive in the whole Java ecosystem. IMO, even Scala couldn't escape the curse and suffers from it (although it's a lot more pleasant to use than Java).

For me it's this: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

My first real job was programming Java and I have a bit of nostalgia for it, but having to do anonymous inner classes for a simple callback is kind of annoying.

Callbacks would be sweet, but for someone who never really used them till I got heavy into javascript I don't really ever think to use them right away. Also callbacks are mostly for asynchronous stuff which you can get away without using in java a lot of the time (I think, that's really the only time I use them at least).

Working with basic data structures like maps, sets, and lists that you don't have to manually allocate takes approximately 20 times as much code as it does in nicer languages like Python.

Because the language comes with a culture. Same with C#. C# is a great language. Horribly misused and taught in the weird manner, leading to incredible amounts of indirection that people confuse with abstraction.

If you've ever tried C# it's hard to go back to Java without hating it, because they are so similar but Java is much more crippled both language- and standard library-wise.

"Assembly"? For what platform? I could care less about AT&T, I've learned to live with Intel, and I'm interested in ARM. It's rosy to think that I like 6502 but it's not the best. What does it even mean to, "like," one of these, "languages?"

I've only learned various assemblers by way of necessity writing compiler backends (usually in my spare time for fun... I don't even know these platforms well enough to write a serious production-grade backend with optimizations). Some I find easier to work with than others... but how can you, "like," one over another? I find assembly to be rather devoid of any characteristic that I find interesting or emotionally endearing.

It's easier to attach an emotional context to a programming language these days by proxy; I think most programmers simply associate with the culture that develops around a language. But there was an era when a programming language was just a manual and all you had was a compiler. There wasn't anything particularly interesting about using one over another beyond perhaps what they were capable of from a technical perspective.

So what does it mean to, "like," a language? Do you find it technically superior relative to all others? Is there some socially accepted criterion I am unaware of by which we measure how we feel about a language?

People are strange.

Regarding the language itself, what's there to dislike about C#?

If C# wasn't made by Microsoft, but had a similar toolset and feature set, i would offer the opinion that it would be the top managed language.

I don't understand that attitude. First, you can use C# really well without depending on any Microsoft tech. Second, Microsoft standardized the language and made a community promise not to enforce their C#-related patents (like e.g. Oracle did against Google for Java).

So, it free, it has full FOSS tooling. What's the problem?

> First, you can use C# really well without depending on any Microsoft tech.

As someone who is coming from a very FOSS world and trying to learn C#, I have to counter that no, C# does not have a really good open source ecosystem. Mono works, MonoStudio is pretty decent, but it lacks all of Windows, and there isn't much to target that is not Windows if you are doing anything that is not a webapp.

Objective-C also has a pretty decent open source toolkit in GCC, but a toolkit that lacks Cocoa is like trying to eat dinner but forgetting the food. Mono is a great toolkit, but it's missing 80% of the libraries that makes C# an easy language to use. You've got your forks and spoons, but you've got nothing to eat.

Note that I'm not complaining against C#. I'm really liking the language and everything I can do when I'm in a Windows or Windows Phone environment. I'm arguing that C# is not as portable, in practice, as everyone continually claims.

I started learning F# a few weeks ago and feel the same way. The language is very nice, but so much of the .NET ecosystem is Windows-specific. I've run into a handful of libraries that would be useful, but I cannot use them on my Mac. To be fair, there are quite a few libraries that do work.

Furthermore, much of the documentation assumes a Windows environment. Getting a development environment set up around Mono has been possible but challenging.

F# and Mono are neat, but .NET has a long way to go before it becomes as cross-platform as Java.

The word "Microsoft" tends to evoke emotion, highly irrational in many cases, despite any actual facts present.

With that said, I know a lot of devs who hate almost everything about MS that actually do like C#.

It's not an irrational behaviour to say "I don't know where you're holding the knife this time, but it's not worth the effort to find out"

The standard only covers up to C# 3.0, if I am not mistaken.

the nuanced microsoft brand

I hate Microsoft, but I love both C# and F# as languages. Unfortunately, I refuse to use them because Microsoft.

Mono is a great attempt at making the use of the languages acceptable to me, but unfortunately it is still a second class citizen. It works okay, I guess, but .NET was created from the ground up as Windows infrastructure.

The same could be said for Clojure on the JVM...it works great if you are using pure Clojure, but the moment you try to use Java libraries, all of a sudden everything becomes messy and loses its idiomatic nature and all the elegance that goes with it (like, for example, the pervasiveness of mutating methods in Java but the almost religious avoidance of mutability in Clojure).

Oh for the love of... it IS a top managed language. Probably the best general-purpose language on the market right now. Not the most widely used, of course, but one of the most enjoyable.

It lacks some of the syntactic niceties and metaprogramming you get with languages like Python.

Otherwise it's quite good for what it is, and my frustration with C# is entirely down to the ongoing failure of Unity Technologies to upgrade the version of Mono included with their game engine. It means I'm stuck with an old version of C# (notably without the dynamic type), watching as quite a few third-party libraries drop support for it.

Variance is messed up, lack of higher kinded types, type inference is pretty awful, no implicit conversion, too much boilerplate for a small method call. sometimes I just want to write:

   public static String getFirstThree(String s) = s.SubString(3);
etc. But, the fact that it has LINQ, good lambda support, and some type inference make it a very good language over all.

lack of higher kinded types,

If you know about kinding, you probably understand that type system design really has to go hand-in-hand with language design. Introducing those kinds of breaking changes now is incredibly difficult, unfortunately.

As far as boilerplate goes, though, I can't promise anything but I can say that we hear you and this is something that could get attention in the near future.

The standard library smells of rot much like Java's(how many timers does one standard library need? The multiple incompatible collections classes, and GUI libraries etc).

Thanks to the rapid language iteration we have neat code features. Thanks to the rapid language iteration our large, long lived code bases now have language version "sediment layers".

Not about the language in particular but other reasons to dislike it. For some reason there is a big NIMS(Not Invented by MS) in the community. People use MS's shoddy add on libraries because they are from MS (Asp.net webforms, EF). The announce, wait 20 min, and kill cycle for some of MS's libraries.

I like C#, and I think that it's an objectively well-designed language given its designers' priorities. But if you have different priorities, there's plenty to dislike. If you want a scripting language, or a really expressive type system, or raw-metal performance, then C#'s not going to scratch your itch.

If I didnt have to use the Microsoft Stack, I'd probably make my main language C# . I like the language, but dont want to use IIS, Windows Server et. al.

Give me (not mono) C# on linux and my choice of webserver and I'll change teams.

There is OWIN for .NET which is the equivalent of Connect / Rack / WSGI. So hopefully in the future it won't be reliant on IIS.

It's almost impeccable at what it's trying to do, but I can think of a couple of things:

* References are nullable by default (IIRC Hejlsberg himself would do this different if he could)

* Its C-derived brace-heavy syntax can make C# code a bit messy-looking and stretch out a bit vertically, especially with the community's preferred brace style

References are nullable by default (IIRC Hejlsberg himself would do this different if he could)

Yeah I think we all would.

I've written a simple ranker for the above scores: http://ancient-garden-9751.herokuapp.com/

Python and C most liked, PHP and Java most disliked (currently)

(Source here for if/when it goes down: https://github.com/thomseddon/lang-rank)


  lower bound of confidence interval at 95% level

source: https://github.com/bshanks/lang-rank

The resulting lists are quite similar but not identical, so i've analyzed them to find sets of languages that always or almost always appear at the top. I also made the corresponding 'most disliked' lists to find the most disliked languages.

On every 'most liked' list out of the above with some sort of control for wellknown-ness[1], the two most liked languages are C and Python. On every corresponding 'most disliked' list, the most disliked five languages are coldfusion, cobol, visual basic, actionscript, php.

Looking at various lists, the next most after C and Python liked usually tend to be lisp, scheme, lua, haskell. Then clojure, rust, erlang, go. Then sql. Then assembly, C#. Then ocaml, F#.

And after {coldfusion, cobol, visual basic, actionscript, php}, the next most disliked usually tend to be groovy or java.

In other words, the partial ordering seems to be approximately[2]:

  {c, python} >
  {lisp, scheme, lua, haskell} >~ {clojure} >~ {rust, erlang, go} >~ {sql} >~ {assembly, C#} >~ {ocaml, F#}
    > ... >~
  {groovy, java} > 
  {coldfusion, cobol, visual basic, actionscript, php}

It's interesting to contrast this 'most liked (controlling for wellknown)' ordering with the most (like+dislike)d counts, whose top 9 items are javascript, python, java, php, c, ruby, c++, sql, c#:

* Python is both extremely liked and extremely well-known

* Javascript is extremely well-known and is both liked and disliked.

* Java is extremely well-known and very disliked, and PHP is extremely well-known and extremely disliked.

* C is very well-known and extremely liked.

* Ruby and C++ are very well-known and both liked and disliked. SQL and C# are very well-known and more liked than disliked. Haskell and Go are moderately well-known and very liked.

* Lisp, Scheme, and Lua are not well-known but are very liked, and, to a lesser extent, Clojure, Rust, and Erlang.

[1] by which i mean, the six lists (like/dislike), ( (likeDirichlet/(likeDirichlet+dislikeDirichlet)), lower bound of confidence interval at 95% level ), (like/dislike)log(like) ), ( (like/(like+dislike))log(like) ), and ( (likeDirichlet/(likeDirichlet+dislikeDirichlet))*log(likeDirichlet).

[2] where >~ means a relation that holds for many of the lists under consideration, and > means a relation that holds for all of them.

Nice. It would be cool to add a third column ordered by the ratio of likes/dislikes.

Thanks! Definitely helped me figure out which languages people voted on overall, as well.

Love the language or hate the language, there seem to be some languages that are much more on people's minds.

I was actually expecting the HN crowd to hate Java more than PHP. But it was close!

143 dislikes for COBOL? Call me cynical but I'll bet most of those votes came from people who have never been near a green screen.

Honestly, I'm pretty sure its the same with C++.

C++ faults are blown out of proportion by sensationalists, most of whom have never touched C++ code in their lives.

Out of C++, Java, Javascript, and PHP, easily four of the most used languages in the poll, only a single one has positive votes. And it has just as many faults as the other three.

Are you suggesting people are voting on things from completely uninformed positions??? ...would people really do that? ;)

It's at something like 340 dislike votes now- I believe your point is more prescient now than ever. :)

I'm surprised at the lack of love for Groovy. Groovy rocks... I made the decision to switch all of our development to Groovy (and Grails) a couple of years ago, and I haven't regretted the move at all... it's gone astonishingly well. Much faster development than in raw Java, but without a huge learning curve, and yet still with seamless integration with existing Java libraries, plus more than a few very cool native Groovy libraries. What's not to like?

> I made the decision to switch all of our development to Groovy (and Grails) a couple of years ago

Look at Groovy's history before 2 yrs ago and you'll see what's not to like. Groovy recently (29 Aug) turned 10 yrs old but no one was celebrating.

I've been using and following Groovy for varying degrees almost since the first release... I'm not sure what you're getting at. As far as I can tell, the only real, persistent, commonly-cited flaw with Groovy has been performance. And that is a fair criticism, but - at least for what I'm working on - not a "deal breaker". And I'm still optimistic that the Groovy team will eventually be able to follow in the footsteps of the JRuby guys and do some big things to take advantage of method handles and invokedynamic to speed things up. But even if they don't, Groovy is fast enough, even if it's not exactly setting the world on fire.

If there are any other serious complaints about Groovy, I haven't heard them, and/or haven't encountered them myself.

What? No love for F#? Why do folks always leave F# out of these things?

I liked F#. Even build a web request handler using it :)

However I kind of don't trust Microsoft to keep supporting this side project... Remember FoxPro?

Right now one of my side projects involves F# on Mono.

I write in Visual Studio, which I own, I deploy to Mono, which is free, and I have access to all the MS libraries over in linux, which are also free.

What's there to support? Do I really need version 7.0 of F# with the neuro-cranial implants? Or do I need just to write solutions for people?

F# is a great transition language from OOP/Imperative-land. You can write code the old way, the new way, purely functional, or in a hybrid fashion. I don't think we require much MS support for it to continue to fulfill that role.

Now if you're deploying to windows, that could be another kettle of fish. But I don't do that anymore.

As an F# MVP, I can tell you MS is committed to the primary functional language on the .NET stack, but more importantly MS has open-sourced F# https://github.com/fsharp/fsharp. The membership of the FSharp Software Foundation http://fsharp.org/ is very active and growing under the informal leadership of Don Syme. F# works today across Linux, iOS, and Android with a community of OSS programmers improving x-platform interop almost on a daily basis.

Thankfully the compiler is open source and there's a thriving community outside of Microsoft (see http://fsharp.org), so this shouldn't be a big worry. And Microsoft hasn't shown a lack of commitment thus far (in fact, with the Visual Studio 2013 release F# gets new features but C# doesn't, as I recall).

Don't use F# but up voted it nonetheless, for TypeProviders alone (waiting for it in Scala...for @2 years now)

You can tell this is a bullshit poll by how many people like C. Don't get me wrong, it's a great language, but there's no way there are that many people programming in C. It has as many likes as JavaScript. Rather, people just voted C because it's a favorite language and it usually has positive press around Hacker News. So people vote what's popular and hip, despite probably having never stepped out of their web development languages (PHP, Ruby, Python, JavaScript, etc.) bubble.

>>but there's no way there are that many people programming in C

Do you have any idea how many embedded systems and performance related software is written every year?

Yeah, I find the popularity of C on nerd forums in the past few years completely baffling. Writing all your data structures from scratch is a nice educational exercise and all, but it's incredibly tedious when you're doing actual work.

25 Dislikes for D? I didn't know it had so many users. :)

Reminds me of the ironic brag at Dconf: "We have people who program D against their will" (http://dconf.org/2013/talks/clugston.html)

I can see that there's visible hate for Perl.

As a disclaimer, I'm not much of a Perl programmer, though I intend on sharpening my skills with it after I'm done with a few other projects.

It appears that it's been trendy to hate Perl for a while now, with the often repeated argument that it looks like line noise.

Yet I've seen plenty of people praise APL for its obscure design, even though it is the definitive unreadable language. To the uninitiated at least, but that's the point. I haven't used it, but I don't hate it, and I think it deserves praise for being a non-Von Neumann language.

The thing is, Perl is pretty much the hacker's language. TMTOWTDI, although allowing for inconsistency, also makes it a highly flexible tool and allows for people to hack together code, be it prototyping or for real use, fairly quickly and to their own preferences. With first-class regexes it's also invaluable for text processing and sysadmin tasks for which a shell script becomes tedious.

The CPAN is also exhaustive and has solutions for so many tasks, making Perl a very tempting language for scripting and general problem solving.

Ultimately, Perl is a tool and it serves a very good purpose. It has the potential for abuse and its philosophy is based on individuality and being able to take several approaches, but that's what makes it beautiful.

Letting go of the line noise mentality and getting to know the language better helps.

This poll should be more specific with Visual Basic. There are a few different languages that share the name VB.





And honestly, VB6 and VB.Net both get a bad rap. VB6 excelled at what it was designed to do, it was an easy-to-use language that was the fastest way to get a GUI up onto the screen and throw together a simple program. I learned on VB4 and it was great. It was the whole COM thing and the serious enterprise perversions of it that ruined the language.

VBA and VBScript, on the other hand, are abominations - the lack of an exception system is excruciating.

VB.Net is basically a few #Defines away from C# and has most of the nice functional features of C# they added in .NET 4.0. It's easy to read and powerful. Plus, the "Handles" keyword makes coding event-driven OOP objects quite pleasant.

My only problems with VB are the non-short-circuiting Boolean operators (so you have to write AndAlso and OrElse for short-circuit instead of And and Or), the bizarre +1 array sizing (but you should be using lists instead of arrays anyways so it doesn't matter) and the anachronistic Dim keyword. Even the option-strict thing makes sense because there are some cases where static typing is excruciating if you're just hacking something out - "oh crap, I have to use this terrible .net 1.1 library that predates generics, either I have to write a zillion typecasts or I can just go with dynamic typing".

Given that the VB.NET side of Roslyn is written in VB.NET, I can probably say I've hacked on the largest modern VB codebase in existence.

As someone who has had never looked at any form of VB before this: meh. It's basically C# with a... unique syntax.

There are a few things that VB does better though: type inference for lambda expressions and exception filters.

Yes, there are some backwards compatibility artifacts in the language. I like how verbose it is, little room for ambiguity when sharing code with lesser-experienced programmers. C# is efficient, but a bit cryptic for people not well-versed on c-style languages. Also, curly braces.

I think curly braces are perfectly clear, to me the big problem with C-derived languages is the use of cryptic Boolean operators. The SQL-style "And", "Or" and "Not" Boolean operators are far more legible than "||", "&&" and the easy-to-miss "!".

I can also break out Lisp into Arc, SBCL, Emacs, Chicken, Racket but I have to draw the line somewhere.

Also historically VBasic has not garnered many responses thus the catch all.

Some VB variants like VBA, VBScript, and VB6, are indeed similar enough to be grouped into a single item, I'll grant you that. VB.NET, however, is not. It's basically C# in VB's clothing. It kept the VB name and some of its syntax to bring VB6 developers into the world of .NET.

So, IMHO, grouping VB.NET with VB6 would be like grouping C, C++, and C# together just because they have a C in their names.

VBA and VBScript (iirc) have only On Error Resume Next, while VB6 has On Error Goto. This is a tremendous difference in how you structure your program's error handling.

VBA in MS Access has On Error Goto.

Oh, I might be getting VBA confused with VBScript then. I know VBScript only allows you to crash or just continue on an error, whereas full VB6 lets you On Error Goto Errorhandler and you can provide an Errorhandler label for your error code.

What about Java and Javascript? :)

There is a Scheme option for Racket/Chicken

This poll seems to give considerable credence to Stroustrop's Law: "There are two kinds of programming languages: The ones nobody likes, and the ones nobody uses." Popular industrial languages like C++, Java, ColdFusion, PHP, and Cobol rank horribly, while niche languages like Lisp, Ocaml, Haskell, and Erlang or emerging stars like Go, Clojure, and Scala rank highly. Even Objective C, which was a cult favorite before Apple made it popular, now has more dislikes than likes.

My pet theory on why this is is that when a language becomes popular, people have to use it against their will. Everybody who uses Haskell likes it, because there is basically no reason to use it if you don't like it. Not everybody who uses C++ or Objective C likes it, because there are many reasons to use them (eg. getting paid) that don't involve liking them.

There are a couple of exceptions: Python and C consistently rate highly despite being widely used, and Rexx and Groovy consistently rate low despite being virtually unknown. The latter might just be bad languages and the former really good languages; actually, this poll seems to be pretty good evidence that the old combination of Python + C for apps is a pretty solid choice.

Funny, I'd say I like functional programming... and yet I disliked all the functional and/or lisp-like languages that are the bees knees these days... Scala, Scheme, Clojure, Haskell, F#, ... All of them have neat sides, but I'm not really productive in any of them.

There are things like too-clever type systems that get into your way, instead of catching errors. Constness can be silly in C++ if you are not careful, but that's nothing against the situation in e.g. Haskell.

Then there is type inference, which really scares me. When I write (in pseudocode):

fun add(a, b) { return a + b; }

the meaning can change depending on how this is called at a different place in my code (e.g. with strings or ints as arguments). On the one hand, this confuses me - if there is a conflict, it can be incredibly hard to debug. On the other hand, the compiler can get confused. If I call add(get_number(x), get_number(y)), I know that a and b are going to be ints, but the compiler might be unable to infer this, depending on how complex get_number is. Type inference is magic, and IMHO often not worth the saved keystrokes. I'd rather have my language use a Variant type when no type is specified (and sure, when it can infer the type, use it as an optimization).

I've heard a few interesting arguments (mostly by Gilad Bracha) against type-dependent semantics, though I don't think these arguments usually apply in this situation where you're just talking about polymorphism in (+). The argument is that if your language doesn't have type-dependent semantics then you can plug and play type systems as completely independent static analysis tools.

I don't know that I buy that those tradeoffs are best, but there is something really interesting there.

That's because having + perform a non-commutative operation like string concatenation is an abomination.

But in a situation like that, you could just annotate the type. In Haskell:

    add :: Int -> Int -> Int
    add a b = a + b

What's Shell?

If you mean Unix/Linux shells, you should have picked a couple, or just used Bash, because many people would upvote one shell and downvote another. Csh, Bash, Zsh are completely different when it comes down to what you like or dislike.

I like Fish. I dislike Bourne Shell. There's no way to express this.


Shells like rc have much more different syntax (and are arguably cleaner) than common ones like Bash.

"Raise your hand if you hate PHP" many hands go up

"Keep your hand up if you've actually built a project using PHP" most hands go down

But my coool poooints!! I need to show the guys I hate PHP so they won't think I'm a newb!!

Not in my experience though. The people who do like PHP are the ones who started with it and didn't use it too much yet. In my exp. a lot of ruby/python/node.js devs are former PHP developers who built several websites using PHP and switched because they got pissed about PHP (or stuff that is related to PHP).

More interestingly imho is the percentage of people who hate PHP but still use it most of their time, since they can't find projects with other languages. I bet that's a lot of people...

I like Symfony2, I hate PHP. PHP has changed a lot in the last couple of years. The quality of libraries and ease of installation skyrocketed. We learned to avoid certain PHP features or built workarounds on top of them. Therefore I still hate the PHP for that. "extract" function anyone?

I like PHP. I've coded in it (and other languages) for more than 10 years. I love the ease of use and the flexibility it offers.

I must however add that, like a sibling comment, I think modern frameworks like Symfony 2 is the way forward for the language in a modern web stack.

I agree with you. Working with Symfony2 has dramatically changed how I work with PHP for the better. I know one of the major complaints people have with PHP is that developers often write poor code but it really doesn't have to be that way.

7 years of PHP projects: old, messy, legacy and new and fresh. I loathe PHP and never want to use it ever again.

Most I've talked to in person (yes, plural of anecdote is not data, etc) hate PHP because they've had a wonderful first-hand experience with it. This is in Sydney (Australia), where Ruby and Node is a relatively recent phenomenon compared to SF and the like.

Your post could do without the shitty attempt at sarcasm, but you've likely figured that out already.

I voted dislike to PHP despite not having used it. I read an article listing a fairly significant number of fairly fundamentally broken thing and gotchas many of which fail silently and keep running corrupting data and I decided that I didn't want to go near it.

I don't want to use it and even go to the extent of avoiding open source software that does. It isn't about cool points but purely about whether I want to use the language.

I like types and type checking and halting with exceptions on errors. Do I think that makes me cool; no, but it does make me dislike PHP and use Postgres rather than MySQL (even before my Oracle aversion became relevant).

Edit: This was the article: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

There might be some truth to your comment, however, the way that you wrote it makes it look like this:

"Most people who disagree with me do so because they're immature, not because they have an informed opinion, so I'll just make fun of them."

And that doesn't reflect well on you.

Actually, my dislike of PHP is entirely based on using it. If I hadn't had to "build projects" in it, I wouldn't care one way or the other.

Oh, I'm doing worse. I'm actually maintaining a project using 1999-era PHP.

My deapest, deapest sympathies. Up until a few years back I was doing the same. It was the most unproductive years of my life.

I'm also in this boat.

Luckily it's just a small backend part of an application that got brought along. That said, I've spent an inordinate amount of time with it given its size.

I used PHP when it was PHP/FI, that's "personal home page form interpreter" for you young 'uns. No-one calls me a n00b.

PHP haters are hysterical, I mean that in the clinical sense. It is powerful, flexible, blazing fast (relative, I know), and arguably the easiest (or at least most accessible) language to learn. Its flexibility is what generates most of the hate. It gives you the freedom to create some really bad/stupid code, which noobs inevitably do. But hating it because it will let you hurt yourself is like hating a table saw because it can cut your arm off.

A table saw doesn't try to disguise its blade as the stop button...

My favorite bug to date? Uninitialized variables being interpreted as strings. That's the one I get to debug for clients on a regular basis. "Why can't I make this DB connection?" "Because you forgot to initialize the variable containing the database name."

I actually hate it because it's not flexible enough. I did a few years of PHP dev and maintenance after learning and using Perl first. There's enough superficial similarities that it really makes the warts stand out. Every time I wanted to simply use a map, grep, anonymous function, or multiple items returned from a function, I was reminded of how much better it could have been if a bit more forethought was put into it.

I'm not really sure it's fair to say that people hate PHP because of its flexibility. Many other languages are very "flexible", and much more so than PHP for some things (you're less likely to do dumb threading or malloc mistakes in PHP, for example).

I think it's because PHP has a much larger surface area of questionable decisions to attack. When your core language is very, very small (e.g. Scheme), you have less to criticize, but when PHP has everything and the kitchen sink, plus a lack of an overarching philosophy or standard, plus a broken core developers community, it simply generates many more hatable things.

I don't hate it, I just find it hilarious to have stuff like == and === ; the old 'mysql_real_escape' (I think now fixed) and other stuff like that.

I wouldn't want to engage in a big project in a language as unstable as that.

The obvious counter point is that most people who hate PHP quite like C. But C more closely fits your description of "freedom to create some really bad/stupid code" than PHP does. People hate it because it makes it more difficult to do things well, not because it makes it easy to do things poorly.

many, most - weasel words

smart words. making sweeping claims about nearly anything is real dumb.

>Anyone who disagrees with me is just ignorant!

Do you have any evidence to support that notion? I find it quite the opposite. People who spent a decade being forced to use PHP know the language well, and dislike it. People who have never bothered to learn and just keep making the same mistakes over and over again defend PHP fervently, despite being almost entirely ignorant of the problems with the language.

>I'll invent a position from whole cloth then present it as a quote the parent comment to turn him into a straw man, then I'll have a debate with that straw man. Then I'll kick a puppy!

Why would you do that?

If you read my comment you'll note that I said "many hands go up" "most hands go down." I'm not saying everyone who dislikes PHP hasn't used it, merely that there's a large number of people here who dogpile on it for no reason other than "it's popular to do so" or "I'm half way thru _why's Poignant Guide so I'm pretty sure that qualifies me to comment on every programming language and why it isn't as good as ruby."

Please note that: a) I use PHP but I'm not a slob, I critique bad PHP freely[0] and b) people are coming out of the woodwork saying 'yeah I don't use PHP but I downvoted it'[1] so I think it's fair to say my original assertion (many people are "disliking" PHP from an uninformed position, merely because it's popular) stands.

[0] https://news.ycombinator.com/item?id=6510051 < note how this thread goes from (in my opinion) a salient, relevant discussion of the codebase and how to improve it to "durr php suxx" circle jerk in approximately 2 comments.

[1] https://news.ycombinator.com/item?id=6528073 "I voted dislike to PHP despite not having used it."

EDIT: trigger warning- more sarcasm | Here are some more thoughtful, informed, salient comments about PHP that really add to the discussion and aren't just "lol php suxx amirite??":




1) his comment was a reasonable paraphrase.

2) if you'd said "many" instead of "most" your later points would hold better. What basis, aside from hopefulness, do you have for assuming that most people who have a bias against php haven't used it? After HTML, CSS, and JavaScript it is the most ubiquitous language for the web: ergo, most web people have probably had exposure to it.

My bias: I hate php. I've deployed a few dozen sites that use it over the years.

You didn't address my comment at all. You are making the baseless claim that most criticism of PHP is out of ignorance. I am countering your baseless claim with a baseless claim of my own: that most defense of PHP is out of ignorance, and most criticism is out of knowledge. Linking to you whining about people disliking PHP does not support your claim.

dewd, did you read anything? "most criticism of PHP is out of ignorance" nope, I suggested that many of the people who "hate php" on this site (i.e. where this poll is taking place) haven't used it. If you want to claim it's not popular to bash PHP on this site, talk to me when your head is back in the sunshine.

"Linking to you whining about people disliking PHP does not support your claim." What are you even talking about? I don't link to any of my own whining. I linked to 1) me, CRITIQUING some poorly written PHP to show that I'm not just some clueless PHP fanboy 2) someone in this very thread explicitly confirming my suspicion- they are downvoting PHP w/o ever having used it even one time, but because, quote, "I read an article" and 3) several examples of vapid, worthless comments bashing PHP for no reason other than to say "PHP sux high five!!" These are evidence of the trend towards mindless PHP hate on HN that you seem... not to recognize.

If you want to criticize PHP, by all means, criticize it! Talk about a feature you don't like or a bad experience you had, but "fuck php amirite??" circle jerk is pointless & stems from the cool-bros-hate-php culture, not from an informed position. If you're informed about why php sucks, share your information! If you have nothing to share, why clutter up the thread everyone will "phpsuxlol" bullshit?

"I am countering your baseless claim with a baseless claim of my own" ok....

>"most criticism of PHP is out of ignorance" nope, I suggested that many of the people who "hate php"

Yes, you said most. Go read your post again, or your response where you quoted yourself.

>but "fuck php amirite??" circle jerk is pointless & stems from the cool-bros-hate-php culture, not from an informed position

It is also nonexistent, so not much of a concern to anyone but you.

>If you have nothing to share, why clutter up the thread everyone will "phpsuxlol" bullshit?

Where did I do that again? You seem to be forgetting that you started this discussion, by preemptively calling out nonexistent "PHP haters" as ignorant.

What is it about CoffeeScript that people don't like?

It's near unreadable. It's optimizing the wrong things, prettiness (I don't think it's very pretty at all) and keystroke counts, vs readability, fewer errors and maintainability.

It also bugs the fuck out of me that CoffeeScript projects frequently end up being given a *.js extension in the name and how often people who want nothing in the world to do with CoffeeScript, people like me, end up having to deal with it for some reason. Like I don't like ada, and I never have to look at it. ada never ends up in my editor or on a github page I'm looking at, but frequently someone puts CoffeeScript somewhere where someone was expecting JavaScript, like a StackOverflow answer, or a package for Meteor, or something. If CoffeeScript stayed out of my life, and I out of it, I would probably hate it a lot less.

It's not that it's transpiled. I mean that isn't a great thing, but for example I like the idea of Dart and even TypeScript. But CoffeeScript? No thanks.

    > [...] how often people who want nothing in the world to do with CoffeeScript, 
    > people like me, end up having to deal with it for some reason. Like I 
    > don't like ada, and I never have to look at it. ada never ends up in 
    > my editor or on a github page I'm looking at, but frequently someone 
    > puts CoffeeScript somewhere where someone was expecting JavaScript, 
    > like a StackOverflow answer, or a package for Meteor, or something. 
    > If CoffeeScript stayed out of my life, and I out of it, I would probably 
    > hate it a lot less.
As the creator of CoffeeScript — I think your answer here is right on the money. It's a pretty perfect answer to joeblau's question.

First thanks, Coffeescript saved me days of work.

But I can understand , because it's popular , some people feel like they are forced to understand or learn it.

Yet you can be proud that Coffeescript influenced the latest ES spec, that's all that matters , you pushed Javascript forward, by saying "Dont wait for other to make the stuff you need, do your own stuff and eventually people will wake up and adress your intial issue".

Hear hear!

I'll never forget reading a blog post [0] by Brendan Eich in which he addressed upcoming ES features that were influenced by or emulated Coffeescript syntax.

It was a pretty solid Krusty the Clown reference on his part.

[0] https://brendaneich.com/2010/11/paren-free/

After using CoffeeScript for a few months I find JavaScript harder to read. Of course something foreign to you is going to be harder to read.

>It also bugs the fuck out of me that CoffeeScript projects frequently end up being given a *.js extension

If a project compiles down to Javascript and is intended to be used as such, a .js name suits it regardless of the source language.

Well since you can compile python, clojure, etc etc to JavaScript I guess the .js extension is meaningless. In my opinion it isn't at all OK, because a .js extension means that the code is in JavaScript, so that I can look at it, and maybe contribute. I'm not interested in CoffeeScript widgetmajigs that turn CoffeeScript into JavaScript. Use .coffee or maybe CoffeeScript just can't stand on its own. Maybe it's just riding JS's coattails and the moment it separates it becomes abandoned.

For the project, possibly. Not for an individual source file. That's bananas.

As a side note, I dislike the use of the term "transpiled."

A compiler is a program which translates between two programming languages. CoffeeScript -> JavaScript is just compilation. There is no need for a new word.

Most of the time, it's easy to ignore programming languages that you aren't familiar with. In day to day programming life, you're not going to be running into many examples of Eiffel, or Dylan, or D or E, in the wild. So you're not going to feel very strongly about them, either pro or con.

For better or for worse (I think for the better), CoffeeScript is fully interoperable with JavaScript. The runtime characteristics and the lowest-common-denominator ES3 support are such that you can use it just about anywhere you might want to use JS. That, and a modicum of success, means that JS programmers sometimes stumble across it in unexpected places, only after popping the hood. e.g. "I thought I was just using a simple library -- Eauggh! What is that stuff down there!" This makes it very hard to ignore...

As a JavaScript programmer, you're forced to ask yourself the question, "Why haven't I given CoffeeScript a real try yet?" Not all, but a large part of the dislike comes from folks rationalizing their response to that question to themselves.

tl;dr, CoffeeScript is almost perfectly situated to inspire fear and loathing in JavaScript programmers with closed minds.

Ah okay, that's a pretty interesting review. I was at an AirBnB Tech Talk and Isaac Schluetter (Head maintainer of Node.js) and he discussed his feelings on it. I've used it a few times and it's been fine, but I never felt compelled to learn it.

[1] - http://www.youtube.com/watch?v=zM-gUM9C5SA&feature=player_de...

There's nothing of substance in his response. When asked what's worse or more ambiguous about CoffeeScript, his answers are:

1) That people who don't know CoffeeScript have to use CoffeeScript when they encounter CoffeeScript.

2) He thinks require might have been implemented differently, though he thinks that maybe that might have been changed, but "I don't really use it so I don't really know."

I frequently experiment with new programming languages (go, Rust, others) and I like Dart and have tried it. That's significant evidence that I'm not close minded. However CoffeeScript was at least for me the first of its kind, so maybe my negative perception has stuck with it unfairly. I do find it hard to read, but I'll tell you what I'll give it a try. :P

I found it a little awkward to read at first, but that went away in a short time. I suggest giving it a proper whirl. Most people who I've introduced to CS seem to really like it.

CoffeeScript is only syntactic sugar. It brings very little new to the table, but perhaps worse of all, it doesn't really fix all of JavaScript's WTF-issues while adding a few of its own. While it's an improvement over JavaScript, its advantages are sometimes outweighed by the extra hassle to compile and deploy it.

I don't really dislike it but I really do not see myself using it if I had a task where I needed JavaScript.

Suprisingly, I have never even thought about compiling on Coffeescript since my rails app does that for me. Personally, I love using Coffeescript because it's just so much easier to write compared to javascript without thinking about braces and semi-colons. On the whole, I guess what framework you use affects how you use a language. In rails projects, it's very efficient to use coffeescript over javascript.

The problem is that sometimes what you write in CS results in surprising and/or incorrect JS.

This can be caused by an unnoticed block of whitespace, corner case of CS language itself, or me simply screwing something up.

About 5-10% of the time I hit a WTF in CS, which is, for now, an acceptable trade off vs. using pure boilerplate ridden JS.

If there was a concise TypeScript a la Scala for Java, I'd be all over it.

The syntax is broken. Things like operator precedence and associativity are the exact opposite of math conventions:

    f x + f y    // is f(x + f(y))
    f g x        // is f(g(x))

Not quite -- the rule is pretty simple: Implicit function calls associate to the right, to the end of the line (or the end of the trailing block). This allows you to write code like this:

    console.log inspect value

    model.save(attrs).then ->
      ui.update attrs

    rect.scale height * factor

... and have all of the results come out correctly, while leaving the code readable. If the rules were "more math-like" as you say, then none of that would work. Perhaps it would harmonize with special libraries that used functions (automatic-partial-application a-la Haskell) in a different way than JavaScript does ... but that's not the world we live in. It's gotta harmonize with JS functions as they exist.

I'm not sure where the idea originated that readability scales inversely with the number of parentheses, but I wish it would hurry up and die.

I'm not sure where the idea originated that readability scales with the number of parentheses, but I wish it would hurry up and die.

I'm not sure where the idea originated that readability scales, but &c., &c.

My brain isn't plastic enough to make this switch. :( For me, those code examples are uncomfortable to look at. backwards read to trying like It's

Right-o. The trick is to "read" it like pseudocode, or like English-ish.

    Log the inspected value.

    Save the model, then
      Update the UI with the attributes.

    Scale the rectangle by (the height times the factor).
The big syntactic difference still being the "model.save" vs "save the model" ordering of dot-notation. But them's the breaks.

I don't understand what's wrong with the second example. What do you think it should do?

In ML-family languages like OCaml and Haskell, function application is left-associative: f g x = (f g)(x).

I guess some just dislike the idea of sugaring Javascript. Others my think that it hides something that can bite your ass, though imho the oppossite is the case. For me personaly after spending some time with CoffeeScript writing plain JS was a displeasure for sure.

Very interesting that people are saying things like "significant whitespace" and "too similar to python" - I personally love Python and I like that coffeescript bears some resemblance to it. I voted "Coffeescript - Like" because it removes many of the mundane aspects of JS programming.

Definitely doesn't solve many of JS's problems, but it certainly makes things easier when writing client side apps. We use it a lot for Backbone development.

It's a quirky dialect of JavaScript, which has very little to offer. There is less typing, but that certainly wasn't JavaScript's biggest issue.

With languages like TypeScript, or Dart, you also reduce the amount of typing work, but that's just a side-effect of the good tooling these languages have to offer. You can auto-complete everything.

It makes a lot more sense to boost productivity via structure and tooling, because that's what really helps with scaling.

Personally I'm ready to start filtering anyone that prefers JS over CoffeeScript. Its just about superior in every way. Maintainability goes up as the lines of code drop precipitously and significant whitespace, come on guys. I use bracey languages all the time, and moving to one that doesn't isn't that big a deal.

The real problem is there are a lot of "developers" that came up just doing simple Javascript functions. They know their functions, and they dont want their world to change. They would rather accidently reference closure or global and type significantly more code than learn a slightly different way to code Javascript.

Complaints such as "extra hassle due to compilation" are laughable honestly. If adding a build step is an extra hassle, this might be the wrong profession. Tinkering should be in your nature!

CoffeeScript super charges Javascript. Any truly competent JS programmer that gives it a try for a few days would realize it.

"If adding a build step is an extra hassle, this might be the wrong profession."

That's a very railsy answer. The strength of the web is that you don't need to run a build at all. I think that's the fundamental dislike of Coffeescript. I've worked on so many html frontends where a build process wasn't necessary to accomplish our job, and if someone tried to introduce one for the sake of coffescript it would simply be an annoyance.

I'm currently using CoffeeScript for a big project on the web and the build step that I have automatically watches my coffee files and recompiles on a new change. Group that with using LiveReload and you have an auto recompile and reloading application with no additional manual build step.

It's also that you lose any ability to step-debug at the moment. You still need to know Javascript to debug Coffeescript by and large.

That mental context-switch overhead is the whole driving philosophy behind NodeJS in the first place - don't switch languages so often. CS/JS is enough of a change that the overhead is not insignificant.

Eh, I don't find switching back and forth to be that problematic in terms of context switching. That's because CS is very similar to JS in everything but syntax. Which is also why a solid JS background is almost essential when writing CS.

This is no longer true. You can debug CoffeeScript in web browsers now with source maps. Yes you may need to dig into JS for a more severe bug but most of the stuff is debug-able in source maps.

The problem for me is not technical per se, but that it adds another element of complexity to an already complex programming environment and has implications for human resourcing.

Becoming expert in a new language goes beyond learning syntax; one must also learn code conventions/style, compiler/transpiler quirks, runtime quirks, and library/framework ecosystem. In CoffeeScript the last two may be moot, but the first two remain. Additionally, to be an expert in a transpiled language, one must be an expert in the target language. It is much harder to find someone that has this knowledge and experience in both CoffeeScript and JavaScript.

This begs the question of each web dev team: if you are already experts in JavaScript, is the value-add from the transpiled language worth the cost of increased solution complexity/cognitive load, and smaller talent pool? My take is that CoffeeScript doesn't meet that bar for most teams.

For individual projects, or isolated one-off tools, these non-technical issues are moot. Also, server-side may be less of an issue since complexity is reduced by not having to write for multiple runtimes (only Node.js and usually without DOM).

Fixes a non-problem.

Ok, so Javascript has a bunch of gotchas but it's an interesting language which I both like and dislike but I don't dislike it enough to add yet another layer to my dev platform.

Also, as someone stated elsewhere on this page the true solution is to make a browser virtual machine and use any high level interpreted language you want.

Debug story perhaps? I haven't tried it but that's what puts me off.

Significant whitespace

My opinion is that it ended up causing more problems than it fixed. In theory is nice and beautiful, but once you start using for large projects you notice that it kills readability and introduces some other small problems.

I think some people still like wasting their time by writing "real" code from the start.

too similar to python

Not enough if you ask me. As other commenter said, too many JS-WTFs remain.

Not at all. I love Python and I don't like CoffeeScript. I think CS superficially looks like Python, but conceptually is more like Ruby/Perl.

It was a good idea but failed in execution. It might take fewer characters to type an instruction but at the cost of what? Being difficult to read? Ambiguity? Not really worth the time.

Any unfamiliar language is hard to read and will have seeming ambiguities.

In my experience working with CoffeeScript, I've always found well-written code easy to read with no ambiguities.

Applications are open for YC Winter 2024

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact