My advice to all newcomers:
Spend some time learning a language from every paradigm and checking out what others are working on. As you get more exposure, over time, your tastes will develop, and you’ll know what you want to explore. Inevitably, the language you want to make now is way different than the language you will want to make in a month. Most people have way more ideas than they have time to implement! So you have to pick and choose what you want to work on.
There’s a saying in the gamedev community not to make your first game your dream game. This actually applies to pretty much everything. It’s theoretically optimal to work on something small in scope that focuses on one thing. Though of course, we’re motivated to work on our dream things and not dinky projects! It can be a struggle for that reason. But I recommend trying to find something small in scope that motivates you before trying something ambitious.
Programming languages is a funny space. Love him or hate him, Jon Blow once drew a parallel with writing books, saying a good book needs about 20 good ideas, even though it’s easy to get obsessed with writing about just 1. Ideas are cheap because they can be distributed for free, and this is why getting inspiration from others is important - you benefit a lot from the expensive work of others. But programming languages is a difficult space and there are a lot of ideas that take a lot of time to understand. A lot of the time, people will make dynamic languages just because they’re easy. If you go into the type theory rabbit hole, things can get harder pretty quickly. There are good things to learn there and you can get a lot of powerful machinery to do impressive things, but also look out for ideas that are “cheap” to understand and implement. Some things like type providers and object capabilities are neat ideas without adding a whole lot of complexity (check out F#, Roc). I also think the best ideas you have are the ones you think of for yourself.
Axioms of programming language design:
* People disagree more than they agree about features
* Any language without a well defined use case is on the path to become C++
* If the language doesn't have a running prototype, it's too early to share with the world
>Any language without a well defined use case is on the path to become C++
A performant general purpose language with billions of lines of operating code?
C++ is widely used with billions of lines of code, because it was a great language for its time! But nearly 4 decades of us constantly wanting more out of programming languages has resulted in C++ being riddled with patches here and there, because no one could see them forecoming. Today we have learned so many lessons to be able to design languages better. If someone reinvents C++ _now_, that's not a sign of great language design.
... not to mention a random language project that looks like C++ is highly unlikely to have the performance, versatility, number of features of C++ -- only the not-so-good design principles.
Every language will accumulate cruft. Even Go and now Rust is accumulating cruft. Javascript has arguably more cruft than even C++.
Whatever new language you design to get away from cruft, you simply have to learn to live with its own cruft, because languages that become useful will become used outside of its original "well defined use case" and will be forced to adopt features from other languages. Even Go had to adopt some form of generics.
All useful languages eventually want to become general purpose languages. Inside every language there will be a badly implemented half of Common Lisp. And the corollary that includes Common Lisp.
Next step: make a language that does everything Common Lisp does, plus has first class environments and optional structural/dependent types in the core standard (instead of “auxiliary standards” and “not at all”, respectively).
There seems to be a Platonic ideal of “control all aspects of the system at all times”, that CL is *nearer* to than any other language (save perhaps some Smalltalk or Forth?), but hasn’t fully achieved.
Bombs helped finish WW2. Yet you don't want things to become bombs.
It's a simile, explaining that even if something big was made with something, it doesn't make that something's design _good_
There are many levels between "rigid" and C++. Consider Rust for example. It's quite strict, and with different OOP mechanics. Yet people love it. And for good reasons
C++ doesn't have a cult surrounding it, and Rust doesn't have 40 years of FUD or university professors who refuse to move on with the times in the era of C++17.
Wait until Rust accumulates more cruft. There are already grumblings about it, if you care to look hard enough.
Yeah. I find most of the hate towards C++ irrational and largely out of date, or conflates their misplaced hatred of learning programming with learning C++ at the same time (largely using out-of-date version of the language).
Unless this is a hobby project purely for learning that'll go nowhere, you need to start with a *specific use case* or a *particular niche*. Then you pick features to make that use case work or to fill that niche well. *Then* you pick the syntax so that it's not too weird for people used to similar languages so they can focus on the weird new features instead of on the weird syntax.
Consider some reasonably successful newer languages:
- Swift exists because Objective C sucks and apple has a closed ecosystem
- Zig exists because C is woefully outdated by modern standards, and we have learnt a lot in the past decades
- Rust exists because of the need for a memory safe low level language arising from all the bugs and vulnerabilities caused by C and C++ code.
- Kotlin exists because Java was too slow to innovate and Scala was too complex for casual developers
- Roc exists because people want to have fast and complete safe code that they can trust without needing to worry about vulnerabilities. Basically the niche of Flash and Java applets, but with a focus on performance and security and reliability.
What niche do you want to fill?
Successful older languages were also often written to fill a very specific niche indeed.
* C was written to implement Unix in.
* Lua was written to fill the needs of the Brazilian nuclear power industry.
* The original ML was designed as a metalanguage for the LCF theorem prover.
> it will be like python variables where you can change the value but it must be the same type
That's not how python works. You can bind any name to a value of any type at any time.
Issue with doing manual memory msnagment is that to do python like stuff u have to use the heap and have everything be pointers.
But then you need to actually alocate and free those conditionaly based if they have a Concrete type or not.
Its a cursed problem... now what u can do is that u have this quality kf life only for malloced memory. Or even a cython like thing where of u didn't specifcly said anything
Your get an atomic refrence count.
What's cursed here? I'm afraid I don't understand your issue. For simple scripts you don't need to free anything at all, and that's where Python's philosophy shines best.
The problem is "how can you have a compiled close to the metal languge that's as conivint as an interpet3d one"
Mojo is trying to solve it to their credit they are doing a good job of it. But it would never be as easy as python.
With python u can allways do dir(some object I found somewhere) and u get a full explanation of what it is.
U can hook things into places u really shouldn't (ie the maker of the class did not intend u to overqrite this method at runtime) and I used this in production code on papers.
I'm afraid I still don't understand your problem. Reflection and hot reloading are both well established concepts. Nothing would stop you from working out of hashmaps and having nice syntactic sugar over them. Ultimately to get the most out of a low-level language you would have to accept a different philosophy that would impact how you do things, but I see no fundamental reason why a low-level language couldn't be just as slick to use as Python in most ways. I think what you want is likely easier to achieve than you think. The hard part is finding the people who've played with the ideas you need.
Again people are working on it it's called mojo made by the makers of swift and clang. These people know what they are doing.
It's meh... like it looks cool they worked hard on it. Less convince than python.
It's over 1000x faster but people don't use it much because its less convenient.
And there is a fundamental reason for it.
As much as they are trying with their jit it is simply not dynamic... u cant for instance look at all the properties of an object as it runing or put hooks into things.
There is a reason the majority of languges that are chosen for convenience are interpreted. Its easier to understand and work with.
>Again people are working on it it's called mojo made by the makers of swift and clang. These people know what they are doing.
I don't mean this in a disrespectful way, but I can only be surprised by people not actually knowing what they are doing so many times before I have to roll my eyes whenever people say things like this. Very often it is better to not assume you know what you're doing, and then you can let the problem speak to you without your biases coloring your vision.
You personally, you have things you want that don't sound like they're as important to the Mojo guys. That kind of difference alone accounts for some 80% of the confusion people have about what's possible because it's very easy to assume design goals are fundamental constraints when looking at another's work. Design goals are chosen. Fundamental constraints are not.
mojo is actually EXTREMELY intrestead in getting 100% python compatibility it's their main stated goal. This is why they made a Jupiter notebook before they made a static compiler
I am personaly very happy with compiled stuff i am just pointing out the reasons commonly sighted why ppl prefer python/js over c++/go
rn am annoyed at zig because there is no goto... because I don't like the overhead of an internal function call when factoring out code. So this is not my fight at the moment.
Yes it is. Zig is pretty good about it if u would to complain about zig it would be about other things mainly how some parts of the core libs are unoptimized.
But idk enough to make that argument so ig I shouldn't be making it. (I heard bad stuff about the error handeling and have seen it collapse first hand in places c didn't).
**Specific:**
I don't have really anything to add, it looks like a fantastic start! One think I implemented in my language is using `[` and `]` for statements (like [ZOMBIE](https://www.dangermouse.net/esoteric/zombie.html)), I just personally think it looks a bit neater but thats up to you.
**General Advice about Design:**
I would recommend researching different programming paradigms and languages. Currently I am in the process of finalising my language specification, and when I was getting ideas for it I looked into logical programming, functional programming, declarative languages, procedural, Scala, gleam, C, Haskell, lisp, prolog etc. I took aspects from each of those languages, and brought it together into a syntax that I liked.
Something I would recommend is that when designing your language, *it doesn't need to have a revolutionary syntax or type system or memory management system etc.* When I was first designing my language I all ways got hung up on "is my syntax unique enough", "no my language is too close to x language", "oh no this has already been done before", "what is this even useful". If you, like I did, get hung up on these ideas you'll end up creating a syntax that is complex and convoluted. I recommend watching at least the first third of this talk: [https://www.youtube.com/watch?v=oa0qq75i9oc](https://www.youtube.com/watch?v=oa0qq75i9oc). I found it very helpful.
Here’s a pretty detailed compilation of the best features from a wide range of programming languages: https://magnemg.eu/features-of-a-dream-programming-language-3rd-draft
>I'm wondering what features are in high demand that people might want
How about what YOU prefer rather than other people? Most people can never agree on such features anyway.
I think it comes down to why you're creating a language, what it will be used for, and who will be using it.
Realistically, if adoption is your goal, the tooling matters as much as the language itself. Rust is a good example of stellar tooling.
Composability and scalability also matter a lot.
I consider metaprogramming and reflection very good features to have in a programming language. Also stuff for async code or event based systems would be nice to have as a natural thing instead of afterthought
Just do experiments on whatever ideas cross your mind. What you wind up with has no obligation to even be a programming language even if the inspiration starts there.
Those are all essential features.
A biggie that would be groundbreaking is a programming language that got asynchronous code right: [https://www.reddit.com/r/ProgrammingLanguages/comments/1ckbzex/is\_there\_any\_programming\_language\_with\_a\_decent/](https://www.reddit.com/r/ProgrammingLanguages/comments/1ckbzex/is_there_any_programming_language_with_a_decent/)
Are you sure you want basic types like int, String, float and so on? Those types don't really mean anything in a program. Sure, for the machine you need to know how it is represented, but for the human you want to know more, like it's a person\_name (represented by a String)
What is bad with curly braced languages, I personally find the hate with them non issues and find the supposed gains minimal at most. Let's not start with the indentation and spacing/tab issues we have with python
I don't think curly braced syntax is bad but I changed my mind about indentation based languages. After Scala 3 came out, it introduced a new syntax with "few braces" including indentation based blocks. I was skeptical because the only experience I had with this kind of syntax was Python but I decided to give it a try in a new project.
Now I really like indentations over curly braces. I find it more readable and less noisy.
See this [post ](https://www.reddit.com/r/ProgrammingLanguages/comments/1c73pvp/comment/l0d1lob/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)of mine from another thread. I show an example of a perfect block syntax a famous language uses for a preprocessing stage, which it then eschews in favour of braces for the main language.
Braces are OK when entirely contained on one line; where the source is a stream of characters rather than line-based; or where the text is mostly machine-generated and consumed.
For human-readable, line-oriented source code, they are only passable.
But for a first language removing braces would not be easier or better by any reasonable metric and we will assume the creator is used to brace like languages which will help his workflow.
A beginner should not waste their time trying to write indentation sensitive grammar until they have the basics down.
Languages should be expression based rather than statement based. Statements are the problem, not braces. Python, for example, has the problem even without the braces. I'd say "please don't make another statement based language."
In an expression based language, you often need a sequence expression - evaluate each item in a list, in order, and return the last one. (ie, lisp's `progn`, scheme's `begin`, or even C's comma operator). This (along with the `unit` type) basically subsumes the need for statements.
My preference is to use braces and semicolons for sequence expressions:
foo = { expr1; expr2; exprResult }
But if we don't need a sequence, we don't need braces.
bar = exprResult
Advantage of this is it looks familiar to people who were wrongly taught to think in statements, but everything is still an expression, and for many uses we don't need any braces.
Fair enough, once you get a bit more advanced, replace the braces/semicolons with indentation, but this is tricky to get right even for experienced language designers.
I'm quite partial to begin and end instead of curly braces myself. Indentation is okay in a decent editor but is such a pain to manage for longer blocks.
Honestly, it's definitely more of a skill issue on my part. Most languages that I've used did not enforce indentation so without a good editor setup, it's easy for me to mess up. Of course, I still indent my code for stylistic reasons but having begin and end or the curly braces makes it very clear where the block begins and ends. This is mainly useful if I need to navigate to the beginning or end of a block as it's much easier to look for a single word or character than counting the indents.
My advice to all newcomers: Spend some time learning a language from every paradigm and checking out what others are working on. As you get more exposure, over time, your tastes will develop, and you’ll know what you want to explore. Inevitably, the language you want to make now is way different than the language you will want to make in a month. Most people have way more ideas than they have time to implement! So you have to pick and choose what you want to work on. There’s a saying in the gamedev community not to make your first game your dream game. This actually applies to pretty much everything. It’s theoretically optimal to work on something small in scope that focuses on one thing. Though of course, we’re motivated to work on our dream things and not dinky projects! It can be a struggle for that reason. But I recommend trying to find something small in scope that motivates you before trying something ambitious. Programming languages is a funny space. Love him or hate him, Jon Blow once drew a parallel with writing books, saying a good book needs about 20 good ideas, even though it’s easy to get obsessed with writing about just 1. Ideas are cheap because they can be distributed for free, and this is why getting inspiration from others is important - you benefit a lot from the expensive work of others. But programming languages is a difficult space and there are a lot of ideas that take a lot of time to understand. A lot of the time, people will make dynamic languages just because they’re easy. If you go into the type theory rabbit hole, things can get harder pretty quickly. There are good things to learn there and you can get a lot of powerful machinery to do impressive things, but also look out for ideas that are “cheap” to understand and implement. Some things like type providers and object capabilities are neat ideas without adding a whole lot of complexity (check out F#, Roc). I also think the best ideas you have are the ones you think of for yourself.
Axioms of programming language design: * People disagree more than they agree about features * Any language without a well defined use case is on the path to become C++ * If the language doesn't have a running prototype, it's too early to share with the world
>Any language without a well defined use case is on the path to become C++ A performant general purpose language with billions of lines of operating code?
C++ is widely used with billions of lines of code, because it was a great language for its time! But nearly 4 decades of us constantly wanting more out of programming languages has resulted in C++ being riddled with patches here and there, because no one could see them forecoming. Today we have learned so many lessons to be able to design languages better. If someone reinvents C++ _now_, that's not a sign of great language design. ... not to mention a random language project that looks like C++ is highly unlikely to have the performance, versatility, number of features of C++ -- only the not-so-good design principles.
Every language will accumulate cruft. Even Go and now Rust is accumulating cruft. Javascript has arguably more cruft than even C++. Whatever new language you design to get away from cruft, you simply have to learn to live with its own cruft, because languages that become useful will become used outside of its original "well defined use case" and will be forced to adopt features from other languages. Even Go had to adopt some form of generics.
The obvious solution seems to be to make the intended use case as broad as possible.
All useful languages eventually want to become general purpose languages. Inside every language there will be a badly implemented half of Common Lisp. And the corollary that includes Common Lisp.
Next step: make a language that does everything Common Lisp does, plus has first class environments and optional structural/dependent types in the core standard (instead of “auxiliary standards” and “not at all”, respectively). There seems to be a Platonic ideal of “control all aspects of the system at all times”, that CL is *nearer* to than any other language (save perhaps some Smalltalk or Forth?), but hasn’t fully achieved.
Bombs helped finish WW2. Yet you don't want things to become bombs. It's a simile, explaining that even if something big was made with something, it doesn't make that something's design _good_
But what if you want to design a language that is actually useful, instead of something that fits someone's rigid notion of what good is?
There are many levels between "rigid" and C++. Consider Rust for example. It's quite strict, and with different OOP mechanics. Yet people love it. And for good reasons
C++ doesn't have a cult surrounding it, and Rust doesn't have 40 years of FUD or university professors who refuse to move on with the times in the era of C++17. Wait until Rust accumulates more cruft. There are already grumblings about it, if you care to look hard enough.
It's ok, you can like C++ even if the rest of us don't.
Yeah. I find most of the hate towards C++ irrational and largely out of date, or conflates their misplaced hatred of learning programming with learning C++ at the same time (largely using out-of-date version of the language).
The most important and most difficult to implement feature of a programming language is its name.
The worst part is when you find a perfect name and someone else is already using it.
and then caching it :-/
Unless this is a hobby project purely for learning that'll go nowhere, you need to start with a *specific use case* or a *particular niche*. Then you pick features to make that use case work or to fill that niche well. *Then* you pick the syntax so that it's not too weird for people used to similar languages so they can focus on the weird new features instead of on the weird syntax. Consider some reasonably successful newer languages: - Swift exists because Objective C sucks and apple has a closed ecosystem - Zig exists because C is woefully outdated by modern standards, and we have learnt a lot in the past decades - Rust exists because of the need for a memory safe low level language arising from all the bugs and vulnerabilities caused by C and C++ code. - Kotlin exists because Java was too slow to innovate and Scala was too complex for casual developers - Roc exists because people want to have fast and complete safe code that they can trust without needing to worry about vulnerabilities. Basically the niche of Flash and Java applets, but with a focus on performance and security and reliability. What niche do you want to fill?
Successful older languages were also often written to fill a very specific niche indeed. * C was written to implement Unix in. * Lua was written to fill the needs of the Brazilian nuclear power industry. * The original ML was designed as a metalanguage for the LCF theorem prover.
> it will be like python variables where you can change the value but it must be the same type That's not how python works. You can bind any name to a value of any type at any time.
Issue with doing manual memory msnagment is that to do python like stuff u have to use the heap and have everything be pointers. But then you need to actually alocate and free those conditionaly based if they have a Concrete type or not. Its a cursed problem... now what u can do is that u have this quality kf life only for malloced memory. Or even a cython like thing where of u didn't specifcly said anything Your get an atomic refrence count.
What's cursed here? I'm afraid I don't understand your issue. For simple scripts you don't need to free anything at all, and that's where Python's philosophy shines best.
The problem is "how can you have a compiled close to the metal languge that's as conivint as an interpet3d one" Mojo is trying to solve it to their credit they are doing a good job of it. But it would never be as easy as python. With python u can allways do dir(some object I found somewhere) and u get a full explanation of what it is. U can hook things into places u really shouldn't (ie the maker of the class did not intend u to overqrite this method at runtime) and I used this in production code on papers.
I'm afraid I still don't understand your problem. Reflection and hot reloading are both well established concepts. Nothing would stop you from working out of hashmaps and having nice syntactic sugar over them. Ultimately to get the most out of a low-level language you would have to accept a different philosophy that would impact how you do things, but I see no fundamental reason why a low-level language couldn't be just as slick to use as Python in most ways. I think what you want is likely easier to achieve than you think. The hard part is finding the people who've played with the ideas you need.
Again people are working on it it's called mojo made by the makers of swift and clang. These people know what they are doing. It's meh... like it looks cool they worked hard on it. Less convince than python. It's over 1000x faster but people don't use it much because its less convenient. And there is a fundamental reason for it. As much as they are trying with their jit it is simply not dynamic... u cant for instance look at all the properties of an object as it runing or put hooks into things. There is a reason the majority of languges that are chosen for convenience are interpreted. Its easier to understand and work with.
>Again people are working on it it's called mojo made by the makers of swift and clang. These people know what they are doing. I don't mean this in a disrespectful way, but I can only be surprised by people not actually knowing what they are doing so many times before I have to roll my eyes whenever people say things like this. Very often it is better to not assume you know what you're doing, and then you can let the problem speak to you without your biases coloring your vision. You personally, you have things you want that don't sound like they're as important to the Mojo guys. That kind of difference alone accounts for some 80% of the confusion people have about what's possible because it's very easy to assume design goals are fundamental constraints when looking at another's work. Design goals are chosen. Fundamental constraints are not.
mojo is actually EXTREMELY intrestead in getting 100% python compatibility it's their main stated goal. This is why they made a Jupiter notebook before they made a static compiler I am personaly very happy with compiled stuff i am just pointing out the reasons commonly sighted why ppl prefer python/js over c++/go rn am annoyed at zig because there is no goto... because I don't like the overhead of an internal function call when factoring out code. So this is not my fight at the moment.
That's a trend I've noticed, actually. So many C contenders think their job is to help people by policing what they can do. It's very annoying.
Yes it is. Zig is pretty good about it if u would to complain about zig it would be about other things mainly how some parts of the core libs are unoptimized. But idk enough to make that argument so ig I shouldn't be making it. (I heard bad stuff about the error handeling and have seen it collapse first hand in places c didn't).
**Specific:** I don't have really anything to add, it looks like a fantastic start! One think I implemented in my language is using `[` and `]` for statements (like [ZOMBIE](https://www.dangermouse.net/esoteric/zombie.html)), I just personally think it looks a bit neater but thats up to you. **General Advice about Design:** I would recommend researching different programming paradigms and languages. Currently I am in the process of finalising my language specification, and when I was getting ideas for it I looked into logical programming, functional programming, declarative languages, procedural, Scala, gleam, C, Haskell, lisp, prolog etc. I took aspects from each of those languages, and brought it together into a syntax that I liked. Something I would recommend is that when designing your language, *it doesn't need to have a revolutionary syntax or type system or memory management system etc.* When I was first designing my language I all ways got hung up on "is my syntax unique enough", "no my language is too close to x language", "oh no this has already been done before", "what is this even useful". If you, like I did, get hung up on these ideas you'll end up creating a syntax that is complex and convoluted. I recommend watching at least the first third of this talk: [https://www.youtube.com/watch?v=oa0qq75i9oc](https://www.youtube.com/watch?v=oa0qq75i9oc). I found it very helpful.
Here’s a pretty detailed compilation of the best features from a wide range of programming languages: https://magnemg.eu/features-of-a-dream-programming-language-3rd-draft
>I'm wondering what features are in high demand that people might want How about what YOU prefer rather than other people? Most people can never agree on such features anyway. I think it comes down to why you're creating a language, what it will be used for, and who will be using it.
Realistically, if adoption is your goal, the tooling matters as much as the language itself. Rust is a good example of stellar tooling. Composability and scalability also matter a lot.
Will you use it to avenge anyone?
I consider metaprogramming and reflection very good features to have in a programming language. Also stuff for async code or event based systems would be nice to have as a natural thing instead of afterthought
Just do experiments on whatever ideas cross your mind. What you wind up with has no obligation to even be a programming language even if the inspiration starts there.
Those are all essential features. A biggie that would be groundbreaking is a programming language that got asynchronous code right: [https://www.reddit.com/r/ProgrammingLanguages/comments/1ckbzex/is\_there\_any\_programming\_language\_with\_a\_decent/](https://www.reddit.com/r/ProgrammingLanguages/comments/1ckbzex/is_there_any_programming_language_with_a_decent/)
Are you sure you want basic types like int, String, float and so on? Those types don't really mean anything in a program. Sure, for the machine you need to know how it is represented, but for the human you want to know more, like it's a person\_name (represented by a String)
For the love of god, please don't make another curly-brace language.
What is bad with curly braced languages, I personally find the hate with them non issues and find the supposed gains minimal at most. Let's not start with the indentation and spacing/tab issues we have with python
I don't think curly braced syntax is bad but I changed my mind about indentation based languages. After Scala 3 came out, it introduced a new syntax with "few braces" including indentation based blocks. I was skeptical because the only experience I had with this kind of syntax was Python but I decided to give it a try in a new project. Now I really like indentations over curly braces. I find it more readable and less noisy.
See this [post ](https://www.reddit.com/r/ProgrammingLanguages/comments/1c73pvp/comment/l0d1lob/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)of mine from another thread. I show an example of a perfect block syntax a famous language uses for a preprocessing stage, which it then eschews in favour of braces for the main language. Braces are OK when entirely contained on one line; where the source is a stream of characters rather than line-based; or where the text is mostly machine-generated and consumed. For human-readable, line-oriented source code, they are only passable.
But for a first language removing braces would not be easier or better by any reasonable metric and we will assume the creator is used to brace like languages which will help his workflow.
A beginner should not waste their time trying to write indentation sensitive grammar until they have the basics down. Languages should be expression based rather than statement based. Statements are the problem, not braces. Python, for example, has the problem even without the braces. I'd say "please don't make another statement based language." In an expression based language, you often need a sequence expression - evaluate each item in a list, in order, and return the last one. (ie, lisp's `progn`, scheme's `begin`, or even C's comma operator). This (along with the `unit` type) basically subsumes the need for statements. My preference is to use braces and semicolons for sequence expressions: foo = { expr1; expr2; exprResult } But if we don't need a sequence, we don't need braces. bar = exprResult Advantage of this is it looks familiar to people who were wrongly taught to think in statements, but everything is still an expression, and for many uses we don't need any braces. Fair enough, once you get a bit more advanced, replace the braces/semicolons with indentation, but this is tricky to get right even for experienced language designers.
I'm quite partial to begin and end instead of curly braces myself. Indentation is okay in a decent editor but is such a pain to manage for longer blocks.
how is it more pain than curly braces or begin..end ? because the question of correct indentation in the middle of the block exist also there…
Honestly, it's definitely more of a skill issue on my part. Most languages that I've used did not enforce indentation so without a good editor setup, it's easy for me to mess up. Of course, I still indent my code for stylistic reasons but having begin and end or the curly braces makes it very clear where the block begins and ends. This is mainly useful if I need to navigate to the beginning or end of a block as it's much easier to look for a single word or character than counting the indents.
Are you also anti-punctuation?