There's a lot of bummed out comments in here about the syntax, but to me it looks a lot like what someone might see in a reimagined Typescript. Maybe a little Haskell thrown in for good measure. I agree they probably would have been better served just using an existing language with loads of existing tutorials like C# or Python, but if they're going to make something totally from scratch, I think a lot of decisions will actually make the language pretty easy to learn.
Everything being an expression should prevent a big trip hazard for new developers. As someone who teaches programming a lot, expressions vs statements vs special forms really confuses new developers.
In a lot of ways, this seems like a lot of good ideas from Haskell and Typescript, put into a straightforward syntax. I'd bet I wouldn't even think about the syntax after a week of cranking out code.
And the possibly to have dependent types down the road is very exciting! That would make things like STM so much easier, which would help immensely with scaling code.
> There's a lot of bummed out comments in here about the syntax
Consider the target audience - first time programmers. Verse has a syntax without the historical baggage of C, but still rather conventional. They avoided going off into functional strangeness land. ("Daddy, what's a monad?")
Define and initialize :=
Equality test =
Assignment set a := b
And and
Or or
Programming languages have settled on '=' for assignment and '==' for equality comparison. Teaching people non-standard syntax because you think it might be easier is just doing them a disservice. Everyone I know that started with Pascal was mostly pissed that they didn't learn a language actually used in industry and had to re-learn the syntax. It's not like mathematical notation is intuitive in some way either - humanity needed several thousand years before we came up with something ergonomic, plus '=' is used for assignment in math just as often too. At least I do not know of any mathematician who uses ':=' to denote assigning a value to a name.
> Programming languages have settled on '=' for assignment and '==' for equality comparison.
Certainly not all. "=" is a poor choice for assignment as it has a totally different meaning in maths. Algol and Pascal got this right with ":=". Fortran got it wrong here.
> plus '=' is used for assignment in math just as often too
No it's a relational operator in math, so "x = x + 1" does not have the same meaning as assignment to a mutable variable.
Most programming languages but not all. Three prominent examples are Pascal which you mention, OCaml, and the POSIX `test`/`[` command which all use `=` for equality. (More specifically, for structural equality, in the case of OCaml.)
More intuitive to complete beginners and definitely not unheard of.
In mathematics, I have seen both `:=` and `\equiv` for assignment. But Go and Pascal also use `:=`. Of these, I would consider Go quite widely used in the industry.
Go only uses := for declare & assign. For simple assignment it's =, and equality is still ==. So I would say it is barely different to the norm.
POSIX `[` is clearly insane so let's ignore that.
Which leaves Pascal and OCaml both of which are quite niche.
I think he's right. It's definitely not worth going against the grain with this syntax, and it's debatable if it's even that bad in isolation. I seriously doubt beginners struggle with it.
This is textbook bikeshedding. If you have a bias for C syntax, everything else will look niche, weird, or "clearly insane" to you. But there's no reason that we should prefer C's syntactic decisions for assignment and equality operators in a non-C language. Go itself deviated from them, and the authors were instrumental to C itself.
> But there's no reason that we should prefer C's syntactic decisions for assignment and equality operators in a non-C language.
Yes there is - because almost every language uses the same convention, and it's a totally reasonable one. You have to have a really good reason to go against that and I don't see one.
> Go itself deviated from them
Go didn't deviate from the C convention. It just added an extra shorthand operator to simultaneously declare and initialise variables. The meanings of `=` and `==` are the same in Go as in C.
> or "clearly insane" to you
I wasn't saying the use of `=` for equality is clearly insane. `[` is clearly insane for other reasons.
In Verse there's no such thing as equality comparison. Assignment is the only thing that = does.If you want to do something if two things are equal, you attempt the assignment and whether this is logically consistent with the rest of the program determines whether the other things are executed.
One thing I noticed when I was in college was that the basics of FP is not hard, in fact it seems way easier (from my data annecdote).
In my university CS course, we start with FP (using Haskell), and in a course with one of the biggest number of dropouts un the first year, FP wasn’t really a reason for it, in fact, from the ten 1st year classes FP was in the top half in success.
BUT what I actually took from that experience was that the students having more trouble with FP (excluding dropouts that failed everything) were actually people that had programing experience before college. For the rest of the world pure functions are easy and “x = x + 1” is confusing as hell.
To note that even though we used haskell, monads were just a light touch at the end mostly to use IO. Haskell has an intrepeter, so you could have a language that mimics how you wrote functions before. It also helped that we learned recursion paralel with induction on a math class, so we where recursing over a Natural Int type on FP while difining naturals through induction on a math intro class (and proofs over inductive definitions are usually do e with recursion).
FP suffers from
* unfamiliarity from the general programing community
* bad tooling due to smaller community
* people very vocal about a language like haskell which has research and teaching before production in its goals
* no decent bridge from the academia ivory to industry.
Some languages like elm most issues but suffer from smaller community and weird dictator.
Erlang was industry first but had a very small community (thus tooling), until elixir came aling decades later. And its focus get “solved” at a different layer/abstraction level by k8s.
Ocaml has shit tooling
F# is Microsoft ocaml, but suffers from most things you want to use with it are tailored for C#.
Lisp derivatives seem to live in a world of their own. Closure seems popular, and i guess emacs will never be irrelevant. And in lisps you have to learn all the vocabulary as each project is almost its own language.
So we need an FP language doing what GoLang did to C++.
Few features, very good tooling and libraries (as in golang has a formatter, builder, dependency manager, etc all on its “compiler”, and strong std lib), easy to read. Basically focusing on Developer productivity from hour 1. An “ML for the masses”, just like go was intended for devs straight out of college to be productive on day one.
True story: when I started programming at age 11, in the book I saw a pair of assignments like:
x = x + y
y = y + 1
(or whatever). I was thinking, what, that has no solutions!
It's just due to notations; abusing the sacrosanct equal sign for something different. People otherwise have no problem with the idea of a datum being updated in place; it's part of everyday experience.
You got me thinking and I think part of what it comes down to for typed FP languages is that you can either generally
1) Go for a simple design, but having poor interop with existing ecosystems because the language lacks equivalent features. I see Elm in this camp, and it's hard to live in because the FP community has fewer people than other communities to build up another ecosystem
2) Go for a more fully featured design, integrating with some ecosystem (like F#, Scala), but you end up with multiple overlapping concepts and inconsistency in the native language's ecosystem
It seems like dynamic FP languages are the only ones to get away with a simple core and wide ecosystem by avoiding the need for features that are important for writing modular code in typed MLs. OCaml is probably closest to the sweet spot as a language+ecosystem, but the language tools are a bit weak coming from other platforms
> So we need an FP language doing what GoLang did to C++.
What we need is an FP language that doesn't pretend that outside world doesn't exist. A pragmatical one.
This is why Erlang/Elixir or even C# or hell even Javascript/Typescript are better FPs for the vast majority of programmers (and beginner programmers, too) than Haskell.
We have a few of those, they just aren't popular. Ocaml and F# both fit, as well as ocamlish langs like rescript, which is really underrated imo.
There's also racket, which I think people give too much credit to as a teaching language, but is genuinely good and lets you easily separate FP from immutability semantics which tend to get conflated in this conversation. Janet, same, but with a different approach to that. Clojure, which is very practical and enforces the kind of constraints that make you think in a functional way.
If I was teaching programming from scratch to a beginner without a specific end goal I'd likely use one of these. I have taught total beginners and have observed a moderately functional style is intuitive to them. Rarely see a totally new programmer bust out the for loop once you show them map, etc.
Unfortunately when I've taught programming before it was with the specific goal of web development so JS was the only real choice.
> What we need is an FP language that doesn't pretend that outside world doesn't exist. A pragmatical one.
yes, anything focusing on devs being actually productive has to be pragmatic. So, yeah, real world exists, IO needs to be "easy/simple", just like compiling should be fast, good error messages, etc. Lots of constraints, Go is nice because it is "good enough" at everything. So it's productive general programming language.
> This is why Erlang/Elixir or even C# or hell even Javascript/Typescript are better FPs for the vast majority of programmers (and beginner programmers, too) than Haskell.
Disagree here. Fully agree those and pretty much all popular languages are better than haskell for the very mast majority of devs including beginner on actually delivering something aka work.
I disagree that haskell is worse for somebody that never actually programmed to learn programming (which is fundamentally different than creating an working application or modifying one), specially at a CS college/university course, than any of the languages you listed.
"basic" Haskell is extremely simple. And it's syntax mirrors what you would typically use when are doing something with functions during your high school. Recursion is not harder than loops, the hard part is going from lots of familiarity with one to the other. I've seen people learning imperative first and functional first at different places, and I can tell you that the confusion first timers face getting to understand a loop is not smaller than recursion(again "x = x +1" hits hard against everything you see in school until programming, re-assigning is evil for teaching).
With recursion, haskell's enums/unions equivalent, and haskell's interface equivalent, you can get really far!
So you won't hit haskell issues while teaching because:
* problems/assignments can be self contained, you don't need to reach for libraries to make simple compiler for example, so you don't have the ivory tower of type category, all conversations about monads, someone else code using unfamiliar lingo/code
* due to good interpreter, IO can be teached last, and can always be and should be only a layer over the rest of the code, and once familiar with the rest, writing some outer functions using do notation to pass to your core isn't troublesome to understand.
F# and Ocaml are not as nice for that purpose, as polymorphism/generics is better teached with haskell, and the language is more consistent without objects.
Racket and some lisps are nice, but i would say that Type checking is important for teaching, due to the whole concept of change data from one thing to another, gets easier to explain, the compiler gives some help as well.
Teaching 1st timers (assuming college) with Haskell Drawbacks IMO are only:
* reaching for out of the class stuff, online discussions and public haskell libraries are hell due to academic mismatch.
with too much
* while type checking and compiler messages are a nice help teaching, they can also have the opposite effect with cryptic messages if for some reason there was some heavy polymorphic/generic code.
For a more general teaching, I'll add the drawback of not being able to do what the general crowd thinks of a "app" or "web app" etc, easily. JS just working on a browser is great, swift playgrounds are great, ruby has rails, etc.
In general it's a mess. Very big language, so C++ issues.
Different communities liking different subsets.
Plenty of people "having to" use it, causing annoyance/hate.
It's not great for teaching due to not only being big, but tooling for first time usage is also not great, and it doesn't hit the nice things about FP for first time programers:
* functional syntax very similar to the way you defined functions in high school math class, or intros in college.
```
f : Z -> Z
f(x) = x + 1
```
is
```
f :: Int -> Int
f x = x + 1
```
in haskell (you can also omit domains/types/sets/signature in both). Familiarity is very important, which is why most programers do not like functional, and most people that haven't learned to program yet can start with it arguably more easily
just not having statements, and everything being immutable is really nice (x=x+1 is cancer).
Scala then has a whole lot of "class" stuff on top.
The main problem with using an established language like C# or Python in an embedded context is that they come with an expectation that the existing library ecosystem is supported. And that’s often just not realistic.
The security implications of embedding a language like Python can be massive. Even the most basic libraries would be broken (e.g. a sandboxed script won’t be able to read and write files). And it may be just too much of a burden to try to enable decades of legacy cruft built with different assumptions than the host app (e.g. blocking vs async).
You end up with a halfway language that has the syntax but none of the ecosystem. And that’s a poor experience for a new developer who googles a Python tutorial, copy-pastes code into Fancy Metaverse App, and is immediately greeted by a horde of mysterious errors.
I don’t see it like that. Because most of the tooling and ecosystem will work fine. No need to reinvent linters, formatters and dependency infrastructure. Perhaps slightly, 20% of the effort. Also, a subset of a language that does not include the batteries/platform is what made Node (and JavaScript as a general purpose language) possible and eventually very popular. Pragmatic communities deal very well with problems like these. Blender uses Python as scripting language and has tons of amazing plugins. I understand that Epic wouldn’t prefer a dynamic language (everything is a mutable object) though.
Everything being an expression should prevent a big trip hazard for new developers. As someone who teaches programming a lot, expressions vs statements vs special forms really confuses new developers.
In a lot of ways, this seems like a lot of good ideas from Haskell and Typescript, put into a straightforward syntax. I'd bet I wouldn't even think about the syntax after a week of cranking out code.
And the possibly to have dependent types down the road is very exciting! That would make things like STM so much easier, which would help immensely with scaling code.