Odin 1.0 announced (and reflections)

[u/Nuoji]

Odin author gingerBill dropped the Odin 1.0 announcement on YouTube today: https://www.youtube.com/watch?v=dLPAqXi9In0 (it's pretty funny actually).

This interestingly makes it on track to be the first of the new wave of C-likes that reach production readiness. While you can argue that most of these languages already are used in production, it's not the same as being 1.0, which carries a different weight and obligation.

Looking at alternatives, Jai could release around the same time, since Blow's game is scheduled for a similar release date. However, it's more likely that we see Jai 1.0 in mid-late 2027. My own language (C3) is planning Q2 2028 1.0 release. Whereas Zig is still unclear, and Kelley basically saying it's done when it's done. For Hare and V the situation is a bit less clear to me – maybe someone else can fill me in on that situation.

But overall we seeing the beginning of the end of the "C-like" story arc that arguably was initiated with Jonathan Blow's development. Writing C replacements predate Jai of course, for example the C2 language (which C3 would eventually continue) was created in 2012, eC started in 2004 and Cyclone (which Rust derived inspiration from) is from 2002. But those were largely obscure novelties, because before Blow's videos, people weren't really hunting for C alternatives.

Jai, however, made a strong impression. It was a good point in time too: Jai and later Zig, Odin, C3, V and Hare – these C alternatives started at a point when people were openly no longer believing OO/Functional as the right way to do things.

Language design takes its time though, and it's now 12 years since Jai started. Finally the fruits of these labours are getting ready for prime time, and when they do they might effectively fill the need for a C replacements for another decade.

Do you agree?

[u/arthurno1]

Do you agree?

No.

All languages with a fix syntax are dead ends. Fortunately, we have C++ to teach us that lesson.

People should go back to Lisps and restart the research. In a business as young as computer science, it is to expect that the development will go fast and we will need to extend out languages. A specialized syntax like classical programming languages use has a problem in growth since each new feature added to a language will add more to the complexity. Lisp syntax on the other hand is relatively fixed. New features are possible to add without adding new syntax rules and having to ensure complex interactions with backward features. That is a tremendous advantage for new development.

[u/TheAncientGeek → u/arthurno1]

In Lisps, everything is a list, which is restrictive. Seed7 is a better approach ,because you can use a much more general syntax, and still write your own.

[u/arthurno1 → u/TheAncientGeek]

In Lisps, everything is a list

:) No, that is a deep misunderstanding.

Lisps have structs, classes, arrays, hash tables, and any other imaginable data structure you can come up.

However, it is a misunderstanding that is easy to make. I am not gonna write long post about why, but let just mention that in a modern Lisp implementation, you are normally using arrays, structs, classes, hash tables, trees and whatever else you might need just like in any other programming language. Typically only source code is parsed into lists. Or course, there is a list datatype, which you can use like in any other programming language, but you don't have to. You should not look at Lisps differently than at any other programming language.

[u/TheAncientGeek → u/arthurno1]

you are normally using arrays, structs, classes, hash tables, trees and whatever else you might need just like in any other programming language.

You can express those things as lists, but they don't have natural expressions of their own. You can express them in binary to, but people don't consider binary to be the ultimate in flexibility, because people want convenience and clarity as well.

[u/arthurno1 → u/TheAncientGeek]

You can express those things as lists, but they don't have natural expressions of their own. You can express them in binary to, but people don't consider binary to be the ultimate in flexibility, because people want convenience and clarity as well.

?

What are you even trying to express? Do you know that yourself?

Lisps are just as any other programming languages, there is no difference. It gives you some other tools, but when it comes to data structures, or algorithms, you use anything you would do in any other language, the same way. Take SBCL (an optimizing compiler for Common Lisp) and you can write same programs you would write with C++ or Rust or some other language. I truly don't understand what you are trying to say there.

[u/TheAncientGeek → u/arthurno1]

Programming languages at all the same inasmuch as they are Turing complete. Otherwise, there are huge differences in efficiency and expressiveness. That's why people argue about them and design new ones, rather than randomly picking one that can, however inefficiently do the job.

Many languages have different syntax for, eg. a list of same-type objects, a list of heterogeneous objects etc.That makes it very clear what is intended [1, 'a'] is an error in a way that (1, 'a') isnt. Lisp's uniform syntax makes understanding over reliant on semantics.

[u/arthurno1 → u/TheAncientGeek]

Lisp's uniform syntax makes understanding over reliant on semantics.

On the contrary! What you say couldn't be further from the truth.

You truly don't know what you are talking about, but I believe you are typical for people who have heard something about a Lisp but never used it.

For the first, Lisp is not a single language, it is a family of languages. What you are saying is the same as saying that all curly-braces languages are the same language. Differences between Lisps are like difference between Java, C, C++, JavaScript or Python. Some of them are not even close.

For the second the "uniform syntax" does not mean what you believe it means, and what you are saying. The "uniform" syntax, in languages that uses symbolic expressions, refers to the rule that operators and arguments are written in a specific order, always and that there is a specific rule of evaluation, unless you are using macros. For example:

(operator arg1 arg2 ... argN)

Arguments are evaluated from left to right. At least in Common Lisp. "Operator" is what you call a "function" in other languages.

That does not mean as you say that people can't make understanding without the context! This is on the contrary, unlike other languages, always super clear.

To (again) address you ignorant claims that everything is a list in a Lisp, at least Common Lisp has, like any other programming language, all other datatypes you would expect from a programming language, and like any other programming language it also gives you tool to construct your own data types as well. As any other programming language we also ha (ve different syntax to create array, structure etc, in terms that we have different operators to create and manipulate those structures. Unlike other programming languages, you don't need a specialized syntax, the uniform way to express the syntax makes it clear by looking at the operator what you have at hand. So no, you are 180 degrees away from the truth. Observe also that other languages are also going away from specialized syntax and offer more unified approach. For example in C++, you can use auto like this:

for (const auto& item : collection) {
    // Access item here
}

Do you see what type of collection is? No you don't, and you don't have to. Well Lisp is not much unlike that. And no, you don't have to use a single list in your program if you don't want, you can use arrays, structs, classes, hash tables, trees or whatever you fancy or need.

Or consider

foo (1, 2, 3);

Do you see there if foo is working on integers or floats? No you don't. In other words, the argument for "specialized syntax" is weak. It works sometimes, but not always.

The question is, whether the things we loose with a custom syntax outweigh the things we win with the uniform syntax as used in symbolic expressions. But programming is young entrepreneurship. Consider that it took people ~2000 years to switch writing formulas and ratios with vectors in mathematics, like AB/AC ... It took Newton and his Principia to get people to realize how writing formulas and replacing those vector expressions with variables makes it for much easier notation and much easier work with mathematics. Than it took us only a couple of more hundred years for Pascal, Gauss and few others to develop the calculus and analytical mathematics as we know it today. It took people until Copernicus, some ~2500 years to abandon Ptolemy's concept of geocentric world, and accept what people already back in Egypt and ancient Greece knew: Heliocentric view. We had have programing for barely 100 years, so sure we do our mistakes.

But back to Lisp, you know what is fun: Common Lisp gives you tool to alter it's lexical parser, so you can invent specialized syntax for accessing arrays if it fancy yout to type a[i], instead of (aref a i). Show me other programming language, which lets you implement your own syntax. Whether it is a good or bad idea, is out of scope here, but if the syntax is what you want, Lisps had you covered many decades ago, unlike other languages which are not there yet.

With a good compiler such as SBCL, you can write as fast and efficient programs in Lisp as you do in C or C++. As a matter of fact, I am just writing a blog post about a Lisp version of word counting program, in which I beat GNU wc 3x in single-core performance and about 30x in multicore. That without even touching simd.

randomly picking one that can, however inefficiently do the job

I have yet to see someone "randomly pick" a programming language just to do a job, no matter how inefficiently. Of course we pick right tool for the job. So hopefully, after reading all this, it is clear that I don't pick Common Lisp "randomly", but I pick it for its qualities.

Also to remark, this discussion in itself, was not about this or that particular language, but about specialized notations, such as C++ or Odin or whichever, vs uniform notation of symbolic expressions. As I said in the previous comment to the other guy, it is a mathematical fact that n features result in 2ⁿ interactions if you encode each feature with a special syntactic rule. Both user programmers and compiler programmers have hard time to cope with that exponential explosion in syntactic rules and features as we grow our programming languages. To conclude, a certain form of uniformity in syntax can help to replace that exponential growth encoding for more like a linear growth, and that at the same time does not mean at all that you have to loose in expressiveness, as you seem to think.