Hacker News new | comments | show | ask | jobs | submit login
What are some of the most disliked programming languages? (stackoverflow.blog)
93 points by fao_ on Nov 1, 2017 | hide | past | web | favorite | 159 comments

I dislike R. As in, design and performance wise. But an alternative often doesn't exist. So i am kind of saddened to see it so "liked".

You can best be sure as hell I wouldn't be listing it as something I hate on any of my applications/resume though :P Try getting away from it in my field. Not least because of the err...positive over-zealousness...of the R community. I used to joke that the main difference between R/Hadley (no offense Hadley) and Jesus was that some of Jesus' followers admit he might have made some mistakes.

Also git. Look, i like it. I use it almost every day, but I'll be damned if i trust anything that says its universally loved/not loathed.

I feel there's another dimension to this data not being captured/expressed, but I'm genuinely struggling to verbalise what it would be...

Git is probably a technology people don’t feel comfortable criticizing because they think whatever problems they have with it are due to them not properly understanding it. I suspect that they feel like disliking it is akin to admitting ignorance. I have this intuitive feeling that git’s design suffers from unnecessary complexity. At some point someone will come along and make an easier to use dvcs, and git will fall out of popularity like cvs did when subversion showed up.

Having now used a number of other VCS tools (Perforce/Piper and Mercurial), I still think git intuitively gets the "model" right, better than the others, but goodness the API naming makes almost no sense.

Git is a very sophisticated and substantially well built tool, with several key weaknesses that border on fatal flaws. Unfortunately, too many of the people in control of git's fundamentals and ux don't recognize those flaws as such and refuse to fix them. This has a bizarre consequence of causing many who also see git as one of the best VCSes out there to fail to see those flaws clearly as well due to groupthink. Unfortunately it will likely be years and years before they're seriously addressed.

> with several key weaknesses that border on fatal flaws

What are you referring to?

Besides the infamous CLI

1. Terrible command line interface

2. Submodules and worktrees being bolt-ons

3. Simplisitic branch namespace forcing repos to be used as semantic concept

4. Lack of O(1) incremenental checkouts.

The good news is a reimplentation could solve all of these but the namespace probablem, which in turn could probably be a very lightweight protocol extension.

I imagine the terrible command-line interface is one.

The UX in general is a mess. There are odd inconsistencies between how things are named, how parameters are used and what they're called throughout the CLI. For example, sometimes you use remote/branch sometimes you use remote<space>branch to reference a branch in a remote. It's a little thing, but it adds up along with everything else and is effectively a tax that uses up mental capacity that could have been better spent elsewhere.

Additionally, the whole workflow around branching and rebasing is pretty terrible. Almost every demo I've seen of how cool and useful rebasing is inevitably runs into some huge fuckup that has to be backed out of carefully. It shouldn't be that hard, even in complicated situations that happen less often but are still common enough to happen routinely.

In a similar vein, the tooling that git (and github) provide for merging and merge resolution are terrible. They work only in the simplest cases, and for anything beyond that they just start to fall over. Almost every developer who has used git has ended up in a situation where git fucked up dealing with a merge conflict so bad that they had to just do the work manually by opening up some "base version" of a file then meticulously applying diffs by hand coding and then figuring out what the final file should look like starting from there. I've used a lot of different VCSes over the years and git is surprisingly one of the worst at this workflow. It relies far too heavily on commit history to figure out the right thing to do and it doesn't even leverage that as well as it could. VCS tooling should help the user, not shove them into the middle of a bunch of machinery and then force them to do all the heavy lifting to make things right.

Code reviews and branch management are also very weak in git/github, for no good reason. Again I've used a ton of different alternatives, some of which were just internal tools built by random folks in the company, and almost all of them were superior to the experience with git. Given that merging and code reviews should be where git/github shine, this failure makes zero sense to me.

Good tools do the monotonous grunt work heavy lifting for you, they make easy stuff trivial, hard stuff easier, and they help you manage the complexity of the really difficult stuff. Git does a good job of this sometimes but when it fails it fails hard. Git is like a multi-million dollar yacht that has some components held together by gum and bailing wire. And when you run into those parts you look around with an expression on your face of "can you believe this shit?" and yet only a tiny fraction of the people around seem to see what you see, all the rest seem content to just ignore it, imagining that that's just the way that all super yachts are built, or something.

There are so many ways that it's easy to just be doing normal day to day stuff in git and end up in a bizarre state that causes your productivity to come to a halt while you figure out how to fix it. Detached head? Uh, how did you get here, what does it mean, how do you get out of it, how do you ensure you aren't accidentally destroying work? Failed rebase? Poorly handled merge conflict? Even simple stuff like reverting local files or rolling back commits is harder than it should be. And the fact that "git push --force" is ever, ever, ever seriously recommended, ever. All of these things could be vastly improved by taking the time to do some quality of life improvements, but the git maintainers think that there's nothing wrong with operating a tool that is half luxury level fit and finish and half exposed razor sharp gears and live uninsulated wiring.

Git is a technology people don't feel comfortable publicly disliking because the obvious alternatives tend to be even worse.

You don't put things on your "won't use" list because they have design problems, you put them there because you want to use something else that you like better; so decent things get disliked because you simply prefer a different style but horrible things get accepted if there's no better choice.

> Also git. Look, i like it. I use it almost every day, but I'll be damned if i trust anything that says its universally loved/not loathed.

git is damn annoying! Been using it on an almost daily basis for over five years but its error messages and other idiosyncrasies still makes me feel like a total newbie.

As a complete guess, I think a clue to what might be missing is in the like/dislike pairings analysis at the end of the article.

It wouldn’t surprise me if a lot of the (dis)likes are relative to something else. So, for example, the view on git is relative to svn or cvs. If that is the case then a generally positive outlook (outside certain niches) is less surprising.

In the same spirit I have a hate for LaTeX. The dazzling errors together with the unclear syntax makes the language very annoying to work with.

I get the dazzling errors, but what unclear syntax are you referring to? And how would you make it more clear?

I hugely dislike being compared to any religious figure. I don't have "followers", and the vast majority of people who use my work understand that it's just one way to do things.

The tidyverse is far from perfect, and I hope it obvious that I acknowledge my mistakes, particularly through evolving APIs (e.g. reshape -> reshape2 -> tidyr + dplyr).

Sorry Hadley. I genuinely admire the work you've done. My analogy is not intended to comment on you, or the tidy- verse (indeed, I think it's fantastic that you're one of the first people to even start talking seriously about what tidy data is), just like my comparison to Jesus isn't meant to actually comment on his life. I'm commenting on the community that follows.

And there it's basic "life of Brian".

You don't want followers.

Doesn't mean you haven't got them. And it doesn't mean many of them aren't ignorant of anything outside of R/stats...

In fairness to Hadley, his tidyverse reshapes the R language from a horrible artifact of the 80s into a useable semi-modern environment.

I don't think there are that many statisticians who were up to the challenge. My experience integrating his work was feeling 30 odd years of programming improvements hitting my workflow. He deserves great praise for that service.

Understand, i think his work is both impressive and admirable. But significant parts of his (and other's work) is best specifically where it makes things more "non-R" like.

Its a section of R users i think have a mildly disturbing religious-esque zeal.

To be fair, I even understand some of it. You put up a bad thing in SAS or SPSS, and then do it in R in one or two lines, and suddenly "everything looks awesome".

I'd love to know what in particular you think is particularly "non-R" like.

As the above poster mentions (and I'm guessing since he mentions it, I'm not the only one holding onto this opinion), what you've done is effectively shape a horrible old warty language into something practical and usable.

The two examples I would use are the explicit operations and the pipe operator in dplyr, and the replacement of base R graphics with ggplot.

Now, in a language like R, where you can (awkwardly) play with the syntax and evaluation and introduce things like the pipe operator, it's very easy to argue that nothing is making things "less like R", since it's all enabled by the language. But I think this is a bit bad faith. Take common lisp and the loop macro. It's implemented in common lisp, but I understand very well what people mean when they complain it isn't very lispy.

Dplyr takes the data frame, and let's you interact with it in a much more explicit and imperative way than base R operations on the data frame. Is this a good thing? Sure! But one of the reasons for its success is that it explicitly moves away from the style of the base R/S language.

I don’t think your point about dplyr holds weight because it explicitly draws inspiration from two base R functions: subset and transform.

And I don’t think ggplot2 is a great example either since it’s some of my earliest work and I’m actively moving away from that style of API to something based on regular function composition.

I wish someone would make this argument more precise so I could better understand it. From my perspective (apart from the pipe) I’m just taking ideas already seen elsewhere in R and trying to express them as cleanly and elegantly as possible.

(I hope your point isn’t that R is fundamentally ugly and anything that makes it more elegant is hence unlike R like)

> But an alternative often doesn't exist.

Python, Julia, Matlab, Java, Scala don't exist for doing what? Are there specific R libraries and functions that aren't reproduced in other languages?

Aside from the libraries issues...

Understand I'm talking about in the context of my workplaces and experiences, which, also in my experience, are a significant number of employers hiring data science-type jobs.

An alternative doesn't exist in the sense that we've been battling for years to get things that are more open and aren't SAS/Matlab/SPSS.

Finally we're at the stage where something is finally getting semi-approved and installed reliably and the doors are opening...and its...R.

Python is becoming more common. Admittedly. And kudos to anaconda for its non-admin requiring install. But in some ways even installing that is a bit "naughty".

But Julia, Java, Scala, C?

No no. Those are programming languages. Software companies get those. Maybe a handful of guys in IT if they need it for some reason, but many are still working in places where most IT/security staff can't tell the difference between R and RStudio. Github is blocked by the firewall and security :P

So the idea of options...maybe in another 10 years :P Until then, we take what we can get...

Julia seems similar to python, and even runs fine on Jupyter. I think https://data-sorcery.org/ (incanter) might be good JVM environment.

What can R do that Python can't right now?

Yes, R is for statistical analysis. It's absolutely great for that (similar in other languages will take 10-100x more LoC with all the possibilities for bugs it implies). On the other hand it's an absolutely awful general purpose language.

I know R is great for that, but are Python stats libraries lacking to the point of needing 10-100x more code? My understanding is that Python has caught up with R in the data science field in terms of popularity and usage.

You can also use R inside Python using the rpy2 library. And Julia embeds R with the RCall package.

It really hasn't. Python has pretty good support for machine learning on data with no missing values.

It doesn't really support things like survival analysis, complicated time series models or (the most important) missing data.

Also, R's formula interface for models is a thing of beauty, while Python has nothing similar.

So, if you have data with no missings and are only interested in a small subset of statistics (that used by computer scientists), then Python can definitely suffice.

If you are in almost any other discipline, you're going to be using R.

Don't get me wrong, Python is a wonderful language, but R is so well adapted to analysis that it will be a very long time before it gets replaced (Julia looks really promising, but its not at 1.0 yet, and hence hasn't seen the broad scale adoption it would need).

It's not just that. R has a few things going for it:

1. It's a functional language, and functional programming style lends itself really well to matrix operations (and the engine of stats is all about matrices).

2. Matrices are baked really deeply into the language, which makes the functional style even more powerful. (my understanding is that what makes the formula interface work so well).

3. R can be viewed as coating of syntactic sugar on a lot of very useful fortran libraries.

On the other hand I once saw some open source toolkit for natural language processing in R. I had two issues with that. Firstly WTF was the author thinking doing all his general purpose programming in R. And two I didn't want to investigate further because as NLP is largely about general purpose operations and I didn't want to get sucked into that rabbit hole.

One thing I don't like about Python libraries, from the top of my head: That there is a distinction between functions and methods, e.g. between nansum(a) and a.sum() where a is a numpy array. The distinction is illogical and just has to be memorized, much like the difference between different categories of verbs in French.

In contrast, R uses an exotic form of object oriented programming called multimethods, which doesn't make a distinction between object.method() and method(object). And if you like chaining methods together like object.method1().method2().method3(), then you can do that in R using the piping operator from the Dplyr package: object %>% method1() %>% method2() %>% method3(), which is rightly equivalent to method3(method2(method1(object)))

The reason there is a distinction in Python between functions and methods is because Python supports multiple paradigms. It doesn't force the programmer into using OOP. Sometimes you want a function that doesn't belong to some kind of data type, and sometimes you want to create a new type of data and define methods that work only for it.

You make it sound like perl (only perl is more flexible - both its major strength and weakness)

So why has nobody tried to implement something similar for Python? Is there some fundamental limitation of the language at play?

Academic statisticians know and use R. They publish research in R. Python doesn't have the same mindshare, so somebody would have to specifically go out and re-implement it in Python. So far, it seems like nobody has been sufficiently motivated to do so.

You'd basically be implementing a new interpreter (and presumably trying to do so in python). And hauling in a bunch of Fortran bindings along for the ride.

Things (IMO) that R has going for it:

* RStudio IDE - none of python equivalents are anywhere near as mature

* Functional programming - I can't fully articulate why yet, but to me, FP seems like it "fits" most DS programming challenges better than OO.

* Tidyverse - I'm biased (being the author) but having a broad ecosystem of tools with shared underlying programming philosophies makes solving data science challenges particularly easy/painless/fun.

* RMarkdown - makes it so easy to intermingle prose + code and then (via pandoc) render to a very wide variety of outputs (html, word, pdf, html slides, dashboards, ...)

* Shiny - for cases where you don't want a single report but an app, an R user can quickly create an interactive app without knowing the details of html/css/js

* Very broad ecosystem of statistical packages. Most statistics researchers use R, so you're more like to see cutting edge stat research in R first.

It's not a terrible general purpose language (unless you believe that only OO languages can be general purpose). It could definitely do with more general purpose programming packages, but that's not a limitation of the language.

There are some things that still aren't available in Python unfortunately. For example, there isn't a package that I'm aware of that will do a mixed-effects logistic regression in Python.

Hey now, Hadley does really great work, IMO he's the main reason R is still worth using.

I started using R about 10 years ago, but after learning Python I came to really dislike R for how ugly it is. But I still kept using it for plotting because ggplot is so damn good.

In the past year I've started to use R more again and have started to kinda like it. It's still unpleasant for general purpose programming, but for manipulating and plotting dataframes, dplyr/tidyr/ggplot is very clean and way nicer than pandas/matplotlib.

So yeah, I think R has improved a lot since I first learned it, mainly due to Hadley, and is actually a pretty good language within its particular domain. But if I had to use it for general-purpose stuff I'd probably come to hate it again.

Yeah, I've been using R for about 7 years now.

I find it frequently unpleasant and the documentation often makes me want to stomp on puppies, but in the end, it NEVER let me down.

Hadley's Tidyverse (and RStudio) has breathed new life into R, but I wish that stuff was available in other languages. NOTHING comes close to ggplot, for example, for composing sophisticated plots with compact but expressive code. dplyr for data wrangling fits like a glove.

After you've wrestled your data to submission, you then have a vast amount statistical analysis you can do out of the box using R libraries and little effort. I don't want to like R, but I can't avoid it.

You should also check out http://purrr.tidyverse.org and http://github.com/r-lib - we're working towards providing tools that make general purpose programming more pleasant. (Not because R should ever be your primary general purpose language, but many data analyses often involve some general purpose components)

I use git explicitly via GUI client and have no problems whatsoever. Am I the only one?

I mastered the Golden Path that works 99,9% of the time together with some starred threads on Stack Overflow. But one of the devs wanted to switch to a rebase based flow and I found myself again needing to learn something overly complicated and fragile and the attempt to change to rebase kind of died because of that.

In my (very limited) experience rebase flow causes way fewer conflicts if used correctly. YMMV though.

Which client if I may ask? GitHub Desktop?

I use gitkraken and there are some annoying things in it, like awkward amend UX or inconsistent branch visualisation, but it's the only one of many I tried that I really liked.

I think R is in the early days of its demand lifecycle. Wait a decade or two (maybe less) and R will get more hate. I'm surprised how fast Julia has advanced toward being a suitable replacement for R. It's just a matter of time. Then Julia will be most hated when Language X comes to replace it.

Yes, thank you for saying it. R is so damn inconsistent and ugly it's unbelievable. It pains me that it comes now with Microsoft SQL Server 2016 and not Python which would be much more beautiful choice.

I'm no statistician, but if languages are new and upcoming, thus still have a standing chance at being fast-growing at all, on Stack Overflow, would they also be languages that aren't yet so established in corporate culture (for being new) that they aren't forced onto people, so that people gravitate more voluntarily to them, so that they are more prone to liking them, so that (finally) they're bound to be less disliked? I mean, I read it, and I went like: "duh".

This is probably why Stroustrup famously remarked "there are two kinds of language: the kind people bitch about, and the kind nobody uses."

It is easy to repeat platitudes, but the data doesn't really show it. Take the ten most popular languages: Java - slightly negative, Javascript - positive, Python - positive, C# - slightly negative, PHP - negative, C++ - neutral, C - neutral, R - very positive, bash - positive, Swift - positive.

The interesting correlation here is that languages that are on their way out seem to be more disliked (Perl, Delphi, etc.). There are multiple possible explanations, e.g.: their usage is shrinking because they are disliked; or people dislike them because they are not 'sexy' anymore.

You have to discount the age factor. Newer languages will always be growing compared to older languages, and early adopters are advocates rather than people criticizing their new chosen tool. To properly criticize something you first need to become intimately familiar with it.

Oddly, this does not apply to C++ which has been steadily growing and growing in features, yet gets criticized for being "too complicated".

Of course, you can get by knowing only the bits you need, and Stroustrup makes the excellent points in his hopl-almost-final PDF that newer languages are easier to "get into" because they haven't had years of having new features bolted on, hence they appear "simpler". A few decades down the line and they'll be in the same position.

I want to agree, but C is even older than C++ and is definitely not in the same position. Ultimately, each language is different and the way they grow is different. C++ has just never been all that conservative about admitting new features. Their primary concern seems to have been the effect on the runtime performance of the binary, not whether the feature makes sense or mixes well with the existing features, or the effect on compilation time.

This is very true. As I sit here waiting for my compilation to finish, I am reminded of the "speed" of compilation.

I have a feeling that to a large degree, what the data seems to show is not an objective measure of how good a language is, but rather "languages I was forced to work with, when it wasn't my preferred language".

The 3 most "hated" languages, Perl, Delphi and VBA, all fall into this category. The number of people actively moving towards them is probably far fewer than the number of people who are forced to pick up and maintain an ancient artifact in them, hence skewing the stats. In most cases, you can spot the pattern of old language being further to the right than the default, newer equivalent.

What would be really interesting is watching this graph evolve over time. As an example, I suspect that initially, CoffeeScript was nowhere near as hated as this, and the hate is coming from falling out of vogue and having its maintenance shoved on developers.

It seems that the survey methodology here maps more to some mix of familiarity and popularity, rather than liking or disliking. They're basing the results on the technologies people indicate as being interested in working with (that's a like) and those they're not interested in working with (that's a dislike).

People are going to "like" the technologies they know and are familiar with. They're going to dislike popular languages that they may otherwise receive numerous offers about. Relatively uncommon languages are going to receive only popular votes since there's no incentive to dislike them. E.g. nobody's getting spammed with recruiters seeking R expertise. This explains why unpopular language also seem very well liked. When considered as a ratio, there's almost nobody disliking them and a handful of people liking them.

I think javascript's position here is the most clear example of the problems with methodology. I think it's safe to say that most consider javascript a flawed and undesirable language (compare to a hypothetical alternative), but at the same time there are a zillion javascript developers who are willing to work with javascript. So the raw number of people willing to work with it for a paycheck outweighs the dislike of the language itself.

Compare this to something like C#. My first thought (before considering the above) is that its lack of popularity was a cultural issue. It's maintained by Microsoft and is probably seen by many as a more corporate and established (in a somehow negative way) language. But then scroll down to their "tag rivalries" section and the real issue becomes clear. The people who most "dislike" C# are visual basic developers!

They should have asked "what technologies are you familiar with that you wouldn't want to work with?".

Note that the data for "(dis) liked language" comes from answers to "language I would (not) like to work with" given by developers on the job market. I think those answers don't reflect so much the developers' sentiment towards the language, but their expectations about future job prospects in that language.

Not only that, but also languages you dislike enough to tell everyone who reads your CV you won't work with them, like ACow_Adonis said. I know many people who avoid R as much as they can, but would rather work with it than be unemployed.

So perl is the most disliked, and bash is one of the most liked languages? Most of people have at least some experience with bash, so they don't mind it, but perl looks scary to them. And they probably never really used any of the two, otherwise they'd notice that almost all of ugly things in perl are taken from bash.

IMHO these stats have little to do with the language itself, and say much more about the current fashion and job niches.

It's funny to see Perl on the top of that list. I was a Perl hater for so long that I don't even remember how it started. It probably has to do with the extensive use of symbols (=~, -s, -d, s/ ...) that makes code quite unreadable and the fact that it sometimes feels more like a shell or a UNIX tool than a proper language.

Recently I wrote a program in Perl after more than 20 years and I actually found it quite enjoyable. It's so easy to write scripts with option parsing that do file processing. You can even make them very readable as long as you sprinkle it with some comments alongside the tersest statements :)

But I guess if I had to write or maintain bigger projects in Perl the nightmare would begin.

Not really, because "unreadable" is a very subjective metric. When you spend some time with a syntax your brain learns to parse it quickly and effortlessly. Perl's use of $%@ prefixes to mark the type of variable actually makes it easier to understand, once you get used to the syntax.

100% agree. Another factor is that Perl is highly correlated with heavy usage of regular expressions. Those are easy to write but often pretty hard to read whatever the enclosing language (and author) :)

"It probably has to do with the extensive use of symbols (=~, -s, -d, s/ ...) that makes code quite unreadable..."

I hope you're not a fan of Haskell, which is so beloved on HN -- as Haskell's use of symbols makes Perl look restrained and moderate in comparison.

Also, there are English-language equivalents of a lot of those symbols in Perl (for instance $INPUT_RECORD_SEPARATOR for $/), and Perl programmers are strongly encouraged to use them.[1]

[1] - http://real-world-systems.com/docs/perlEnglish.html

I don't really buy this argument that Haskell's symbolic operators make it harder to read than Perl. Haskell has a very precise and simple rule that syntactically delimits operators from non-operators. Furthermore it has the type system to help you infer semantics. AFAIK Perl doesn't have either of these benefits.

Granted, there still may be too much of a tendency for Haskellers to use operators, but lack of clarity to Perl level? Come on!

Perl was meant to be used as "better bourne-shell". Why would you make "big projects" in perl?

Oh sweet summer child. You have clearly never worked on a 100,000 line web service written entirely in Perl in 1999.

Doesn't matter you cannot hate perl for doing something it's not meant to do. You cannot write Python code for a super performance critical task in a 500KHz microchip and decide that Python is a horrible language. Python is not meant to be used that way. You should use assembly or C. My point is, if you abuse the intent of languages, they all may end up horrible. It's like writing purely functional OOP code in C.

I felt the same as you, but lately I've felt an attraction to perl6. Which version did you choose to use?

Didn't really chose. After checking, perl5 is installed on my laptop. I'll admit I'm too newbie to know the differences between versions 5 and 6 :)

I love perl, but probably only because I am already well versed in it. can do a lot with it and it still is the best option for some things.

I wish perl 6 had a larger community, it actually looks very cool.

I do lots of data munging and loading with Perl. There's nothing that comes close to the productivity that Perl enables me to have.

I was surprised to see Ruby attracting much dislike. I had the impression that it was a language explicitly designed to be used by human programers to express ideas, although with poor runtime performance. What could be the reason?

I use Ruby everyday and while I definitely don't hate it, there are many things I dislike. For example, functions are not first class citizens (despite the "functional" slant to the standard library). You have to jump through hoops to do any real functional programming (and it's ugly).

The syntax has waaaay too many options. This leads to a language where 3rd party tools are really hard to write. Even at this late date, refactoring tools are mostly absent (or awful). Not only that, but it leads to serious religious wars about how to format your code (I'm sick to death of it, even though I try to stay out of it).

Modules are slightly strange. You can't really use them for namespacing without writing pretty non-standard code. They are really only useful for mixins -- which normally isn't a great plan.

And as popular as meta programming is, it's incredibly awkward. The underlying design seems completely arbitrary and is hard to reason about. Despite the many syntactic options for frivolous things, there are very few syntactic tools for meta programming -- just super long function names.

People are going to laugh, but I actually prefer Javascript to Ruby because the design is much more logical and flexible (despite the poor syntax and really terrible standard library). There are lots more things that bug me about Ruby, but I think those are the main ones. I still enjoy writing code in it, but it wouldn't be my first choice these days.

Poor performance, and Ruby likes magic. Magic methods and macros scare off a huge audience of programmers in the mainstream world. Rubyists tend to wholeheartedly embrace them, however.

Magic is exactly why I stayed away from Ruby. You have to learn some for every environment but Ruby was too much for me. Perhaps because I first saw it with RoR - which adds even more magic.

Both above and above one's parent comment is about rails, not about ruby. It's understandable that most people got familiarized with ruby because of the popularity of rails, but confusing between the two?

I've written Ruby, not Rails. In fact, most of my Ruby work hasn't had anything to do with the technologies associated with the web, they've been desktop GUI applications and server applications (like dealing with ActiveDirectory). I'm not confusing anything, I'm speaking from experience.

The Ruby community likes things that think for you, and insert methods unexpectedly, change the meaning of semantics, and all sorts of other magic designed to think for the programmer.

Ruby doesn't have macros and all the magic in its ecosystem is confined to Rails and the gems related to it. But most Rubyists are such because of Rails so that's understandable. Examples of the magic like features of Rails are ActiveRecord's auto discovery of db schema and auto creation of queries, or callbacks on the changes of status of db records. It's where programming in Rails becomes somewhat declarative.

But macros? A language with macros I'm working with is Elixir. Even the seldom used if then else is a macro there. Do people dislike Elixir because macros change the code at compile time? I don't think so.

> Ruby doesn't have macros and all the magic in its ecosystem is confined to Rails

Then what would you call the method_missing method?

> a b c

> = Name Error

> def method_missing(*args); args.join(" "); end

> a b c

> = "a b c"

That looks exactly like a macro to me.


> But macros?

Not macros as such, we all like having them. But Ruby likes using them constantly, and that culture is hardly restricted to Rails.

I see your point but Matz was clear about adding macros to Ruby:

> Macro is a great power, but at the same time, it makes the languagesyntax different for each application. You will have hard time to read the program without knowledge of the application/framework macros.

> So I am not going to add macro to Ruby.

> matz.


The funny thing is that this is what happens when we use method_missing or other Ruby features to create DLSes: unless you know the application/framework DLS you can't understand the program. They must be used wisely.

But to be fair: how can one understand a program without the knowledge of the non standard libraries it uses? This applies to every program and language, macros or not.

Macros and meta-programming aren't necessarily the same.

Contrast with Lua: equally possible to do monkey-patching, but it's considered unclean and confusing to do it in Lua, at least among the community. Generally, there is a thing we could call the 'magic budget' and it's important not to blow it too quickly.

I think this quote from Metalua's frontpage, an extended Lua for better metaprogramming, sums up that feeling perfectly:

> Don't bother developers with macros when they aren't writing one: the language's syntax and semantics should be best suited for those 95% of the time when we aren't writing macros.

An extended language to add more magic, says we don't need it most of the time.

And to be honest, it's one of the things about the Lua community I find really attractive.

Does that scare off a lot of programmers from Lisp as well? It's interesting, because Elixir, Julia and Crystal, all newish languages, include macros.

The combination of the lack of a type system and magical metaprogramming that relies on mutating classes at runtime leads to maintenance nightmares. Probably one of the more frustrating languages I've used.

I love both Ruby and Coffescript and I love magic. When you've embraced pure happiness and productivity everything else is depressing.

I'm (pleasantly) surprised that C++ isn't nearly as hated as I expected it to be. I never considered C++ to be a bad language in my experience.

I'm surprised that C# and Java are higher than C++.

Perl being #1 isn't a terrible surprise. But I think its no small secret that Perl is usually the ugliest, but most practical... language for a huge number of jobs. No one likes using Perl, but damn is it useful in a lot of situations.

Matlab would be that language I dislike (despite it being low on the list).

I am surprised with c# vs java as well, but they are close.

I code c++, javascript and java these days, and i greatly miss my c# days.

Say what you will about microsoft, but i consider C# and the default development environment in vs superior compared to what's available for other languages. That with Resharper back in the day was the bomb.

MS's devenv is excellent, and IMHO doesn't get the recognition it deserves. Folk often talk of Windows and Office as the twin pillars of MS, but I'd say Visual Studio is the third pillar. MS has always done a great job of dev relations with MSDN, cheap or free tools, sample code and excellent blogs like Raymond Chen's Old New Thing. JetBrain's IntelliJ and PyCharm, as well as Firebug and the Chrome debugger have improved things for devs outside the MS ecosystem, but MS are still ahead. Mixed language debugging in Visual Studio still amazes me. As a Python C++ dev I'd love to have a Python IDE that would enable me to debug C++ .pyds.

Heck, still is. C# is a nice, pragmatic, practical language, and the VS/Resharper combination can't be beat anywhere, period. I love how lazy it lets me be.

Funny enough, I developed libraries mostly, in both for server use (nhibernate/castle), and for client side use (windows phone), and i can say pretty confidently that development environment for windows phone 8 was far superior to what android had, too. Android was a platform for years while wp8 was really new.

Microsoft knows how to create developer tools, and languages.

It's an ugly secret that WP in many regards was the best platform out there. If it was about 90's desktop operating systems it would be BeOS out of the options Windows 98, MacOS 8 or BeOS.

But it was not only late to market but also Microsoft's PHB's managed it pretty ugly.

I'm also similarly surprised by the neutral response to C, given that it's been trendy to hate it for numerous buffer overruns and CVEs!

What do people have against delphi? I thought it was a nice fast language with a decent UI builder for native(ish) apps. I've never used delphi as it is but I've got fond memories of pascal. I didn't realize it was even used enough anymore to have people dislike it.

I'm moderator on a large latin-america delphi forum (http://www.clubdelphi.com).

So, contrary to most uninformed people or some guys that were "forced" to use Delphi for a bit and haven't learned the language at all (something I could relate: I will totally hate to be forced to use C or C++), I can give a reason why Delphi is out.

Delphi is amazing. Is the only RAD language left in the world. It compile fast. Is as powerfull as C/C++, +/- minor stuff and this or that library. Is loved and is one of the few where you have fun working on it.

You must understand that Delphi is part of the pascal family. And if you are into that, you like it. So, from our side, the C/C++ are the "irrationals" ones that decide to work with slower compiles, mess of errors, insane templates, irrational behaviours and massive complexity.

Is the love of the community what have keep Delphi were is it, far more used that most people could imagine (above clojure, rust, vb and many others).

Why is disliked? Because Delphi is the most mismanaged language ever. Since Delphi 3 Borland take a route that put Delphi from be the #1 to be in a corner:


Borland lost its way when executive management decided to change the company to pursue a different market. ... ... In the height of the enterprise transformation, I asked Del Yocam, one of many interim CEOs after Kahn, "Are you saying you want to trade a million loyal $100 customers for a hundred $1 million customers?" Yocam replied without hesitation "Absolutely."

Also, the owners rarely have pay attention to the clamor of the community, like focus on stability and bug fixes. To get bug fixes, you MUST buy the next version. And the IDE cost a lot of money (only recently a free version return!).

This kill Delphi for a large segment of the population. So, is more a reject of the direction than the language itself.

I have to use it at work (for legacy reasons) and it's the worst IDE ever.

Prepare yourself for random crashes, Auto completion and code Navigation not working, and if you debug 64bit values of local variables sometimes are not accessible.

Also the bar with the open files doesnt Scroll and isnt resizeable. Tidious as fuck if you have more than 3 files open.

And it doesn't even have proper syntax highlighting! You have to install some shady chinese plugin if you want it. Ffs!

And don't get me started about the Pascal language it uses... There is absolutely no actual help on the Internet. Forget StackOverflow, some old German forums is all there is.

And it forces you to have some kind of Header section in the file were you declare fields and Methods that you want to implement. If you want to quickly rename or change some parameter you have to Scroll All the way up...

rant off

I have to step in here to correct a few completely false statements.

> And don't get me started about the Pascal language it uses... There is absolutely no actual help on the Internet. Forget StackOverflow, some old German forums is all there is.

> And it forces you to have some kind of Header section in the file were you declare fields and Methods that you want to implement. If you want to quickly rename or change some parameter you have to Scroll All the way up...

There is /plenty/ of help online and SO. In fact, for some topics (eg raw WinAPI programming) you will often find /more/ help, articles, or blogs using Delphi than in other languages, including C++.

As for a header: yes, you define a class and its methods, and implement it, separately. I'm guessing you're not used to languages where this is the norm? That's quite ok, but don't knock it :) FWIW, just turn on "Sync Prototypes" and when you modify a method, the declaration for it changes too, and vice versa.


There are also other IDE features, such as a shortcut to autocreate methods you declare (Ctrl+Shift+C, "class completion".) Type a new method in the interface, press it, it exists. Use Ctrl+Shift+Up or Down to move between the interface and implementation of the method(s), too. If you are scrolling, that is a more efficient way to navigate ;) Or you could use the shortcuts in the editor toolbar, listing methods/classes etc etc, if you prefer mouse interaction.

If you're a keyboard user vs mouse, mainly, check out some of the keyboard shortcuts: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Default_Ke...

I have no idea what you mean re "proper" syntax highlighting. It does indeed highlight. The main thing I know of that GExperts modifies here is changing the colour of block keywords as it indents, and Delphi does that through a block indicator line in the editor, instead.

The problem is that the shortcuts don't work (as expected) half of the time for some reasons... So I stopped relying on them.

As "proper" syntax highligtting I mean things such as highlighting every occurrance of a clicked variable, and maybe some color. The default prints "begin" and "end" blue and adds some lines to control structures... wow. ._. I'm using CNPack for that now.

I have to use it at work too. I don't use the IDE. I use Sublime Text with a couple of Delphi plugins. Compile from the command line. Debug with message boxes.

I recently had to debug an open source delphi application, it was awful. The IDE is dated, the errors arcane, and I had someone from "greymatter" leave me a voicemail after I started a free trial of the IDE.

Also, curly braces as block comments actually offend me.

Curly braces offend? There are other language families than C-descended, you know :D

Delphi goes for /reading/ code. My experience - and anecdotally, reading comments others say - is that it is a literate, readable, clear language. One of the biggest problems with long-term coding and big projects is "write-only code", and the language can help.

Why “ish”? The apps are fully native.

Native UI. It's compiled native, but AFAIK it uses it's own UI toolkit, admittedly I have no idea how well it matches the LnF is on various platforms.

Native UI on Windows and iOS. Android and macOS are on the roadmap. FMX is a good UI/graphics toolkit too - runs on the GPU etc.

> One tag that stands out is the functional language Clojure; almost nobody expresses dislike for it, but it’s still among the most rapidly shrinking

Is it fair to correlate a single qa site usage even a massively popular one with popularity.

By that definition if error messages improve it will be deemed to "shrink".

Well, yes. My dislike of PHP took a steep dive right around the time I didn't have to use it anymore. It's obviously way easier to dislike something you use, and even more easy if it's something you have to use.

I'm really surprised to see Ruby so high on the list. I have limited experience with it myself, but I had the impression it was a generally well-liked language.

Me too, but I have a feeling a lot of that is Rails backlash. I dislike that Ruby is so strongly associated with Rails, because it's a full programming language like Python or Perl in it's own right.

Also Chef backlash

I'm one of the new generation of devs to have come into the startup world in Melbourne after Ruby stole its heart, and damn is it a mess and a maintenance nightmare. So many production bugs due to nil pointers, missing methods, etc, and a woeful time to be had if you want to start doing large scale refactors and clean up tech debt. Makes me sad that when faced with Java the generation before me escaped towards Smalltalk and Perl rather than towards ML and Haskell.

Thankfully we seem to slowly be turning it around though. If only on the front end, that is - with Typescript, Elm, Flow, Reason, etc. In Melbourne the Rubyists seem to be running towards Elixir hoping it will save them, but having worked on a number of Elixir code bases it seems that while solving some problems it leaves many still standing. :(

I've worked on over 40 Rails web-apps in the last 10 years and what I see it lots of apps built by juniors who didn't even bother to read the most basic conventions of the frameworks which result in bizarre behaviour.

At least in Rails if you have to refactor you know what it should be refactored to.

Frameworks based in other langs have no concrete conventions and this willfully frees developers to write bizarre over engineer web-apps.

None of the points you made are specific to ruby. Any language can have technical debt, dangling pointers and so on. I think you might have had the misfortune of running into mismanaged code bases.

> Any language can have technical debt, dangling pointers and so on

Any language can have tech debt, but I want access to tools in order to help me refactor my way out of that. Working with Ruby feels like building on a foundation of sand with mashed potatoes. It requires a huge amount of discipline to maintain a good enough test suite to combat code rot, and even then, a sufficiently paranoid test suite becomes a hindrance to change (not arguing against tests, just how much extra testing a dynamic lang requires of you if you want to have confidence). You have to refactor incredibly slowly, one small change at a time.

Dangling pointers are not an issue in languages like Haskell, and ML. We've had these around for decades. Thankfully most newer languages are banishing them.

I think there's a pushback from developers who see Ruby as more hipster and alot of "Ruby" developers as merely Rails developers gluing together gems.

I learned Ruby before learning anything about Rails. I've used it off and on professionally for 7 or 8 years for production services, testing, and random glue/batch code.

It felt super powerful and refreshing when I was doing C++ daily. And after Perl it seemed like a nice improvement in syntax and readability to me.

But... Time has not been kind to my views on Ruby. All that promise turned to ashes in my day to day.

All that flexibility and expressiveness led to subjective code reviews and inconsistent styles across files, let alone projects, being worked on by the same team.

All that metaprogramming goodness lead to very robust, extendable classes and modules.. that were never extended. They were copy-pasta'd to a new codebase instead because testing the metaprogramming to support both variants was too risky for the project. And once there were two deployed forks no one ever approved time to consolidate them so then the third one was forked...

Working with Rails for some internal sites a couple years ago was like my whole Ruby experience in miniature. Started happy and very productive (ahh, generators! I'll just get my boilerplate started.. Rails guides! Actual documentation...) Then it was a little bumpy.. (Ok sure, convention over configuration. But where are the conventions listed? What options are there?).. And then magically working for almost everything. Then I spent three times as much work fixing the last 5% of my issues because they were poorly supported/unusual features, impossible to configure within the default Rails knobs, or basically just growing pains in moving from development to deployment environments.

I don't consider Ruby as a hipster language and I formed my opinions of it based on the core language not Rails. Not saying there aren't people who match your description, just offering a different view. I'd summarize it more as Ruby-fatigue.

Ruby "in the large" is pretty tedious and working with larger teams has lead to friction (even with good teams trying to be proactive with linting, style guides, code reviews, automation). So I still use it, but it's a "better Perl" for me now. If it's a one file script it's in bash/Perl/Ruby/whatever, if it's a couple files for a utility it's probably in Ruby, but if it's something new and I expect it to be more than that I'll pick something else.

Ruby has some of Perl's problems. One's experience with a language is not merely writing greenfield code on your own. Instead it's maintaining and understanding other people's code, more often than not. If that task is burdensome and frustrating then your feelings towards the language in general will reflect that. Ruby encourages a lot of cowboy coding practices like monkey patching and so forth, which make maintenance a hazard.

I think some of the dislike will be misplaced annoyance against rails.

R is a great tool but terrible programming language. There is some basic fundamentals how programming language should work which R just disregards for the sake of being different.

Okey indexes start at 1, I can get past that.

Variables are initialized with "a <- 1" okey well for each to their own.

Return requires you to wrap values with "()" so "return x" doesn't work but "return(x)" does. Umm.

You should never iterate over a dataframe except when you have to and then there's a plethora of different ways to do it. Some are better, some are worse. But isn't it nice that everyone can invent their own way of doing it? Right?

Those are what I can come up with from the top of my head. But overall the feeling I get when I code R is that it's this mystic arcane magic that requires completely new way of thinking compared to other programming languages. And it's very frustrating.

Python is better but I have my issues with it too. Mainly the fact that debugging in Python is such a pain the ass and typelessness makes reading of other people's code a nightmare at times. Also libraries like numpy, pandas and matplotlib are very convoluted with kinda bad documentation. Maybe a good IDE would solve it with Intellisense and RStudio like capabilities (again where R shines). I've tried Spyder/Rodeo/Pycharm but none of them were as simple and user-friendly as RStudio when doing data-stuff.

EDIT: Anecdote: I did some programming with a statistician who is a R-guru and he wrote terrible code in Python. Would he coded better if he had learned a different language than R? Maybe. In my opinion probably yes.

Sounds you like have a very OO background. I'd strongly encourage you to learn more about functional programming (FP). I personally believe it's a very good fit for the types of programming you commonly encounter in data science, and it leads to elegant and readable code.

I've written a bit of an intro at http://r4ds.had.co.nz/iteration.html#for-loops-vs.functional...

> There is some basic fundamentals how programming language should work which R just disregards for the sake of being different.

So, you can complain that R feels different from languages you're used to, but it's incorrect to assert that R does things for "the sake of being different." R is simply influenced by a different lineage of languages than, e.g., Python.

> Okey indexes start at 1

Languages have had 1-based indexing since Fortran. If your languages is doing numerical computing, you're going to take a lot of cues from Fortran.

> Variables are initialized with "a <- 1" okey well for each to their own.

This is how APL does assignment. Like APL, R is an array-based language (all types are vectors/arrays; all functions operate over arrays).

> Return requires you to wrap values with "()" so "return x" doesn't work but "return(x)" does. Umm.

R is highly functional. Arithmetic, assignment, and indexing operators are all functions. There are very few "statements" in the language. It's actually highly consistent with that to have return be a function, not a statement. It's actually uncommon to use return in R, since every block automatically returns its last expression.

> You should never iterate over a dataframe except when you have to and then there's a plethora of different ways to do it. Some are better, some are worse. But isn't it nice that everyone can invent their own way of doing it? Right?

A data frame implements both list and matrix semantics. This makes sense since, like a list, it is an array of differently-type arrays. But like a matrix it has a notion of rows and columns. Over time, folks have tended to move away from using matrix semantics.

> Those are what I can come up with from the top of my head. But overall the feeling I get when I code R is that it's this mystic arcane magic that requires completely new way of thinking compared to other programming languages. And it's very frustrating.

I mean, this is a fair complaint, but it's not a problem with the language. You have to learn it. At its core, R is actually a fairly simple, elegant language that has a few key principles, and some interesting and powerful design features (like delayed argument evaluation).

In "Javascript: The Good Parts", Doug Crockford says this:

"JavaScript is most despised because it isn’t SOME OTHER LANGUAGE. If you are good in SOME OTHER LANGUAGE and you have to program in an environment that only supports JavaScript, then you are forced to use JavaScript, and that is annoying. Most people in that situation don’t even bother to learn JavaScript first, and then they are surprised when JavaScript turns out to have significant differences from the SOME OTHER LANGUAGE they would rather be using, and that those differences matter."

Which reminds me of most people's attitude towards R.

This has already been discussed yesterday:


I begin to find the constant bashing of Perl amusing. Such a great language, people just use it and it gets stuff done. I have no explanation as to why people hate it, other than because most people just don't understand Perl.

I've used Perl since 1991. I've spent more than 80% of my career writing and maintaining Perl. I get paid large amounts of money to come in and help people sort out their Perl projects.

... it's not a great language; it's a clusterfuck of "cleverness" which lets "clever" people implement horrifying glass cathedrals that shatter as soon as you open the door.

(And there is some selection bias here, I'll admit - the people who control their Perl programmers and enforce simple, readable code don't need contractors to rescue things. It's generally only the hideous fractals of fuckery I get to see.)

> ... it's not a great language;

Yes it is.

> it's a clusterfuck of "cleverness" which lets "clever" people implement horrifying glass cathedrals that shatter as soon as you open the door.

It is clever, so are most other languages. It lets do people do horrible stuff, as well as wonderful stuff, same as in most other languages.

The Perl code from other programmers that I usually come across is mostly using established popular CPAN modules and/or frameworks that encapsulate the "clever" parts. I think you are right in that you mostly get to see Perl code that does need help, rather than the better maintained Perl code that does exist as well.

I agree it is a great language, but you need to have discipline and a coding standard to avoid the pitfalls of TIMTOWTDI

Agreed -- there are far too many pitfalls that you only really learn through debugging strange behaviour. Autovivication is a perfect example of this:

  perl -wE 'my @test; say $test[5]{yes}[0]{ok}++; say scalar @test; say ref $test[5]; say $test[5]{yes}[0]{ok}'

with not a single warning

Why would there be a warning? Your example does exactly what autovivification is supposed to do. Obviously you don't normally use it as obscurely as you've done here.

I hate C#'s way of assigning a value to a dictionary, without autovivification:

    if (dict.ContainsKey("yes"))
        dict["yes"] = val;
        dict.Add("yes", val);
You also have to use ContainsKey before you try to use [] to retrieve a value, because [] throws an exception if the key doesn't exist in the dictionary. Perl's autovivification, which assumes you know what you're doing and expect the key to be there when you ask for the value rather than explicity check for the key, makes much more sense and is a lot easier to work with.

>which assumes you know what you're doing

This is exactly my point, there should be no autovivification - I'd wager most people using perl these days don't know what they're doing, they're reluctantly editing some legacy code.

It's a dangerous default behaviour that can lead to very hard to debug errors. Most languages don't do this so people don't expect it; I don't know C# but can immediately tell what the code you wrote is doing. Explicit is better.

It's extra confusing because if you try and dereference undef without accessing a value it's an error:

  perl -Mstrict -WE 'my $test; say @{ $test };'
  Can't use an undefined value as an ARRAY reference at -e line 1.
What harm is there in a warning? You can disable classes of warnings in perl if you want to, or turn them off completely. I would much rather be explicit so I don't accidentally use some magic.

Explicit isn't better when the explicit boilerplate overwhelms and hides the intent of your code.

For the C# example, this can cause an exception:

   dict["yes"] = "val";
If the dictionary already contains an entry with the key "yes", the line will assign "val" to that entry. But if there is no entry with that key, an exception is thrown. The alternative is to use the Add() method, but that throws an exception if the key does exist, and works if it doesn't. I can't imagine any common use case of dictionaries where this behavior makes sense.

So what you're left with is a bunch of boilerplace and an if/else branch wrapped around every place you want to set a value in a dictionary. It makes dictionary use very cumbersome, which obscures the intention of code that uses dictionaries and, worse, discourages their use. C#'s design here takes away a very handy data structure that can make entire classes of problems easy to solve.

Perl's dictionaries, aka hash types, are used everywhere in Perl code. They're extremely useful and flexible, and a lot of that is due to the ease of use that autovivification brings.

I don't think it's fair to judge a language (or any tool) by how difficult it is to use by someone who rarely uses it and has no desire to learn, rather than by how usable it is for someone who uses it all of the time.

> than by how usable it is for someone who uses it all of the time.

Most of my career since 1996 has been in developing Perl. I'm a contractor who gets hired (and paid well) to help with Perl projects. By no stretch can you say I "rarely use it".

And I still consider Perl one of the more difficult languages to deal with because it's very easy to rely on implicit behaviour that - whilst perfectly clear as you develop it - makes life inordinately hard a year later when you're trying to debug an edge case because now, e.g., people can have two different delivery methods in the same basket (whoops, the second one overwrote the first one in the hash!)

> Perl's autovivification, which assumes you know what you're doing

Which is fine if you're the only person who will look at this code and we're talking about a timespan of a few hours.

When someone comes to deal with this code a year later, it makes life more difficult than it needs to be; at least the C# way is explicit - you can come back to that years later and know exactly what's happening.

(Which is the basic problem with most of Perl's magic - coming back to it hours/months/years later makes life harder for no actual gain.)

I assume the higher than (I) expected dislike for C# is because of the Microsoft ecosystem, not the language itself. It will be interesting to see whether that remains so over the next few years as .NET Core and VS Code mature.

Indeed. I've used a lot of languages and C# is one of the best to work with. It's easy mode for practically any task you can imagine. Maybe it has to do with the employers who want to use C#, I can imagine more of a predominance of enterprisey hell holes making dumb line of business apps.

I think it's due to how the question was formulated.

The answer is not really if the person 'likes' a language but more about if the person is looking for a job writing that language.

That would also explain why JS is so low in dislikes when it should really be one of the most disliked (there's a whole ecosystem of languages and transpilers that have cropped up just so you _don't_ have to write in it).

please don't hate Perl, it is great for one-liners from command line ;)

though I do wish the move towards Python in VLSI industry had occurred lot earlier


I clicked on this just to see if perl is on top :D

I'm surprised that JavaScript not disliked by more people given that it's probably the #1 language that developers are essentially forced to learn (often against their will). I guess it's a testament to how good it is/has become.

Interestingly, but somewhat unsurprising, most disliked languages are "medieval" languages according to: https://www.youtube.com/watch?v=y2___qaG_9Q


I like the network plot. In it I recognize how some stacks are growing and shrinking in popularity: ML/AI, JavaScript are growing. PHP Is losing to Node. MS and Oracle JEE down, Java Spring moving on... I definitely need to polish my Kotlin

Lisp? Did I miss a mention of it?

Unforunately, us lispers are probably too obscure for most professional programmers to even have an opinion on :(

Its right there under "Javascript". Lol.

Since Javascript is one of the few languages that first properly implemented clotures, and are functional to boot. A big joke in LISP circles was that Javascript is more similar to Scheme (one LISP dialect) than it is to Java.

Not really a joke is it? Only got the syntax because of the sun deal, I thought.

Wow so many wrong in one comment. Javascript is not the first language implemented closures. Javascript is close to scheme ... compared to C, Eiffel, Algol, Haskell? Semantically null statement. Javascript is not named Javascript because it is supposed to be close to Java; no one thinks Javascript is close to Java, so comparison is misguided.


Don't blame me. Blame Douglas Crockford. And I think Mr. Crockford knows more about early Javascript history than you do.


The link you gave explains my 3rd point. It doesn't mention Javascript being the first closure implementation. And it says Javascript is closer to Scheme compared to C and Java; which is _exactly_ what I suggested above (which didn't support your original argument).

Dude, its an offhanded joke comment. I'll accept the downvotes if you don't find the humor funny. But please, don't bring forth this aggressive discussion style to YCombinator.

This ain't Reddit. YCombinator is supposed to be a way more mature environment.


I'll play "serious business discussions" on issues that actually matter or are of technical importance. But there's no need to be this aggressive on this humorous issue.

Never intended to be aggressive. But I want to emphasize that your joke comment included misinformation, and I cannot find any reason not to point out misinformation. You're not downvoted for the joke, you're downvoted for writing misinformation without explicitly stating it is so.

Microsoft despite all their efforts clearly takes the lead on disliked technologies. Poor guys.

Given the typical “developers use Macs” mantra you see echoed everywhere, it’s interesting to see OSX so clearly disliked too though.

I think the issue with OSX is the perceived decrease in quality over the past few years.

If by developpers you mean bootcamp graduates...

Whichever one the legacy code is written in.

I'm surprised nobody said that yet.

Chip (ASIC, SoC, FPGA) designers kind of all hate verilog and VHDL, but the alternatives, sadly, aren't gaining much traction yet.

Short version: Perl, Delphi, and VBA are the most disliked languages.

Perl is like Crack. Feels so good to use it and it solves the narrow problem so fast. But when you have to go back to it you feel so dirty.

HolyC ?

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