No programming language is obvious to someone who doesn't know any programming. This particular example is even less clear because it's purely abstract; it literally doesn't do anything.
> I'm not sure about the "learn it as a first language" bit.
I think this is very subjective. Our minds have been "poisoned" - or rather trained over years - into a very specific way of thinking about expressions like in the example.
A first programming language, however, assumes that the learner hasn't been preconditioned in any way into a certain paradigm. So just keeping the two rules in mind that 1) evaluation is strictly from left to right and 2) an expression evaluates to a sequence of zero or more values immediately makes sense of the example.
Unfortunately it's incredibly hard to "reset" your mind into a state that doesn't know about variable assignments and thinking of variables as singular slots as is the case in Haskell and most other programming languages.
That's why "intuition" is a very subjective thing - your intuition changes with knowledge and experience and both are hard to suppress.
I remember struggling to understand the x = 7 syntax for storing a value in x. My young self was like “so if x is equal to 7, how come we can write x is equal to 8 later? That doesn’t make sense”
A cool thing about this in Erlang (which I think is the same in Prolog) is that the = operator works almost exactly how you would have expected: it binds the value but then it asserts the binding’s equality. So once you’ve established x = 7, x = 8 is actually an error! Because you’re right, it doesn’t make sense that at one point x = 7 and later the same x = 8!
I get that to some degree, but that code doesn't look like something most people are exposed to, whereas 'x = 10' or something that says 'foreach' seems like it'd make sense with a minimum of explanation to a lot of people.
You could also write the example as a list comprehension, which essentially mimics set-builder notation in math, i.e. "The set of all pairs such that ..."
[(x, y) for x in [1, 2] for y in [7, 8]] // Python (list comprehension)
{(x, y) | x \in {1, 2}, y \in {7, 8}} // math (set-builder notation)
See, the Python code has some hints as to what's going on. If you know that x is a variable, 'for x in' spells it out to some degree. Maybe you don't nail the exact functionality just from looking, but it feels more accessible.
I'll be the first to hate on C++, but the only reason C++ might be considered a "don't learn it as a first language" language, is because it's huge. It's got 40 years worth of baggage, and it's "standard" libraries are an absolute mess. Javascript has a super simple syntax, and it's standard libraries though sometimes a bit idiosyncratic are comparatively clean and pragmatic.
If you just removed like 90% of C++'s useless standard library, and restricted the syntax to purely what's in Strousup's "Tour of C++" book, then I'm pretty sure that would be a pretty acceptable "learn it as a first language" language. Of course in that imaginary world C++ would also not have been deprecated by Rust.
The Python library is even larger and doesn't seem to be a barrier. If you know `std::vector`, `<<`, and `std::sort` it seems you're set to contribute to most code bases.
> C++ would also not have been deprecated by Rust.
In Python the standard library is fairly easily traversed and understood and if there's a better way of doing something it's usually linked I think. In C++ we have.. this..
Python's standard library includes many modules for specialised applications and yet it's surprisingly lacking in fundamental data structures and algorithms. Personally I think that's the wrong way round. Simple things like building dicts from different data structures or working with optional values that can be something or None just aren't there and you always seem to end up with some kind of utils.py full of hand-written functions to do these things that everyone writes again every time when they would have been either built into the syntax or a one-liner using the standard library in some other languages.
I agree that the C++ example is (one reason) why modern C++ has jumped the shark.
I agree that the example is crazy. But the function is not fine, it's a testament to how unhinged the C++ standards committee is. Its existence is proof that the problems of C++ are not just with its history, but that it is an ongoing snowball of incompetence and bad decisions.
It is hard to know what you are talking about. It applies linear operators to an input sequence, defaulting to + and x, or whatever you specify. It is like inner_product, but sequence order is not specified.
There is a "range" version in C++20 that in use looks more like in other languages. (It is technically C++23, but appears in libraries shipped with C++20.)
It seems like a small thing, but everything about it is just slightly wrong. That it's called `transform_reduce` and not just `reduce`. The fact that it was in C++17 alongside a function called `reduce` that's basically useless. Why was it not in C++14? Why was it not in C++11? Why was it not in C++03?
That in 2017 the C++ standard committee was still introducing misdesigned cruft like std::reduce to the language says everything you need to be about C++, it's a clusterfuck.
Thanks for the heads up. From the outside looking in, my perception of the difficulty of learning C++ is knowing what is idiomatic or not, with the understanding that that differs depending on who you work for and with.
It is the same as in other languages: you do the simplest thing that gets the job done. Loops, particularly C-style "for" loops, often do not count as simple, despite their familiarity: std:: algorithms leave less scope for error.
Ah fair. Though I do think the issue they meant is perhaps the C++‘s STL is not fleshed out enough to be as ergonomic and useful as Python.
Python’s standard library is not without its faults but I’m always so frustrated that the C++ STL stops just short of providing many things, and when it does, it requires writing out so much verbiage.
I don't think it is an overstatement to say that that imaginary world C++ would have been deprecated by Rust.
C++ complexity is also its strength. Highly backward compatible, even with C, and multiparadigm. It has classes, but you don't have to use them, it has exceptions, but you don't have to use them, it has templates, lambdas, smart pointers,... and again, you don't have to use them, but they are here if you need them. Even the "deprecated" features of C++ (like most things related to raw pointers) are heavily used today, even in new projects, because they are useful.
Strip 90% of "deprecated" C++ and what you get is essentially Rust, but worse because it still has its C baggage without the advantage of being mostly compatible with C.
How much of that can be attributed to it not having as much time to attract cruft? See Haskell, a very minimal and carefully designed language with a heap of complex and contrary extensions.
In my uni they still teach C++ as a first language, that's why the "don't learn it as a first language" got me confused. The core language is very useful for learning programming, it is actually very clean.
Maybe he only knew C as you say. I did C++ professionally for a while. Not properly, just updating models in derivatives trading systems. I remember reading 3 Scott Meyer books, the Effective Programming series, at the time, they were a tour de force. Loved that guy. I've lost track of everything since 11 or whenever they introduced move semantics. One day I might go back to it.
It was my first proper language too, if you discount what I did on my graphical calculator. Now I'm a Rubyist, heart and soul, make of that what you will.
Has it got currying? Partially applied functions passed around in folds and traverses are horribly difficult to read for beginners. Example: an Advent of Code solution posted in r/haskell for Day 10 this year, tell me how long it takes you to understand the function cycleStrengths.
signalStrength cycle x = cycle \* x
cycleGaps = [19, 40, 40, 40, 40, 40]
cycleStrengths = foldr a (const []) cycleGaps . (\x -> (1, x))
where
a n r (i, xs) = signalStrength m y : r (m, ys)
where
m = i + n
ys@(y : _) = drop n xs
That kind of code is sometimes easier to write than read… you build it up incrementally. On the other hand it’s easy to refactor this to make it readable. Is Haskell supposed to be an easy language for beginners? Is Verse? Not every language should be.
> [Paraphrasing] Is Verse supposed to be an easy language for beginners ?
Yes! Well that was the point of my comment. Maybe you have a different interpretation of 'Learnable as a first language' from the article, which is fine, not interested in arguing about that.
I might be totally off, as I don't know any vercel. But the declarations look like "x can be 1 or 2, y can be 7 or 8, and let's declare a superposed tuple of these which could be any combination of the values". I don't see the point, but that's what I understand by reading raw syntax.
That's the usual way to read it, yes. The point is that you can then ask it e.g. to "find a tuple where x > y", and later expressions will be evaluated only for tuples that meet this condition.
In logic programming it's known as the "generate and test" pattern, where you declare the tuple and the program logically generates all its possible values, and then tests each value for compliance. The runtime usually will ensure to make this in an efficient way.
P.S. See the definition of the "amb" operator in typical logic programming languages:
It's the cartesian product. Think of it as a table with x labeling the top (x-axis) and y labeling the left side (y-axis). The cells of the table are the result of the product.
x 1 2
y |--------------
7 | (1,7) (2,7)
8 | (1,8) (2,8)
Except, as the slides indicate, sequences of values are not sets. They are ordered. You can also, as they mention, refer to "y" in the definition of "x". This is like set union, but it is, again, sensitive to ordering of elements.
I'm not sure about the "learn it as a first language" bit.
My university taught Haskell as its intro language to math and science students, and the people who had the most problems where those who already knew a bit of programming. People for whom Haskell genuinely was their first introduction to a programming language on the whole had no problem getting it. I imagine this might be the same.
The main downside with the approach was that when these people who had just learnt Haskell moved on to the next programming course, that was taught using Java, they had a really hard time understanding what was going on.
Looks interesting though; that's a really bright group of people. Be curious to see where their project ends up.