Remarks on syntax

[mindplay-dk]

Hi folks,

Just drive-by looking over this language, as I've done with hundreds of languages over the years. 😁

I just found a few things a little surprising, and thought I'd comment on these briefly.

1. Why the semicolons? I did a quick regex search, and you do not have any occurrences of two statements on one line - so you probably don't need these as statement separators in practice. Line breaks would probably be fine as statement separators, and it would help the language look a little less noisy and more modern.

2. You truncated function to func - but you lengthened export to exported. Why not just function and export, same as most mainstream languages?

3. Why the "reverse" syntax/semantic here? x = "world!"; set x = "Antarctica!"; rather than let x = "world"; x = "Antarctica!", which is practically universal. (this looks particularly odd when assigning properties like set ship.name = "Raza")

4. Just a personal opinion, but a str = "world!" is less readable to me than a: str = "world!" - it's harder to scan code when nothing visually separates names from types. (I'm not used to reading C or C++, and half the developer world knows TypeScript by now.)

5. Closures like (x int) => { x + 2 } have two minor problems: most people are going to assume (x int) => x + 2 would work for single-expression closures, as it does in most mainstream languages - and since regular functions use a return statement, closures with a {} delimited body probably should include a return statement for consistency. (and easier scanning.)

6. "Shortcalling" constructors and interfaces: looks like array expressions but turns into objects based on context? Might save some typing, at the expense of making the code less consistent and harder to scan. Imagine trying to read this in a conversation, without highlighting. Probably has real problems like complicating IDE support as well - nothing to CTRL-click on, nothing to highlight to help you scan.

Unfortunately, developers are busy people - onboarding a new language needs to be fast and intuitive for the majority of mainstream programmers who work in conventional mainstream languages.

Don't get me wrong - I realize these are just one guy's opinions! I wouldn't bother commenting on syntax if it wasn't for all the exciting features you have, or have planned. There's plenty of things I already love about this language, just from glossing over the docs. This has real potential!

But you could do a bit more to make this look more familiar and appealing on the surface. There's a gazillion languages out there, and (sadly) most devs will drive by in a rush unless it looks like something they already know.

Cheers and good luck with your language! Really liking many of your ideas here. Can't say that for most languages these days. 😄

[ntrel]

1. Maybe because redundancy is good for error detection and error message quality and probably leaves more space for syntax enhancements available. Other modern languages use semicolons.
2. Please keep func (or even fn). Functions are very common. Maybe exported was chosen so attributes are all adjectives?
3. See https://verdagon.dev/blog/on-removing-let-let-mut. Though requiring mut at the declaration could be good in addition to set statements.
4. (Semicolons also make reading multi line statements easier). A colon might be fine but I'd say you'd probably get used to it if not. Semantic differences are a lot more important for learners.
   I can't comment on the other points.

[mindplay-dk]

Redundancy does not help prevent errors - forgetting to add a semicolon can lead to syntax errors. If it leaves space for syntax enhancements, it's mostly the kind of enhancements that would enable you to cram more things onto a single line - which isn't really good practice. (as mentioned, the Vale codebase itself doesn't do that).

Truncating keywords has been treated with some controversial humor of late - the question is why would you need to? You're used to seeing the word "function" written in full everywhere except source code in certain specific languages. Most people have an easier time parsing proper words vs abbreviations. I'm not going to claim it's difficult to figure out the meaning of "fun" or "func" in the context of source code, but the question remains why? Needing to type less is not a strong point, because IDEs.

It might seem silly for me to carry on about something seemingly trivial, but proper words (as a broad principle, in syntax and in source code) reduces information density - when you pack more information into a smaller space, your eyes need to slow down to parse and unpack the information. It's the same basic principle as zipping a text file - unpacking adds some overhead, however minimal.

u cn tll wht im wrtng here bt im not hlpng u rd this fstr

If there were reasons to condense keywords (disk space, parser speed) they are hardly relevant today. 🙂

[ntrel]

Forgetting to put a semicolon is fairly easy to diagnose and easy to get in the habit of noticing. You don't seem familiar with ambiguous parsing problems without semicolons. Those are much easier to avoid when there are semicolons.
https://digitalmars.com/articles/b05.html

Tooling is very important to a new language. semicolon justification is nothing to do with the number of tokens on a line.

[ntrel]

Long keywords push the rest of the line over too much. Consider reading on a phone or a diff, horizontal space is sometimes limited.
I've not heard of anyone having a problem instantly recognising the fn keyword, let alone func.

[mindplay-dk]

Forgetting to put a semicolon is fairly easy to diagnose and easy to get in the habit of noticing.

Sure, it's easy to justify, if you're trying.

My angle with new languages is more along the lines of what does the user want. Do they want semicolons everywhere?

Probably not. What for. They don't really solve any problem for the end user.

You don't seem familiar with ambiguous parsing problems without semicolons. Those are much easier to avoid when there are semicolons.

I'm no expert, but Skew has one of the smallest, simplest, most readable parsers I've seen:

https://github.com/evanw/skew/tree/master/src/frontend

Pratt parsers seem to handle this nicely - they're extremely simple and are also used in V and eslint among others.

Not going to claim it would be an "easy fix" to incorporate this in an existing parser! not by any means.

But the idea that it's necessarily more complex doesn't seem that convincing to me.

Long keywords push the rest of the line over too much. Consider reading on a phone or a diff, horizontal space is sometimes limited.

If your target audience all code on their cell phones, that seems important.

I've not heard of anyone having a problem instantly recognizing the fn keyword, let alone func.

Yeah, any programmer with a bit of experience will be able to guess what those mean.

Just trying to be inclusive, approaching this from the perspective of someone learning to program - since abbreviations are generally considered bad practice, why add to the learning curve by making it seem acceptable from first glance at the language.

Anyways, I understand anyone's perspective is as good as anybody else's when it comes to programming languages. Just explaining my position. In a language, I basically don't want to do anything that's surprising unless it's necessary for real and practical reasons - by which I mean, reasons that matter to the end user. You don't have to agree with me. If your target group is C/C++ developers, my reasons aren't going to mean anything in the context of Vale. 😊

[mindplay-dk]

I was playing around with GPT-4 system prompts, and decided to see what it thinks. 😄

I gave it the following system prompt:

You are a programming language expert.

You value:

* Simplicity
* Human-readable code
* Clean, terse and unambiguous syntax
* Familiarity with modern mainstream languages

You offer clear-cut opinions on programming language syntax and semantics based on your personal values.

And then I asked:

do modern languages benefit from having semicolons as statement separators?

To which it replied:

The use of semicolons as statement separators in modern programming languages can be seen as both beneficial and unnecessary, depending on the language design and goals. Here are some points to consider:

1. Benefits:

   • Explicit separation: Semicolons provide a clear and unambiguous separation between statements, making it easier for both the compiler and the programmer to understand the code. This reduces the likelihood of syntax errors and misinterpretations.
   • Flexibility: Semicolons allow for multiple statements to be written on the same line, which can be useful for short statements or one-liners.
   • Familiarity: Many popular programming languages, like C, C++, Java, and JavaScript, use semicolons as statement separators. Programmers familiar with these languages may find it easier to adapt to a new language that uses semicolons.

2. Drawbacks:

   • Verbosity: Semicolons can be seen as unnecessary characters in the code, making it less concise and less readable, especially if the language can infer statement separation through other means like line breaks.
   • Errors: Forgetting a semicolon can lead to syntax errors, which can be frustrating for developers, especially those new to a language.

Some modern languages, like Python, Ruby, and Swift, have opted for using line breaks as statement separators instead of semicolons. This choice can lead to cleaner, more readable code, but may require extra care when dealing with multi-line statements or expressions.

In conclusion, whether or not modern languages benefit from having semicolons as statement separators depends on the design goals and target audience of the language. There is no one-size-fits-all answer, and different languages may make different choices based on their priorities and the preferences of their user community.

However, pay attention to how I phrased my question.

If instead I ask:

if you were to design a new programming language today, should it have semicolons as statement separators?

The answer to that is very different:

If I were to design a new programming language today, considering my values of simplicity, human-readable code, clean and terse syntax, and familiarity with modern mainstream languages, I would likely choose not to include semicolons as mandatory statement separators. Instead, I would rely on line breaks and indentation for statement separation, similar to languages like Python and Ruby.

Here are the reasons for this decision:

1. Simplicity and readability: Omitting semicolons reduces visual clutter and makes the code easier to read and understand. It also encourages developers to write simpler and more maintainable code.

2. Reduced verbosity: Relying on line breaks and indentation for statement separation reduces the number of characters needed to write code, making it more concise and easier to maintain.

3. Lower risk of syntax errors: Without mandatory semicolons, developers won't encounter syntax errors caused by forgetting to add semicolons at the end of statements.

4. Familiarity for a diverse audience: While some developers might be more familiar with languages that use semicolons, many others come from backgrounds with languages that do not rely on semicolons, such as Python, Ruby, or Haskell. By omitting semicolons, the language can cater to a broader audience and provide a more inclusive experience for developers from various programming backgrounds.

However, I would also consider the following:

1. Flexibility: Depending on the language's design goals and target audience, it might be beneficial to make semicolons optional, similar to JavaScript. This approach could provide flexibility for developers who prefer explicit statement separation while still maintaining simplicity and readability for those who prefer not to use semicolons.

In conclusion, if I were to design a new programming language today, I would likely choose not to include semicolons as mandatory statement separators, focusing on simplicity, readability, and catering to a diverse audience. However, depending on the language's goals and target audience, providing optional semicolon usage could be considered as a way to offer flexibility and accommodate different developer preferences.

As for the flexibility caveat, I decided to challenge it a bit further on that point:

while optional semicolons would make the syntax more flexible, is flexibility a good thing here? or should we favor simplicity and consistency?

To which it replied:

You raise an important point. While flexibility can be beneficial in some cases, it may not always be the best choice, especially when it comes to language syntax. In the context of semicolons as statement separators, favoring simplicity and consistency might be a better approach. Here's why:

1. Readability and maintainability: Consistent syntax rules make it easier for developers to read and understand the code written by others. When a language has a single, consistent way of separating statements, it reduces the cognitive load required to comprehend the code, leading to better maintainability.

2. Reduced ambiguity: With a single, consistent way of separating statements, there is less room for ambiguity or misunderstandings in the code. This can help prevent potential bugs or issues caused by different interpretations of the code.

3. Easier learning curve: A simple and consistent syntax is easier for newcomers to learn and adopt. When there is only one way to separate statements, it removes the need for developers to decide which approach to use and helps them focus on learning other aspects of the language.

4. Code style consistency: When a language enforces a consistent syntax, it promotes a uniform coding style across projects and teams, making it easier to collaborate and share code.

Given these reasons, it might be better to favor simplicity and consistency in a programming language's syntax rather than making semicolons optional. By choosing a single, consistent way of separating statements, either by using line breaks and indentation or by using semicolons, a language can provide a more straightforward and unified experience for developers. In the context of my values and the modern programming landscape, I would lean towards using line breaks and indentation for statement separation, as it promotes simplicity, readability, and maintainability.

Now, GPT is generally very helpful and sometimes seems a little too agreeable - but it's also fairly rational and objective. And it has heard all the arguments, both for and against, so it's pretty interesting to see it hash things out.

(Why am I doing this, well, actually I've just been having fun, seeing if I could turn GPT into a language designer. I've had it write out EBNF syntax and a bunch of other fun things as well. I don't personally have the time to build my own language, but I'm curious how far we are from being able to simply prompt our way to having an LLM design and build a compiler for a working language, so that's why. 😊)

[BenjaBobs]

I think semicolons are a small price to pay for simplifying parsers, such as the compiler or a prettyfier of some sort.

But then again, I come from a mainly c# background so my mind reads the ; as a statement separator and it feels out of place to me when it's not there. 😄

[ntrel]

This AI has not worked on maintaining and extending a programming language with human users, so I don't think this is particularly helpful.

[Verdagon]

Howdy! Thanks for all this input, and I'm glad I finally have some time to chime in. The thread's a bit long and my time is a bit short today, so I'll only respond to the original for now.

Onboarding a new language needs to be fast and intuitive for the majority of mainstream programmers who work in conventional mainstream languages.

It's a balance between making a carbon-copy of an existing language's syntax, and making something that's better calibrated for the new language's use cases. Optimizing for one extreme over the other is usually a mistake.

That said, onto the suggestions!

1. The safe default for a new language is always to require semicolons, because we always have the option to easily take them out later (compared to adding them back in via a semi-breaking epoch change). There's no final decision on whether we'll have semicolons, that will come pre-1.0. The usual pros/cons apply: semicolons are annoying, they make for better error messages, etc.

2. exported is hopefully very temporary. I'd like to change that to export soon. Currently export is being used to make things public to anything across the FFI boundary, like C.

3. Check out https://verdagon.dev/blog/on-removing-let-let-mut, it's a bit better IMO to have set than let. Jury's still out on whether to require something like mut (likely !)

4. It's pretty subjective, some people consider that : to be useless noise. I tend to agree, though it's a vague topic. I remember a study on students learning (typed) Python showing that : made it a bit easier to learn... however, I'm not sure we want to optimize for users that have only been coding for an hour. An initial guess, we should probably optimize for someone who has experience in another statically typed language and has been using Vale for 5-20ish hours. Dunno! Open to other philosophies here.

5. (x int) => x + 2 actually works today, braces are optional for 1-expression lambdas.

6. Shortcalling syntax is super up in the air, especially since it's still in the "planned features" category. I'm kind of considering using curly braces for this, or perhaps an underscore like foo(_("Raza", 2)).

Hope that helps, and happy to answer more questions from here. Cheers!

[mindplay-dk]

Shortcalling could be good for when the type is redundant

I don't think fewer characters or less information is automatically good. Imagine a complex, domain-specific type with two or three type arguments and all the arguments are just underscores, values and parens. You might save a minute typing, but I don't think it's going to be easier to read.

I also wonder how code with underscores would affect the refactoring experience, your ability to read a diff or pull request, and so on.

[mindplay-dk]

Also, developers will no doubt do some unproductive bikeshedding over the right time to use this feature, or whether to use it at all.

We're doing that already. 😉

[BenjaBobs]

my_map =
  Map<int, Vec3>(
    _(5, _(353, 466, 500)),
    _(10, _(45, 231, 654)),
    _(12, _(876, 534, 533)));

It does open up for the possibility of hiding the type information behind a function:

my_map =
  CreateMap(
    _(5, _(353, 466, 500)),
    _(10, _(45, 231, 654)),
    _(12, _(876, 534, 533)));

The compiler will know which types to work with here, but I as reviewer have to know the definition of CreateMap to understand what type I'll be handed.

This is usually no problem when writing, as sufficiently smart IDEs will allow me to mouse-over to find out the type, or maybe even display inline type hints.

When reviewing code online, however, this becomes much more difficult.

In an ideal world, I would like to be able to write _(5, _(353, 466, 500)), and then when I do ctrl + s it would be automatically replaced by Entry(5, Vec3(353, 466, 500)).
That way I as a developer will get the ease of writing with shortcalling, but cognitive burden of reading my code would be smaller, allowing for easier reviewing.

Of course this is mostly a question of tooling / ecosystem around the language.

EDIT: And probably something that is better left as a choice for the repository owner, and a configuration in an .editorconfig

[mindplay-dk]

In an ideal world, I would like to be able to write _(5, _(353, 466, 500)), and then when I do ctrl + s it would be automatically replaced by Entry(5, Vec3(353, 466, 500)).

Essentially auto-completion, then.

Not 100% sure if this jives with the rest of the language, but you could even potentially have an IDE automatically fill in the types in constructor calls, as soon as you type the opening parens inside an expression:

mymap = CreateMap(
                  ^ cursor position

mymap = CreateMap((
                  ^ opening paren

mymap = CreateMap(Entry(
                  ^      ^ cursor position
                  auto completed

But yeah, typing fast should be a tooling concern - readable code is a language concern.

For that matter, if someone is more comfortable seeing a bunch of underscores instead of constructor names, that's something an IDE could just do. No pressing reason to burden the language with this, I think.

[Verdagon]

That's a great insight and idea, that IDEs could do this for us.

Another use case for shortcalling would be to make it so Some and None are a little less verbose. Some and None often make things a bit verbose in Scala.

In the end, this will likely come down to where we want to be on the spectrum of more verbose/explicit vs shorter/implicit. Vale tends toward the former, so this feature does seem a bit inconsistent.

You all have given me much to think about! I'll leave this discussion open (shortcalling certainly wont happen for a while), and I think I'll link to it from the guide as well, in case others want to weigh in.

[RednibCoding]

Hi, I completely agree with point 6 regarding "Shortcalling". It's too easy to confuse it with other constructs, whether it resembles an array due to its syntax or looks like an anonymous struct when curly braces are used, and so on. For a language to be readable, there should be only one way to express a particular concept. Multiple representations can obfuscate the meaning and make the code harder to understand. We have IDEs nowadays that assist with typing, and we're no longer restricted by a certain number of characters per line. Don't sacrifice readability just to save a few keystrokes.
What frustrates me the most is reading language documentation that says things like: 'To create x/y, you can write it this way, or you can also use this alternative, and in certain situations, you can express it with yet another method.' For me, personally, such a language has already fallen short. Just because other languages adopt certain practices doesn't mean yours should as well. Also, it's crucial not to implement features merely for the sake of expanding the feature list. It's essential to keep the language small and concise. Many modern and new languages fail at this.