4 ms·
Functional programming languages (almost always?) come with the baggage of foreign looking syntax. Additionally, imperative is easier in some situations, so hav
by tasn 11mo ago
Functional programming languages (almost always?) come with the baggage of foreign looking syntax. Additionally, imperative is easier in some situations, so having that escape hatch is great.
I think that's why we're seeing a lot of what you're describing. E.g. with Rust you end up writing mostly functional code with a bit of imperative mixed in.
Additional, most software is not pure (human input, disk, network, etc), so a pure first approach ends up being weird for many people.
At least based on my experience.
- deleted 11mo ago[deleted]
- rapind 11mo ago> come with the baggage of foreign looking syntax Maybe they're right about the syntax too though? :)
- kragen 11mo agoWhich one, Erlang, Lisp, or ML?
- nickpeterson 11mo agoHonestly I find ML derived languages the most pleasant to look at.
- kragen 11mo agoI prefer Piet, but it has some real drawbacks when it comes to readability: https://www.dangermouse.net/esoteric/piet/samples.html https://www.dangermouse.net/esoteric/piet/samples.html
- tmtvl 11mo agoLisp syntax is objectively superior because you can write a predicate like thus: (< lower-bound x-coordinate upper-bound) Instead of having to do the awful ampersand dance.
- kragen 11mo agoIn Python or Icon (or Unicon) that's lower_bound < x_coordinate < upper_bound except that usually you want lower_bound <= x_coordinate < upper_bound which is also legal. In Python this is a magical special case, but in Icon/Unicon it falls out somewhat naturally from the language semantics; comparisons don't return Boolean values, but rather fail (returning no value) or succeed (returning a usually unused value which is chosen to be, IIRC, the right-hand operand). And in SQL you have `x-coordinate` between `lower-bound` - 1 and `upper-bound` + 1 which is obviously the best possible syntax.
- rapind 11mo agoML superfan here. I don’t mind lisp simplicity either. Erlang is too alien for me, but maybe once I was used to it.
- impossiblefork 11mo agoIf you start programming in it though, syntax only matters during the first day. Familiarity comes very fast, and if you do five programming exercises, maybe one a day, 'implement a hash map', 'make a small game', etc. you will have no problems whatsoever once the week is done. If you have a course where one day you're supposed to do Haskell and another Erlang, and another LISP, and another Prolog, and there's only one exercise in each language, then you're obviously going to have to waste a lot of time on syntax, but that's never a situation you encounter while actually programming.
- rapind 11mo agoI disagree, at least for my own case. I greatly prefer reading ML code than C style syntax.
- runevault 11mo agoEh, I'd say it depends. I write way more algol-derived language code than ML, yet piped operations being an option over either constant dot operators where every function returns the answer or itself depending on the context or inside out code is beautiful in a way that I've never felt about my C#/C++/etc code. And even Lisp can do that style with arrow macros that exist in at least CL and Clojure (dunno about Racket/other schemes).
- kragen 11mo agoThis is far from true in my experience. I'm no Lisp hater (I wrote a self-compiling compiler in Scheme) but different syntaxes have dramatically different degrees of familiarity, like Latin letters and Cyrillic. How long do you think it would take you to learn to read phonetically in Cyrillic as fast as you do in the Latin script? It takes the humans months or years, if they ever arrive. But, also, some notations are more usable than others, even for experts, just as with other kinds of user interfaces. Flat is better than nested, simple is better than complex, complex is better than complicated, Perl and MUMPS are unnecessarily error-prone, etc.
- kragen 11mo agoRust is not very suitable for functional programming because it is aggressively non-garbage-collected. Any time Rustaceans want to do the kind of immutable DAG thing that gives functional languages so much power, they seem to end up either taking the huge performance and concurrency hit of fine-grained reference counting, or they just stick all their nodes in a big array.
- tayo42 11mo agoUsing a big array has good performance though?
- kragen 11mo agoComputer memory is already a big array. Probably what you are thinking of is that processing array items sequentially is a lot faster than following pointers, but in the cases I'm talking about, you end up using array indices instead of pointers, which isn't much faster.
- gf000 11mo agoYeah, but now logic bugs can cause memory leaks, doing use-after-frees, etc, without any kind of tooling to prevent it (nothing like valgrind to catch them). Sure, they won't crash the program, but sending money from a wrong account is worse than a segfault, imo.
- rao-v 11mo agoExactly this! I’d love a modern C++ like syntax with the expressiveness of python and a mostly functional approach. C# is not that far I suppose from what I want
- tjk 11mo agoEverybody's mileage will vary, but I find contemporary C# to be an impressively well rounded language and ecosystem. It's wonderfully boring, in the most positive sense of the word.
- LogicHound 11mo agoI can't stand modern C#. They've bung in a bunch of new keywords and features that are of dubious benefit every release.
- mrsmrtss 11mo agoI'm interested what are those new keywords and features that are of dubious benefit?
- LogicHound 11mo agoThere is a huge amount of syntactic sugar that has been added over the years that doesn't do whole lot IMO. It is often imported from other languages (usually JavaScript and/or Python). e.g. Just a very simple example to illustrate the point if (customer != null) { customer.Order = GetCurrentOrder(); } vs if (customer is not null) { customer.Order = GetCurrentOrder(); } Is there really any benefit in adding "is/is not"? I would argue no. So I categorise that as being of "dubious benefit" and there are many similar small features, keywords etc. that get added each release where they might save a few lines of code somewhere but I've never seem them used that often.
- mrsmrtss 11mo agoIn your sample there really is no benefit to using the "is" operator over just checking for null (assuming you haven't overloaded the "!=" operator). However, the "is" operator is a lot more powerful, you can match an expression against a pattern with it. Would you say that these samples show no benefit to using the "is" operator? if (obj is string s) { ... } if (date is { Month: 10, Day: <=7, DayOfWeek: DayOfWeek.Friday }) { ... } https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/is https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/patterns https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
- gf000 11mo agoForeign looking is just a person's biases/experience. C is just as foreign looking to a layperson, you just happened to start programming with C-family languages. (Also, as a "gotcha" counterpoint, I can just look up a Haskell symbol in hoogle, but the only language that needs a website to decipher its gibberish type notation is C https://cdecl.org/ https://cdecl.org/ ) Nonetheless, I also heavily dislike non-alphabetical, library-defined symbols (with the exception of math operators), but this is a cheap argument and I don't think this is the primary reason FPs are not more prevalent.
- acdha 11mo agoI think you could construct a stronger version of this complaint as FP languages not prioritizing usability enough. C was never seen as a great language but it was relatively simple to learn to the point that you could have running code doing something you needed without getting hit with a ton of theory first. That code would probably be unsafe in some way but the first impression of “I made a machine do something useful!” carries a lot of weight and anyone not starting with an academic CS background would get that rush faster with most mainstream languages.
- theSIRius 11mo ago> Functional programming languages (almost always?) come with the baggage of foreign looking syntax. At least for me, this was solved by Gleam. The syntax is pretty compact, and, from my experience, the language is easily readable for anyone used to C/C++/TypeScript and even Java. The pure approach may be a bit off-putting at first, but the apprehensions usually disappear after a first big refactoring in the language. With the type system and Gleam's helpful compiler, any significant changes are mostly a breeze, and the code works as expected once it compiles. There are escape hatches to TypeScript/JavaScript and Erlang when necessary. But yeah, this does not really solve the impure edges many people may cut themselves on.
- dragonwriter 11mo ago> Functional programming languages (almost always?) come with the baggage of foreign looking syntax. That increases the activation energy, I guess, for people who have spent their whole programming life inside the algol-derived syntax set of languages, but that’s a box worth getting out of independently of the value of functional programming.