Bash script. Not necessarily hard to understand but very unintuitive in my opinion. I’ve written so much bash script over the years and still have to look up how to do simple things like iterate over associative arrays or do basic string manipulation. Maybe it’s just a me problem though 🤷
Bash does have a weird syntax. I too have to look stuff up all the time.
Yup, same. I’ve been a developer for years and used to code way before that and to this day I can’t write any non trivial bash script without looking up half a dozen of things lol, glad I’m not alone.
I’ve recently come across nushell, and it’s everything I’ve ever wanted when it comes to shell scripting. It’s not POSIX compliant so you can’t just run it anywhere but it helps keep my sanity in personal projects and whatnot. See also, elvish, xonsh.Even worse is Windows batch scripts. The syntax also changes depending on if it’s in the terminal or run from a file
In shell languages, concurrency is easy and everything else is hard.
Concurrency is not easy if you need the output and exit status of the commands. Fire and forget concurrency/parallelism is easy in any language. It is when you need to sync state up that it becomes hard.
Yeah, anything to do with iterative over strings. Basically anything that involves IFS is unintuitive.
I don’t think it’s just a you problem :)
I’ve been curious to try fish or zsh to hopefully run into less weirdness.
I don’t think it’s just a you problem :)
I didn’t think so. I guess Reddit has conditioned me to not state my opinion without a disclaimer, lest someone wants to start arguing :D
Btw. I don’t think you’ll find ZSH more intuitive to program. While it is an awesome interactive shell, the scripting part is Bash taken to the extreme.
My running joke, after four different friends told me they were using ChatGPT to help them with it, is that the language is so hard to learn that we invented an entirely new class of AI to help.
It’s a joke, of course, but it does have some “surprising” syntax, since some stuff is whitespace sensitive, and there are subtle differences between () and [] and [[ ]], for example. All of that’s due to the long history of shell behavior, so I don’t necessarily blame bash.
Brainfuck
Actually one of the few languages you can learn in its completeness in less than a day, so I wouldn’t really say it’s “hard to understand”. More like hard to read and understands programs written in it.
You have a point
Have you ever taken a look at Windows API, it’s disgusting.
Uh? It’s about what I expect. Anything in particular?
I honestly don’t think it’s so bad. There are some things which make it look ugly, the Hungarian notation, the fact that it’s a C API which means everything has to be functional and there are many limitations, and there is a lot of legacy stuff kept for backwards compatibility. There is a lot of "we did it this way before we knew the right way of doing it, but now we’re stuck with it because of backwards compatibility.
I think MFC is a lot worse. It’s basically a C++ API that wraps a lot of things from the win32 API. It heavily relies on macros, and I really dislike it in general. And don’t get me started on COM.
If by “hard to understand” you’re including trying to understand someone else’s code, Perl can be a nightmare.
I’ve heard a few people refer to perl as a “write-only” language.
// Dear programmer // // When I wrote this code, both // God and I knew how it worked. // Now only God knows!! // // Therefore if you are trying to // optimise this routine and it fails // (most surely) please increase // this counter as a warning for the // next person // // total_hours_wasted_here = 254There’s some truth to it, but it’s mostly that junior developers and senior developers with no discipline that give it a bad name.
The major problem is that it has one of the the highest capacities for writting incredibly dense code there is, paired with very powerful language transformation tooling (i.e. switch statements were added as a module, but can also be used for funny evil.)
When I was a Perl programmer, I had to modify this other guy’s code, and all I could think was that this guy was writing code with job security in mind.
Imo the amount of magic variables in perl is too damn high.
Like I don’t want to have to keep all that in my head while parsing through thousands of lines of code. I spent a few years working as a perl developer and even near my last days there I still found myself digging through docs to figure out what certain symbols meant and did.
My first developer role was as a junior developer and I was tossed into single letter variable loop hell in perl lol.
I was telling my mentor that if I were introduced to perl now that I’ve got several years of experience in a variety of different languages and thought models, it probably wouldn’t bother me as much. I kind of like bash (sometimes) and perl is really a hyper extended scripting language so going from bash to perl isn’t too bad. But given that that is what I was started in, I have a massive distaste for it and I doubt that will ever change.
Imo the amount of magic variables in perl is too damn high.
“Explicit is better than implicit” and “There should be one-- and preferably only one --obvious way to do it” in The Zen of Python exist, I’m sure, as a direct reaction to Perl’s magic variables and TIMTOWTDI.
OK just checked out that Hodor module. That is hilarious.
Perl isn’t particularly worse than JavaScript. Which itself has a lot of quirks, of course. The big thing with Perl is getting your head around list and scalar context. There’s a learning curve to it, but can be very powerful once you understand. I wish more languages would do list flattening by default.
Or your own after six months.
Depends on what you already know.
Functional languages like Haskell, Clojure or Erlang have a reputation of being hard to grasp.
Rust’s borrow mechanics are hard for some people at first, especially because it’s very unique to the language.
Javascript can be frustrating because it also has some rare features among popular languages, and uses the same keywords for different concepts. It’s not bad at all once you let go of your assumptions and dedicate the time to understand how it works under the hood.
C++ is also notorious for being hard but I haven’t used it for a very long time so I can’t say anything about it.
Javascript can be frustrating because it also has some rare features among popular languages, and uses the same keywords for different concepts.
I don’t think those are the reasons JS is frustrating.
For Erlang I would say that the hard part is not the language itself (maybe a bit because it is influenced by prolog) but because of the mental model. Using concurrency and parallelism as core concepts of the language and understanding that you don’t need a lot of the external tools you would with the more mainstream languages is what’s hard imo.
Yeah I bet, I’ve always wanted to learn Erlang. People always speak to highly of it. The guy that made Sonic Pi was saying he wished he would’ve used it because Sonic Pi involves a lot of music loops playing at the same time and stopping individual ones and modifying them etc and because so many of those concepts are baked in he said it would’ve been nice
Clojure : if lisp had an illegitimate baby with java. Add to it the pain of setting up fireplace in vim or having to use emacs. At a former employer we had one area in closure. I could read it without much difficulty but damn if it didn’t take me weeks to write or update it
Perl is a write-only language.
You can write clean Perl easily. But it’s maybe a bit easier to write illegible code in Perl than in most other languages. It’s all up to you though.
I am just regurgitating one of my favorite Perl jokes for a laugh. Though for me the joke contains some truth. Most of the Perl code I’ve ever seen is pretty impenetrable for non-Perl programmers. I quite literally have returned to my own Perl efforts after just a couple of weeks and had some trouble working out what the code is doing (in ways I do not experience with other languages).
When Python was trying to unseat Perl, that in my view was reason alone to prefer it: I didn’t know Python but I could read Python. Though at that point Perl had the benefit of loads of libraries and ubiquity, and Python hadn’t got there yet. But it was enough to have me cheering for Python’s success at the expense of Perl. I get that Perl has many virtues, but they’re nullified by the ugliness and relative inaccessibility of its code in my eyes.
I really hate the magic side-effect variables where you do a pattern match or something and then various obtusely named variables have meaningful values with relation to the last match. To me that’s just flat out bad coding, and it’s built into the language.
The above was my second-favorite Perl joke. My favorite being:
Perl is the vise-grips* of programming languages. It’s a tool that can do most jobs, and it’s the wrong tool for all of them.
*BrEng: mole-grips
Those magic match variables from regexen weren’t very legible if you weren’t a little familiar with them, but they were super useful in lots of cases. Perl could be a godsend to quickly parse lots of text.
I love perl. 20y on I still think in perl.
C++ because you have multiple versions, you can write in different styles (C, OOP, functional, meta-stuff, very low level like assembly, very high level like Python), it has undefined behaviors, and you can waste your whole life optimizing code.
you can waste your whole life
chuckles I am in danger
Any language if the code was written by me
Fearing a bit to say it but Haskell. I know that it is a different concept, but it’s not just that for me. The way the elements are separated, sometimes spaces sometimes symbols, makes it hard for me to understand how things are grouped, and what gets plugged into what.
Haskell for sure has a very sloped learning curve. The functional style, different syntax, a myriad of symbols and pragmas, as well as the tooling around it.
The only reason I was able to pick it up as quick as I did was because I was used to Elm due to my job. Then it was just learning about the IO type (and how to use it), cabal, stack, built-in symbols, and the most common pragmas.
But the symbols part is especially harsh, since symbols only hold meaning if they’re universally understood. Sure, the base- language ones are kinda adopted at this point, so they’ll stay, but the fact that external modules can also make symbols (sometimes without actually-named counterparts) adds some confusion. Like, would you just know what
.:is supposed to mean off the top of your head?Like, would you just know what .: is supposed to mean off the top of your head?
Yeah, it’s point-free shenanigans people use for code-golf and satisfying the linter.
If you caught yourself using it, you should probably reevaluate.
I agree. OCaml too. I think there are several factors that lead to it being very difficult to read other people’s code:
- Currying and lack of syntax in general means you have to be a human parser for basic things like “which part of the text is a function name? which bits are arguments?”. Often it’s impossible to tell without looking up the function definitions.
- The functional style - while generally great - also makes it very tempting for people to write enormous heavily nested functions where the control flow is hard to follow. You sometimes get assignment expressions that are hundreds of lines long.
- Haskel & OCaml feature global type inference. Programmers often omit explicit type annotations which very often means that function types are inferred as generic. This means you lose several huge benefits from static types. For example you can no longer look up the types that will actually be passed into the function, and inferring the authors intent is much harder. It also makes error messages way more confusing.
- I don’t know why but Haskel and OCaml programmers love stupidly short identifiers.
- They also abhor comments.
Same here. The syntax is just different enough from the C family for it to totally scramble my brain.
I like Haskell, but the syntax is probably the worst part about it. The ability to define your own infix operators with arbitrary precedence / associativity is really cool and useful, but can make it a complete mess to read because then you have no idea how any of the operators combine. I vaguely like the syntax, there’s something kind of clean about it, but frankly if it was just a lisp it would be so much easier for people to pick up (aside from the fact that nobody would because it would look like lisp).
I write tons of functional code and am still no fan of Haskell’s syntactical choices.
It’s trying to look like basic English or maths equations, when programming is not that. Programming has more concepts. And those concepts deserve being denoted by punctuation.
C and C++. The pointer syntax being slightly different than the pointer declaration syntax always confuses me to no end. I conceptually under pointers perfectly but their syntax is wack.
C is simple. Like really simple. Hardly anything exists in C lol. You have Integers, floats, chars, arrays, functions, pointers and structs. That’s it.
Therefore reading C isn’t too difficult.
Now doing anything in C? Lol have fun with that, nothing exists in C.
C++, you’re absolutely right lol the standard lib in c++ is so god damn big I don’t even know where to begin when using it. And there’s like a billion different ways to approach a problem there.
I like C. I don’t like working on C just because if you want a hashmap you must first build the universe lol. But c is fun.
I’ve been finding that same fun feeling in Rust though I haven’t used it long enough to know whether that’s just the “ohh new shiny” fun or “I really like this” fun.
Reading anything to do with pointers in C is confusing to me. Sorry to disappoint you.
A pointer is nothing but an integer that “points to” a memory location.
They can feel intimidating because it’s really easy to footgun with them, but they are not as complicated as they appear :)
The pointer syntax being slightly different than the pointer declaration syntax always confuses me to no end. I conceptually under pointers perfectly but their syntax is wack.
Objective-C and Objective-C++ are an abomination. Extending languages with other language constructs is ok, I guess, but I find Apple’s extremely poor documentation to worsen a situation that’s already quite bad.
Objective C++ sounds scary. Two object systems living totally unaware of each other.
INTERCAL seems pretty hard.
For example, you have to occasionally say PLEASE or else the compiler will throw an error calling you unpolite. You can’t also say PLEASE evey time because it will call you overly polite.
Here are some of the other compiler error messages: https://gist.github.com/kconner/a5c73557230dee1f7a3934d6a7abee13
i mean. i like good jokes
But why? insert meme here
The most delciously evil part of INTERCAL is “COMEFROM” (though COMEFROM was proposed a number of times as a joke long before INTERCAL)
The hardest languages to learn are the ones that have a different paradigm than the ones you’re used to.
Most modern languages today somehow derive from C, in a way or another. JavaScript, Go, PHP, Java, C#, even Python… If you’re used to one of these languages, you should be able to get a high level understanding of code written in other languages. Some like Rust can be a bit harder when diving into idiosyncrasies (e.g. borrow checker and lifetimes), but it’s not too hard.
But if I encounter a Lisp, or a more domain-specific language like Julia or Matlab, I need to put in a lot more effort to understand what I’m trying to read. Though Lisps are inherently simple languages, the lack of familiarity with the syntax throws me off.
I’m not much of a programmer, but when I was a kid I used to play around in QBasic. Then dropped all programming for decades and picked up Lua a few years back. Made me realise it’s more of a dialect than a new language.
I had the most problems with Ruby, or was that Rails. However I have to admit I gave up quickly. It left me with the impression the language itself doesn’t do much but the magic is all in the framework. You can’t follow the logic but have to know where things are, you have to know whatever assumptions the framework started with, but they don’t seem to be set anywhere.
That was the paradigm jump I didn’t make, didn’t want to make. APL was just so much more straightforward, because it was logical. Variants of C and Java are all pretty easy. PERL and Groovy have been two of my favorites except I’m a strong believer in strict variable typing. I have to admit Python took some getting used to, because who makes spacing part of your code structure these days: I thought we gave that up many decades ago. The COBOLs of the world are pretty focused - I’m not sure if even call them a programming language, but fairly easy to embed a query or report in a real language
From personal experience making the jump from Python to Julia was overall painless, it was probably made to be as well. I do agree that rust on the other end is something else. Even after clearing the whole rustlings course I was still brute forcing my way through code by relying on the compiler to tell me where borrowers were missing. Spoiler: everywhere!
Malbolge https://en.m.wikipedia.org/wiki/Malbolge
It required a cryptanalyst to write hello world.
I find syntax wise, Rust is very closely bordering on esoteric. My employer is currently considering switching to Rust and I can say working in a department with a bunch of Data Scientists with varying degrees of programming experience and capability, this switch, if it happens, will probably be poorly received.
Prayers man.
We brought in a dept of data scientists when we bought a company.
I never witnessed the worse code ever.
I don’t know if they were all 1y bootcamp grads or something. I thought math formulas was supposed to be elegant. But everything was written top-down, no reusability, like coding excel formulas that feed one cell into another and takes a hour or two to calculate. I nope’d so fast out of one “system” they built which was just daisychaining SQL queries into a new file that is fed into another SQL query repeat 7 times.
Mathematicians and scientists are notoriously awful programmers. They get shit done but with absolutely 0 regard to good practices and reusability.
Would have thought mathematicians would be slightly better at writing functions
It’s kind of like hiring a bunch of physicists to design a bridge. It’ll probably be a great bridge, but also probably overly complex, expensive and late. And for some reason made out of a novel alloy.
deleted by creator
I’ve experienced similar.
One thing that helped: separating research code from production.
Research is to answer a decision problem and much of the optimization problems that are in software engineering do not, and should not, apply.
Once the research problem is answered. Reproducing that answer with production quality systems should be it’s own project. This also serves as a reproduction of the science in the research. Satisfying that hallmark of the scientific method.
Course, getting a company to agree to such an arrangement is near impossible. Especially if they have never been crippled by the mismatch expectations of putting research code in production.
As that is an organizational problem not just an engineering problem, good luck convincing management.
An alternative, if I can’t get such an arrangement is the building a platform that supports integration of research code. That can be… uh… hard. Aside from the people challenges not all tech can support such a platform.
What’s esoteric about Rusts syntax? I can’t relate at all, but maybe I had just the right background of languages commin into Rust.
Bruh on one post people are bandwagoning rust and then on another post people calling it esoteric 🤣 hard to see what’s what past the hype. I mostly code in Python though so I might need to find out for myself
