I Probably Hate Writing Code in Your Favorite Language
lambdaland.org
lambdaland.org
Functional programming just has something magical about it that really draws certain kinds of people in.
I wonder if it has to do with the fact that, when you play inside the boundaries of what a functional programming language can do, everything feels so neat. So tidy. Like a game. Or using lego bricks. It almost feels insane to do things any other way.
But then again, most problems live in the real world, where things are not neat, or tidy, or like a game. I wonder if this is why you tend not to see functional programming languages more broadly used...?
Personally, I need transparency and understand everything step by step. But there are those that threat a function/process like a blackbox and just build pipes based on some defined axiomes. The latter also seems to do quite well in math.
The way my brain works is by turning all problems into spatial problems. Programs take the form of a large graph with a function or other operation at each node. Generally, I'm modeling data flow through the graph. I can keep a fair amount of detail associated with any node, but it takes effort. There's a lot of information floating around.
OOP just kind of naturally falls out of this kind of thinking. By collecting parts of the program into discrete objects that do their own thing, large parts of the graph can be collapsed into a single node. Data flows into an object, data flows out. No need to spend the mental effort of knowing what happens inside the box. I can just simply trust that I wrote an object to do what it says it does.
Of course this approach often fails and I have to be much more thorough. If I can focus on a small section of the program, the graph becomes almost an arbitrary syntax tree. The past couple of weeks I've been way in the weeds with a microcontroller. At some point I've started modeling parts of the program in terms of assembly instructions and CPU implementation details.
1. Until now most functional programming languages have had abysmal syntax. I'm sure I will get downvoted for this but have you seen Lisp? I do not want to program in raw AST. ML is also pretty bad. Honestly the hardest thing learning OCaml was figuring out where to put the brackets and semicolons. I am 100% serious. (Well, that and fighting OPAM bugs.)
Rust is functional but the syntax is 10 times easier to read and write. I think other languages will follow.
2. Functional programming has been synonymous with pure functional programming due to Haskell. Honestly I didn't even realise there were impure functional languages until relatively recently. I thought to be "functional" a language had to be pure.
Again Rust is functional and impure.
So I think it's really that most "practical" or "engineering" languages just happened to be not functional until now because the idea of functional programming was hidden in weird and difficult to read academic languages.
There's clearly nothing intrinsic to the functional paradigm that would mean it can't be used in the real world (otherwise Rust wouldn't be so popular).
How much time have you spent writing in lisps?
I'm definitely an OOP person, but I spent a couple of years writing Clojure. After a few hours of working in it, the syntax just... disappears. I installed two tools in vim to help: one colored parentheses to match corresponding pairs, and the other inferred parentheses from indentation. After a week, I removed the first because I realized I literally never looked at them. Ever.
The reason I didn't fall in love with lisps is because it's just hard for me to work in them. Yes, I'm _very_ productive once I get into flow state - but it took about a half hour each session before I got there. There were many days where I never got into that state for more than a few minutes here and there. It was a terrible experience as a result.
With Python - and other OO languages - I can look at some code and almost immediately know what it does. It's just not like that for me in lisp.
I use an adaptation of parinfer I found in github. It required a bit of tweaking , including adding a keybinding to turn it off, because sometimes it fights what you are trying to do. Its opposite mode (indentation from parens) does not work at all.
> hour each session before I got there
That could just be the Clojure, doing everything with immutable sequences. If the obvious way (at least to you, if not generally) to express something is OOP with mutable classes, then you have to solve a puzzle before things start to flow.
It's been years now, but I believe it was "parinfer". This specific plugin might not be it, but it looks very similar at least: https://github.com/gpanders/nvim-parinfer
I wouldn't call Rust "functional and impure." It has pattern matching (like in ML), and it has traits (which are reminiscent of Haskell's typeclasses) instead of object-oriented classes (like C++), but most programming in it is very much centered around mutable state and pointers and memory, like a higher-level C; hence, it's impure and imperative, not functional.
A functional and impure language would be more like OCaml, Standard ML, or Scheme. Those all give you unrestricted access to exceptions and mutable cells of memory without restricting it behind a layer of monads, like in Haskell. They just don't really encourage it.
> Rust is functional but the syntax is 10 times easier to read and write. I think other languages will follow.
People complain all the time about Rust syntax looking cryptic and difficult to read.
Also, I'm familiar with both Haskell and Rust syntax, and although many would disagree with what I'm saying here, I don't think Haskell syntax is any harder to read than Rust's. And Standard ML even has much simpler syntax than Rust (although it's much less alive than OCaml, whose syntax is a bit more complicated). I really think it's a matter of what you're used to.
> People complain all the time about Rust syntax looking cryptic and difficult to read.
They're talking about all the borrowing, lifetime and generics syntax. Not the basic blocks and semicolons.
Also, I just noticed this part again:
> Honestly the hardest thing learning OCaml was figuring out where to put the brackets and semicolons. I am 100% serious.
Unironically, I'd recommend Haskell, or another programming language with similar whitespace-sensitive syntax. I'm more familiar with Haskell than OCaml (though inexperienced in both), and the semicolons and other delimiters actually got me as well.
> They're talking about all the borrowing, lifetime and generics syntax. Not the basic blocks and semicolons.
That's half the syntax to get confused about. But, ignoring that, people also get confused by the implicit returns at the ends of blocks.
The overarching problem is that functional programming trades extra thought now for extra benefit later.
Inexperienced programmers hate functional programming because they like "magic". They are having a tough enough time just getting the task at hand finished and the more stuff done for them without thinking, the better.
Inexperienced programmers don't want to think about multiple threads. They don't want to think about the event loop or sockets. They don't want to think about the state of the protocol and why it shouldn't update multiple steps. etc.
The only way for that kind of magic to happen is to have a bunch of implicit state that sits invisibly in the background. It's either global or part of a single mega-struct that might as well be global.
However, if an inexperienced programmer sticks around long enough they eventually run into a Heisenbug that is difficult to replicate. In order to run down the bug, they start having to isolate everything. Suddenly, the words of the old greybreard start coming back: "Immutable is good" "Time needs to be an explicit part of your state" and "bytes in, bytes out--putting the bytes on the wire is a different function" and ...
At that moment, they become an acolyte of functional programming and now qualify as an experienced programmer.
They each have their own set of advantages and disadvantages.
problem : solution
and I think sometimes certain languages fit the solution space better than others.
I think it might have to do with expressiveness.
If I want to write a CLI program and parse a bunch of arguments in different ways, I think python + argparse is a pretty effective way to do that.
At one point, I think perl was the most generally expressive language I'd ever used. I could think of something, and then dump what was in my head into perl with little or no friction. do until! unless!
(of course, the practical aspect of that was that if it is expressive that way for everyone, you will have to understand how someone else thinks to understand their perl program)
The language I would like to write in.
The language in which I would like to debug and maintain code written by someone else.
> make the language and syntax as simple as possible, and then even simpler at the expense of expressivity
I understand why people say this because you can write these small highly condensed statements which would take a lot of code otherwise to do. I think it's probably the wrong word though. These languages generally prevent you from manually managing memory, which ironically makes expressing some designs or patterns impractical. If you want to express say writing a performant garbage collected language or something, a language like c or c++ is ironically more expressive than these other higher level functional languages with a runtime gc.
I agree with the author about Rust in that it has a beautiful and expressive type system. The fact that it can be used for systems programming, has a modern package system, and can be deployed as a single static binary are bonuses.
Rust is a perfect little Go/Java replacement for microservices and web servers.
But I have decided that I hate it enough that I wouldn't accept a job that required me to do much with it. I would be unhappy in such a position.
It's an unusual stance for me to take -- I am proficient in a number of languages that I'm not that keen on, but can tolerate them for a paycheck. For whatever reason, Rust is an exception. I'm not sure why.
But I'm a programming polyglot. Learning new languages is pretty easy (if you already know the paradigm of the language, then it's just a matter of syntax), so why not?
[1] It's important to me mostly because learning a new language or other skill often gives me a new understanding or insight into programming overall. Also, having a wide skillset makes me qualified for a wider selection of jobs, making it more likely that I can find one that excites me in some way.
Why do you think that is?
> Why do you think that is?
Because time travel, as far as we can tell, is not possible.
At least in the case of Kubernetes, Rust 1.0 wasn't even around until the year after it was first released (Kubernetes 2014, Rust 1.0 2015). It also came out of Google and Go was one of its blessed languages at the time (and today). Given Rust 1.0 wasn't out yet, I'd be surprised if it got more than five seconds of consideration by the team developing Kubernetes, if it was even on their radar at the time they started development.
def winning_team(game_log: GameLog) -> Team:
team_a, team_b = get_teams(game_log)
points_a = get_points(game_log, team_a)
points_b = get_points(game_log, team_b)
return team_a if points_a > points_b else team_b def winning_team(game_log: GameLog) -> Team:
return max(
get_teams(game_log),
key=lambda t: get_points(game_log, t)
)FWIW, I do not like any OO languages at all.
The other is c, which I went to in the 90s, that seemed to have started getting hate from everyone these days :) I prefer the K&R dialect is the version I started with.
I struggle to take anyone very seriously that expresses a profound negative opinion about C - it is still so ubiquitous and odds are overwhelming that the person expressing this uses somewhere in their stack many libraries written in C anyway.
I'd wager this is coming from the Rust ecosystem rising in prominence the last 10 years and Rust adherents being really passionate about that (cool! I take no opinion either way, please don't savagely downvote me).
I find all such debates tiresome, I am much more interested in the why of doing something than the "how." A programming language is a tool to me, nothing more. If the tool sucks I will choose a different one and probably feel zero emotions about it, but acknowledge not everyone is this way.
I like C, and I do think the hate mostly comes from the loud zealots in the Rust crowd, but this doesn't make sense to me. I hate car-centric planning, the fact that it's ubiquitous and that I drive around my city doesn't really affect the validity of my opinion.
It's a very silly argument, in my opinion. Better ones are actually about what makes Rust good, not that the alternative are evil.
> I struggle to take anyone very seriously that expresses a profound negative opinion about [a language that] is still so ubiquitous and […] the person expressing this [probably] uses somewhere in their stack
Are you saying that because C is popular and widely used, someone can't credibly hold a negative opinion on it? Are we required to think highly of things because they are popular?
Luckily my opinion doesn’t matter and can be ignored.
Those OpenSSH vulnerabilities really get stale you know...
>The net effect of exploiting CVE-2024-6387 is a full system compromise and takeover, enabling threat actors to execute arbitrary code with the highest privileges, subvert security mechanisms, data theft, and even maintain persistent access.
Ah, the joys of C.
if {"Bjarne Stroustrup:
There are only two kinds of languages:
the ones people complain about and
the ones nobody uses."} == True &
{"Your favorite programming language is probably used a lot"} == True then:
return {"Must hate and complain about your programming language"}...
> The thing I hate about all of the languages I listed is their emphasis on mutation. When I call a function and pass it a list or object or whatever, I have no guarantees about that thing’s value when the function returns.
This is not true for C++, where the 'const' keyword allows you to disallow mutation. Perhaps the author would complain that this behavior isn't the default, but the functionality exists.
int foo(const int &x) {
int &y { const_cast<int &>(x) };
y += 1;
return y;
}
It may be really bad style, but not mutating const references is not enforced by the compiler. Hence you aren't guaranteed that your const references actually stay unmodified if you pass them to a function.