Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Java Python

What Makes Some Programming Languages the 'Most Dreaded'? (oreilly.com) 137

Posted by EditorDavid from the least-loved-languages dept.
O'Reilly media's Vice President of Content Strategy (also the coauthor of Unix Power Tools) recently explored why several popular programming languages wound up on the "most dreaded" list in StackOverflow's annual developer survey: There's no surprise that VBA is #1 disliked language. I'll admit to complete ignorance on Objective C (#2), which I've never had any reason to play with. Although I'm a Perl-hater from way back, I'm surprised that Perl is so widely disliked (#3), but some wounds never heal. It will be interesting to see what happens after Perl 7 has been out for a few years. Assembly (#4) is an acquired taste (and isn't a single language)...
But he eventually suggests that both C and Java might be on the list simply because they have millions of users, citing a quote from C++ creator Bjarne Stroustrup: "there are only two kinds of languages: the ones people complain about and the ones nobody uses." Dislike of a language may be "guilt by association": dislike of a large, antiquated codebase with minimal documentation, and an architectural style in which every bug fixed breaks something else. Therefore, it's not surprising to see languages that used to be widely used but have fallen from popularity on the list... Java has been the language people love to hate since its birth. I was at the USENIX session in which James Gosling first spoke about Java (way before 1.0), and people left the room talking about how horrible Java was — none of whom had actually used the language because it hadn't been released yet...

If there's one language on this list that's associated with gigantic projects, it's Java. And there are a lot of things to dislike about it — though a lot of them have to do with bad habits that grew up around Java, rather than the language itself. If you find yourself abusing design patterns, step back and look at what you're doing; making everything into a design pattern is a sign that you didn't understand what patterns are really for... If you start writing a FactoryFactoryFactory, stop and take a nice long walk. If you're writing a ClassWithAReallyLongNameBecauseThatsHowWeDoIt, you don't need to. Java doesn't make you do that... I've found Java easier to read and understand than most other languages, in part because it's so explicit — and most good programmers realize that they spend more time reading others' code than writing their own.
He also notes that Python only rose to #23 on the "most dreaded" languages list, speculating developers may appreciation its lack of curly braces, good libraries, and Jupyter notebooks. "Python wins the award for the most popular language to inspire minimal dislike. It's got a balanced set of features that make it ideal for small projects, and good for large ones."

"And what shall we say about JavaScript, sixteenth on the list? I've got nothing. It's a language that grew in a random and disordered way, and that programmers eventually learned could be powerful and productive... A language that's as widely used as JavaScript, and that's only 16th on the list of most dreaded languages, is certainly doing something right. But I don't have to like it."
This discussion has been archived. No new comments can be posted.

What Makes Some Programming Languages the 'Most Dreaded'? More

What Makes Some Programming Languages the 'Most Dreaded'?

Comments Filter:

  • JavaScript does something right.. (Score:5, Insightful)

    by mybecq ( 131456 ) on Sunday August 16, 2020 @02:39PM (#60407463)

    > A language that's as widely used as JavaScript, and that's only 16th on the list of most dreaded languages, is certainly doing something right.

    Or has a industry-given monopoly.

    • Re: (Score:2)

      by JackAxe ( 689361 )
      I second this statement.

    • Re: (Score:2)

      by Sique ( 173459 )
      I don't get it. Is it somehow not possible to dread a language just because it has an industry driven monopoly? Is there a cabale going on in the industry to squeeze anyone out who dares to claim to dread JavaScript?

      • Actually, a language with a monopoly I would expect to rank higher on a list of most dreaded languages because it's unavoidable, hence more opportunities to dread having to use it. As opposed to something like Python, where if I really didn't want to use it for something, I might be able to substitute something else in there.

        • Re: (Score:2)

          by jeremyp ( 130771 )

          But this isn't a list of dreaded languages, it's a list of

          % of developers who are developing with the language or technology but have not expressed interest in continuing to do so

          If you are a front end developer and you want to remain a front end developer, you are going to want to continue to use Javascript whether you like it as a language or not.

    • When it's the only language you know, what do you expect?

      Most languages go from concise to bloated, and the more bloat, the more hate. It's not hard to figure out.

    • Or has a industry-given monopoly.

      Being a monopoly doesn't support it's case, it actively works against it. Using something just because it's a monopoly invokes a sense of dread and doesn't make using it any better.

      Unless it is that "Big JS" rigged the study by forcing developer slaves to show the language in favourable light under the threat of breaking their fingers with a keyboard.

  • Familiarity does not always breed contempt (Score:4, Insightful)

    by rednip ( 186217 ) on Sunday August 16, 2020 @02:49PM (#60407499) Journal
    Seems to me that this is really mostly a list of 'legendary' languages which a developer has had exposure but is not yet familiar. A few at least took it to be 'Something I wish I knew, but likely will never learn'. I wouldn't read into it too much.
    • And it totally misses languages that are worth dreading because they are non-procedural, like Lisp.

      • Re: (Score:2)

        by chthon ( 580889 )

        You can program strictly procedural in Common Lisp or Scheme. There is nothing in those languages that prohibits that.

        Additionally, in Common Lisp you can program in a functional style, an object-oriented style, or other things.

        The only thing missing in Common Lisp is better interaction with standard libraries.

        Now for languages to dread: anything that has been derived from Ada, because of the red tape. I think that even modern Cobol variants have less red tape than Ada.

  • Went to the article to find out what other observations he had to make, and I don't really think there are any. The TFA is the Readers Digest condensed article.

  • VBA fan (Score:5, Interesting)

    by rbrander ( 73222 ) on Sunday August 16, 2020 @03:06PM (#60407551) Homepage

    It's not VBA per se, but the thing is, VBA is not really a language, its an environment. As an engineer with stuff to do, most of it just the once, or for the duration of a project, the overall Excel tool is indispensable.

    So the question is not how well VBA does general programming, but how well it lets you customize an Excel spreadsheet to allow people who would otherwise have to go through nine steps to load some data in, set some parameters, crunch the data, and pull out a report...100 times.

    VBA can turn hours into minutes with highly repetitive spreadsheet uses that just require some procedural steps and IFs and stuff that are really hard to embed in spreadsheet formula approaches.

    And VBA, with the huge bonus of having the development environment right there in the spreadsheet, very good at whipping together short, simple programs, made me the office magician. This did not get me seen as a "programmer" at all; indeed, those who appreciated me most were the trainee engineers and clerical assistants that were the ones stuck with going through the same 10 steps for four hours, and I'd make it all go away. Bosses were frequently unaware I'd saved hundreds of hours of staff time with a 20-line VBA.

    Programmers judge languages by how good they are at 1000+ line programs that must last years and years; users know that programming problems are like the Richter Scale, where there are 10 Richter 6 earthquakes for every Richer 7, and 100 Richter 5 earthquakes. Programmers never even hear about the 50-line programs that would be useful, many of them, because it's not worth calling a programmer, and really not worth calling the programmer's IT bureaucracy.

    The Program Size Power Law. analogous to the Richter Scale, suggests that there is as much code in the world in 1000-line chunks as 10,000-line chunks and 100-line chunks; just 10X as many total programs as you go down each order of magnitude. (I just invented this law, and stand by it.)

    Example: a programmer being called in to fix a VBA written by engineers... that grew over years to 1000 lines, that guy has my sympathy. The thing is, the programmer doesn't realize there are also 1000 lines worth of 100-line VBAs in the same office, that they never called him about, because those ten solutions are doing fine.

    • I once programmed an entire CMS/ERP into an access database using VBA. The UI was great. Tracked everything from manufacuring QA, employee timeclocks, shipping, customer requests, etc. and was fully integrated with their generic ISP email (IMAP/SMTP client custom-coded, there were no libraries for it back then), QuickBooks integration, and fedex integration.

      It wasn't my choice BTW, VBA was one of the main constraints the client gave me, because he had spent so much time building his precious Access datab

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        You know what? VBA probably made that project possible. Had you used Java or C++, the project would have grown in size and complexity beyond the ability for a single developer to manage.

        VBA, lacking OOP, forced you to actually write in a modular style. (OOP is anti-modular, as most of us have discovered.)

        It's a shame there isn't support for it outside of Microsoft platforms. For CRUD and LOB apps, it's hard to beat good old VBA!

    • VB and VBA can be wickedly misused. I once encountered a real-time control system written in VB and Assembly. The VB variables were labelled TextBox1 through TextBox100. The assembly was similar. It must have been hell to not use a single meaningful variable name in a 16,000 line VB program, and another 10,000 lines of assembly.

      Incidentally, VB was a popular language for control systems. I spent at least 20 years of my life spotting Emergency STOP circuits in VB. For safety reasons, Emergency STOP ci

    • You'd better be sure that the project for which you're building that VBA-boosted spreadsheet will be shorter than an Office update cycle. Because I've been there, done that and I got fed up with it.

  • Perl is fine for quick command line data transformation. Otherwise, it blows. Too easy to write inscrutable and, hence, unmaintainable code.

    Who the hell is using VBA these days? Why?

    • Re: (Score:3)

      by rossz ( 67331 )

      I like Perl just fine if I'm writing something from scratch. Doing maintenance on something, however, is dreadful. Even when it's my own code, six months from now I have no idea what I was doing and have to rely on my own comments. That typically results in a promise to next time write better comments. I lie to myself a lot.

      • Re: (Score:2)

        by chthon ( 580889 )

        Don't write comments, write requirements. And use a lightweight issue tracking tool like Trac.

        It is all a question of discipline, hard obtained because of encountering your own mistakes further down the line, or down the years.

    • Re: (Score:2)

      by HiThere ( 15173 )

      I suspect you're talking about the classical version of Perl, not the more modern iterations. I don't know whether they're any good or not, because I don't trust a language that has to continually be loading things from the internet, but it doesn't look as if it would have the problem you're attributing to it. Probably not the advantages, either.

      • Do you mean Raku? Was named perl 6 when released, I believe. Haven't used it, but technically it's not Perl. However, point taken.

        • Re: (Score:2)

          by HiThere ( 15173 )

          Perl 7 is derived from Raku. And the language spec that Raku implemented was called Perl 6. (There were multiple compilers for that spec, and Raku was one and became the accepted one. I didn't know that they ever renamed the spec, however.)

    • Who the hell is using VBA these days? Why?

      VBA can be embedded in Excel.

  • If you don't know how your code is affecting the users hardware, you have no idea what side effects it is causing.

    • If you don't know how your code is affecting the users hardware, you have no idea what side effects it is causing.

      Assuming that your code runs in an operating system, you have no idea what side effects the system calls are causing. Assuming that your code runs in a processor architecture that's not open, you have no idea what side effects your opcodes are causing.

      And yet, sometimes, people manage to write working, useful programs in Python.

  • CFML - a blast of of the past with a dollop of coding 'XML' goodness.

    Not

  • - Design by committee such as C++ iostreams which has horrible performance. [youtu.be]
    * Over-engineered crap like Boost's CRC [boost.org] that takes 1,100+ LOC when a mere 21 LOC would do the job.
    * No native ability for modules. Even Pascal had support for modules back in the 1980s!
    - Stupid side effects that learnt nothing from earlier languages
    * Javascript's crappy design of using variables even if you haven't declared them unless you turn on the "use strict"; hack. We already went

    • Javascript's crappy design of using variables even if you haven't declared them unless you turn on the "use strict"

      Use "use strict"!

      Shitty inconsistent designs such as PHP: a fractal of bad design [eev.ee]

      Page written in 2012... PHP changed and improved so much in between, that page is obsolete for most of its points.

    • Re: (Score:2)

      by Ksevio ( 865461 )

      Imagine not knowing how to indent properly in 2020. I guess python isn't for everyone!

      Are all your language complaints from a decade ago?

      I also had problems with inconsistency in PHP in 2012, but 8 years later it's improved

      My problem with Java isn't that I want to pretend to write C and manage all the memory (if I'm writing something that requires that I'll pick a more appropriate language), it's that there's so much overhead involved to so even the simplest tasks. When you want to do something and think

    • Imagine a Programmer telling a Mathematician that these two statements are functionally different even though semantically they are the same. They would laugh at your stupidity.

      a=b+c a = b + c

      Uh, those two statements are functionally the same. The only difference is that the second one came from a different nesting level. It's the same as saying that two identical statements in C are functionally different based on the number of braces before it.

    • Python's retarded whitespace effecting functionality.

      Au contraire, this is what makes Python the proverbial Good(TM) language; you do not have to count the fucking brackets that do so much to make bracket-using code unreadable.

  • code-of-conduct.md

    • Everyone needs a code of conduct to make fun of when they're bored.

      Like astronomy eliminating offensive names such as the Eskimo Galaxy, and just using the alphanumeric catalogue designation.

      So what are we supposed to call Uranus? A red dwarf? A black hole?

    • When you behave in a decent manner does your neckbeard ache and burn?

  • For Objective C, I imagine there are two groups that dislike it: one that doesn't like Apple and one that would rather use Swift. I know there is also GNUstep but I don't think that's statistically relevant.

    Assembly isn't bad for what it does, but if you run into a block of assembly code when debugging or changing a piece of code, you know you have a lot of work ahead of you, so I can imagine people dread it for that reason.

    Perl has a reputation of being hard to read, but it really depends on who wrote the

    • Re: (Score:2)

      by dgatwood ( 11270 )

      For Objective C, I imagine there are two groups that dislike it: one that doesn't like Apple and one that would rather use Swift.

      And then there are those of us weirdos who like Objective-C, but don't particularly like Swift, because the Objective-C syntax seems more consistent (not to mention more familiar), at least from a C programmer's point of view. To be fair, every time we see an Objective-C block, we have to close our eyes and think of England, but apart from that syntactic abortion, it's a decent language, and with just a tiny bit of C preprocessor glue, it can be a great language.

      Perl has a reputation of being hard to read, but it really depends on who wrote the code. I once had to add some features to a Perl script and I wasn't looking forward to that, but the script was very straightforward and I could make sense of it despite knowing barely any Perl.

      Perl's inclusion of regular expressions as p

      • Your describing Laravel as far as using php in a a sane way. That how they do it. Falcon was nice but sucked...

        • Re: (Score:2)

          by dgatwood ( 11270 )

          I was actually describing how I wrote my own PHP code half a decade before Laravel existed, but it's good to know that others have taken a similar approach. :-D

  • Languages Evolve (Score:3)

    by Required Snark ( 1702878 ) on Sunday August 16, 2020 @06:15PM (#60408171)
    I've been using both JavaScript and Python for the last few years, and they have both changed for the better. This is partly from adding new features and partly because existing features are being used in better ways. Emphasizing better styles and changing how code is written is another path to language evolution.

    My favorite new feature in JS is the arrow function. I almost never use the function definition statement anymore. It may just be syntactic sugar, but it's much better.

    In both Python and JS I have stopped using loops and use map and reduce functions instead. When I look back on old JS code with for loops it seems very clunky and overly verbose. With map/reduce code is easier to write, easier to read and it looks really clean. I think I am making fewer mistakes as well. Style counts, and style can evolve.

  • "Dreaded" in this context means "% of developers who are developing with the language or technology but have not expressed interest in continuing to do so"

    Limiting the pool to people who are actively using the language probably explains why Java, Javascript and Rust are so far down the list.

    (Honestly, I'd describe myself as both wanting to use Rust and also dreading it. It seems to have so many neat ideas, but then I look at some actual Rust code and oh grief I'm already confused...)

  • On the one hand, businesses who run on ancient COBOL should be appalled by the fact that they have to pay through the nose to have the code maintained quite often by people who had retired once already. On the other hand, the maintainers of that code are making a crapton of money doing so.

    • You gave yourself an answer right there. No programmer making good bucks in his retirement because of his arcane skills will vote COBOL down.

  • Outdated or shitty libraries

    Weird, inconsistent syntax

    Need to write complex lines for what should be simple

    Security vulns that are rarely or never patched

    Compilers that knitpick over code not written the way the compiler writers wanted, even if the code is 100% valid, with no alternative compiler available (not sure how often this happens)

    Languages tied to a specific OS, or code not being readily portable

    Languages that change rapidly and are not compatable with previous versions

  • Objective-C (Score:3)

    by gnasher719 ( 869701 ) on Monday August 17, 2020 @05:01AM (#60409395)
    Objective-C is interesting. I can fully understand that people just reading tiny bits if Objective-C code have a bit of a problem. But the reality is that after a week of programming or so, you get used to it and it ends up being quite normal. Slightly later you start loving named parameters. Then you start loving that interfaces can be implemented by completely unrelated classes. Sending messages to nil starts as a shock to the system, then becomes very useful. Notifications are really useful. Blocks (closures elsewhere) have a very unfortunate syntax but you learn to love them. And there are some advanced techniques that let you do things you can't do with a different language.

    But to the absolute novice, it's quite shocking.

Slashdot Top Deals

Avoid strange women and temporary variables.

Close