Comment by andrewstuart | Hacker News Reader

Comment by andrewstuart | Hacker News Reader

edit: these comments are general, not directed at Val.

A humble suggestion to anyone coming up with a new language.

Please make it as familiar as possible.

For example, do you really need to come up with some new syntax for defining a function, or specifying types and returns?

If you want people to use your new language, reduce the cognitive load - do things the same as other languages and be different only where you must.

Every time you come up with some completely alien programming construct, you have set a barrier to learning. Coming up with a new language should, for the most part, be an exercise in copying the best of how other extremely popular languages do things, and on top of that build in the necessary differences that make your language special.

Also, less is more. For example, one of the reasons Rust is so complex and intimidating is it has six sublanguages https://gist.github.com/brendanzab/d41c3ae485d66c07178749eae...

    the expression language
        unsafe runtime language
        safe runtime language
        compile time language
    the type language
    the trait language
    the macro language
    the attribute language

Whereas Zig goes the other direction and attempts to make everything programmable in the one core language, even ditching macros entirely. https://ziglang.org/learn/overview/. In Zig you can write compile time code in the same language and same code base.

I put forward these suggestions not as a language edxpert - I am far from it - instead I put them forward as a frustrated learner wanting to do new things and looking at new languages and thinking "shit, I already work with three of four languages plus any number of subtechnologies on a given system, I just don't have time/headspace to learn a programming language with six sub languages".

I disagree. Syntax is the thing everyone loves to comment on because of the bikeshed effect, but it's probably the quickest aspect of a new language to learn. If you're already creating a new language and have the opportunity to fix some things that make older languages harder to remember, parse, or type, why not take it?

Alternatively, where the semantics are different to existing languages, try to make the syntax different too. Languages which look the same as existing ones and behave differently are pretty rough going for newcomers and anyone programming in multiple languages.

I probably should have said "did you really need the syntax and the behavior to be different?"

My point is not so much about syntax, it is about unnecessarily doing things in a conceptually different way.

If different behavior at a given point is core to what makes your language special then sure thing, make it behave different, but implementing some different behavior without a significant payoff only makes your new language harder to grasp.

Presumably you are making a language because you have some core concepts or beliefs you want to bring to life - all I'm saying is - make that happen, and make the rest as familiar as possible for most programmers.

One reason I prefer Erlang to Elixir is that I appreciate the fact that Erlang syntax is very different, and I feel like it helps me think in Erlang. I don’t think about Python or Ruby.

Reminds me of Bjarne Stroustrup talking about how every time they add a new feature to the language, it's unfamiliar to anyone so everyone wants it to be REALLY LOUD AND OBVIOUS. "Stand back! I'm going to use a LAMBDA here!" But, after a short time, the new features are so common and familiar that everyone starts complaining about how loud they are. "Why is the syntax for lambdas so noisy! [](){}! Gah! Can we at least make the () optional to quiet it down a bit??"

They do have a good reason to do what they do though. They explicitly say that they’re going for a language where you can pretend there are no references and things are just mutable values. And you can’t really do this without coming up with new names. Because of course there are references under the hood.

If Rust goes the explicit modifier route, e.g. something can be & and also mut, and you need to know what these are, Val goes the implied behavior route where a ‘set’ parameter can be set, while a ‘let’ parameter can’t.

If they didn’t come up with new semantics, they’d just be making a Rust clone. I for one am very looking forward to how Val develops. Currently it seems like it can offer similar guarantees to Rust while using a simpler mental model to deal with.

I’m curious to see how they are going to tackle concurrency. Their roadmap outlines that as one of the trickier parts given the semantics that they’re going for.

I never get this argument. The syntax is important for consistency, but in another sense is trivial. It's the smallest thing about a new language that you have to learn, I don't understand why people get hung up on it.

I often find people get very hung up on it because they don't have much else to talk about. The look and feel of the syntax is the least important part of a language but its also the easiest to complain about.

This syntax looks almost exactly like Swift, which is also where it borrows its semantics from.

Yeah, it feels like Swift with lifetimes (which are coming to Swift). Other than the abstract benefits of mutable value semantics for generics, I wonder what would make one reach for Val over Swift (or going the other way, Rust)

Adobe likes Swift, but doesn't think it will ever strive outside Apple's ecosystem, as it was it Objective-C as well.

Additionally Dave Abrahms would like to have another go at designing Swift.

Wait a second, isn’t Mojo supposed to be the Swift but better language- there’s another one already?

https://news.ycombinator.com/item?id=36281245

Surprise it turns out various Swift designers have different points of view.

What's unfamiliar about Val? It looks very similar to most languages released in the past 10 years with minor changes.

Clearly, this is why Rust has been unsuccessful. /s

But seriously, if you aren't doing something really different, why bother. If you find Popular Language X (PLX) too limiting, there's probably a dozen or two "it's just like PLX, but with a sprinkling of things from Y, which is pretty much like PLX, but sweeter sugar, and that makes it perfect". As others have pointed out, syntax is trivia[1].

[1] Unless, of course, you think a BEGIN..END language is nifty, and then you're a heretic and someone is coming with torches and pitchforks. :-)

P.S. - I'm not talking about PL/X, which is a thing, because of course it is. PL/I with some PL.8 and PL/S, and probably some PL/M. Nope...not joking.

I disagree with this a lot.

I think most programmers have been trained to think that C like syntax and semantics is fundamental to programming languages, as if languages are just inherently C like, and that C is just what programming is, but this is not true.

Programming language theory is an entire field of study on it's own, and there are a lot more possibilities than just rehashing C for the nth time.

Reply on news.ycombinator.com