John Carmack on mutable variables

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.

> come with the baggage of foreign looking syntax

Maybe they're right about the syntax too though? :)

Rust 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.

Which one, Erlang, Lisp, or ML?

Using a big array has good performance though?

Computer 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.

Honestly I find ML derived languages the most pleasant to look at.

Exactly 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

Everybody'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.

I can't stand modern C#. They've bung in a bunch of new keywords and features that are of dubious benefit every release.

I'm interested what are those new keywords and features that are of dubious benefit?

Lisp 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.

Foreign 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/ )

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.

Yeah, 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.

There 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.

In 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-ref... https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

> 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.

The issue is that I dislike the overall mentality of just adding a bunch of language features. Things just seem to be dumped in each release and I think to myself "When I am going to use that?".

> Would you say that these samples show no benefit to using the "is" operator?

I didn't say no benefit. I said dubious benefit.

I didn't really want to get into discussing specific operators, but lets just use your date example:

   if (date is { Month: 10, Day: <=7, DayOfWeek: DayOfWeek.Friday }) { ... }

This following would do the same thing before the is operator:

    static bool IsFirstFridayOfOctober(DateTime date)
    {
        return date.Month == 10
            && date.Day <= 7
            && date.DayOfWeek == DayOfWeek.Friday;
    }

And then:

    if IsFirstFridayOfOctober(date) {
       ...
    }

I understand it is more verbose. But do we really need a new operator for this? I was getting on fine without it.

Each release there seems to be more of these language features and half the time I have a hard time remembering that they even exist.

Each time I meet with other .NET developers either virtually or in Person they all seem to be salivating over this stuff and I feel like I've walked in on some sort of cult meeting.

ML superfan here. I don’t mind lisp simplicity either. Erlang is too alien for me, but maybe once I was used to it.

I agree that they should not add new stuff lightly, but the "is" operator actually should be looked together with switch expression in the context of pattern matching. How else could you enable powerful and succint pattern matching in c#?

> In your sample there really is no benefit to using the "is" operator over just checking for null

Microsoft give the same example though. I understand what hes saying, theres conceptual overlap between is and ==. Many ways to do the same thing.

Why couldnt it just be...

if (obj == string s) { ... }

Arguments about whether the is and switch operators should exist is missing the forest for the trees. I am sure there are circumstances where it very useful.

It isn't any one language feature it is the mentality of both the developer community and Microsoft.

> I agree that they should not add new stuff lightly

It seems though kinda do though. I am not the first person to complain that they add syntactic sugar that doesn't really benefit anything.

e.g. https://devclass.com/2024/04/26/new-c-12-feature-proves-cont...

I have a raft of other complaints outside of language features. Some of these are to do with the community itself which only recognise something existing when Microsoft has officially blessed it, it is like everyone has received the official permission to talk about a feature. Hot Reload was disabled in .NET 6 IIRC for dubious reasons.

> 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.

Scala

I 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.

If 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.

I disagree, at least for my own case. I greatly prefer reading ML code than C style syntax.

In Python '==' and 'is' are not the same thing. '==' checks for equality, 'is' for identity.

In 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.

I am aware. I probably should have said "inspired".

Eh, 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).

This 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.

I shouldn't have mentioned LISP because I don't use it and I actually find the parentheses to be annoying, but it's a paradigm and you need them. Cyrillic at full speed is obviously weeks. But Erlang is very math-notation-y and when I introduced people to some Erlang code I'd written they understood it once I'd given a presentation on it and were then able to do similar things.