What are some of the most disliked programming languages?
stackoverflow.blog
stackoverflow.blog
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...
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?
You can also use R inside Python using the rpy2 library. And Julia embeds R with the RCall package.
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).
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.
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)))
* 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.
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...
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.
What are you referring to?
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.
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.
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.
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.
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".
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.
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)
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.
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.
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.
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).
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...
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.
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.
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.
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!
IMHO these stats have little to do with the language itself, and say much more about the current fashion and job niches.
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.
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]
Granted, there still may be too much of a tendency for Haskellers to use operators, but lack of clarity to Perl level? Come on!
I wish perl 6 had a larger community, it actually looks very cool.
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.
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.
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.
> 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.
https://www.ruby-forum.com/topic/215212
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.
> 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.
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.
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 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.
Microsoft knows how to create developer tools, and languages.
But it was not only late to market but also Microsoft's PHB's managed it pretty ugly.
Also, curly braces as block comments actually offend me.
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.
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
> 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.
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Code_Edito...
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.
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.
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:
https://www.quora.com/Why-did-Borland-fail?share=1
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.
By that definition if error messages improve it will be deemed to "shrink".
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.
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. :(
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.
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.
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.
I've written a bit of an intro at http://r4ds.had.co.nz/iteration.html#for-loops-vs.functional...
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.
... 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.)
perl -wE 'my @test; say $test[5]{yes}[0]{ok}++; say scalar @test; say ref $test[5]; say $test[5]{yes}[0]{ok}'
0
6
HASH
1
I hate C#'s way of assigning a value to a dictionary, without autovivification:
if (dict.ContainsKey("yes"))
{
dict["yes"] = val;
}
else
{
dict.Add("yes", val);
}
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.)
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.
For the C# example, this can cause an exception:
dict["yes"] = "val";
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.
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!)
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.
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).
though I do wish the move towards Python in VLSI industry had occurred lot earlier
;-)
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.
Don't blame me. Blame Douglas Crockford. And I think Mr. Crockford knows more about early Javascript history than you do.
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.
Given the typical “developers use Macs” mantra you see echoed everywhere, it’s interesting to see OSX so clearly disliked too though.
I'm surprised nobody said that yet.