Raphael_Amiard

I mean I’m only answering that because you’re asking, nothing set me off personally there, but now that you ask:

« The pull request alone adds over 197 thousand lines of code across 1,816 files. »

I noticed that both Claude and GPT are fond of those kind of stupid accounting statements that don’t mean a lot in and of themselves, but look impressive in a « wow numbers » way. Which is kind of ironic since counting remains one of their weak points

Average american is what you mean

It’s pattern matching. A big part of reasoning for sure, but not reasoning per se

"Is this true for the Ada lang/compiler"

Yes, Ada has a lot of the same kind of fractal complexity that C++ has, which derives from unforeseen interaction of some features with some other.

On top of that, as I said in another comment, features are extremely overspecified. The standard specifies what has to be done in every edge case, often with a specification that is not very practical to implement efficiently

You're right in your first part. Ada 83 is less complex than modern C++ or Rust. However Ada kept evolving, and a lot of complexity was added in later revisions, such as Ada 95, which added a kind of bastardized and very complex Java style object model layer.

Ada features that are hard to compile are very common in the language. It is generally a language that is hard to compile to efficient code, because rules were conceived in an abstract notion of what safety is. But in general Ada is an extremely over specified language, which leaves very little space to interpretation. You can check the Ada reference manual if you want, which is a use 1000 pages book (http://www.ada-auth.org/arm.html)

* Array types are very powerful and very complicated * Tasking & threading are specified in the language, which seems good on paper, but the abstractions are not very efficient and of tremendous complexity to implement. * Ada's generic model is very hard to compile efficiently. It was designed in a way that tried to make it possible to compile down both to a "shared implementation" approach, as well as down to a monomorphized approach. Mistakes were done down the line wrt the specification of generics which made compiling them to shared generics almost impossible, which is why some compiler vendors didn't support some features of the language at all. * Ada scoping & module system is of immense complexity * The type system is very vast. Ada's name & type resolution algorithm is extremely complex to implement. functions can be overloaded on both parameters & return types, and there is a enclosing context that determines which overloads will be used in the end. On top of that you have preferences rules for some functions & types, subtyping, derived types, etc ...

This is just what comes to mind on a late Friday evening :) I would say that the language is so complex that writing a new compiler is one of those herculean efforts that reach similar heights as writing a new C++ compiler. That's just a fe

> Today, the criticism about complexity seems naive, because many later languages have become much more complex than Ada

I don’t think you really understand what you’re saying here. I have worked on an ada compiler for the best part of a decade. It’s one of the most complex languages there is, up there with C++ and C#, and probably rust

There is none as far as affine types go, even is there is a parallel to be made with limited types, but they don’t serve the same purpose.

The way Ada generally solves the same problem is by allowing much more in terms of what you can give a stack lifetime to, return from a function, and pass by parameters to functions.

It also has the regular « smart pointer » mechanisms that C++ and Rust also have, also with relatively crappy ergonomics

The very obvious flaw with that argument is that flying is defined by, you know, moving in the air, whereas intelligence tends to be defined with the baseline of human intelligence. You can invent a new meaning, but it seems kind of dishonest

I love systems programming language and have worked on the Ada language for a long time. I find Zig to be incredibly underwhelming. Absolutely nothing about it is new or novel, the closest being comptime which is not actually new.

Also highly subjective but the syntax hurts my eyes.

So I’m kind of interested by an answer to the question this articles fails to answer. Why do you guys find Zig so cool ?

Came here to say that. It’s important to remember how biased hacker news is in that regard. I’m just out of ten years in the safety critical market, and I can assure you that our clients are still a long way from being able to use those. I myself work in low level/runtime/compilers, and the output from AIs is often too erratic to be useful

SPARK allows you to formally prove that your code is correct according to a given specification. It can thus provides much stronger guarantees than what Rust would be able to provide.

Similar technology exists for Rust, but it is much less advanced than SPARK is (https://github.com/xldenis/creusot)

This is about firmware, nothing to do with the performance of GPUs...

Not defending Russia in general, or in particular russian government. As a French person whose national medias are completely taken over by multinationals (source https://www.monde-diplomatique.fr/cartes/PPA), not only the ban was a bit laughable in terms of banning propaganda, but also RT France's perspective and journalism was refreshing. It was presenting a skewed version of the world, but if you believe as I do that we won't attain information via objectivity, which is a nebulous concept anyway, but via plurality, RT France's disappearance is a net loss for the French media landscape, and I'm a bit alarmed at the black&whiteness of views I see here and in other places.

> For verification in general, is the expense of verification in this case because of the model needed to verify Ada? For instance, perhaps a language that makes different choices might have a model checker that could scale better.

I don't think so. The SPARK subset has been chosen to aid verification. The problem of proof is inherently computationally hard, and the most gains you can expect will come from advances in solver technology, both algorithmic and in terms of scaling to multiple cores or GPU eventually.

Just my opinion :) But I work at AdaCore (not on SPARK) so have some familiarity with the subject.

There are also toolchains shipped as part of Alire since 1.1:

https://github.com/alire-project/alire/blob/release/1.1/doc/...

So you have a workflow similar to cargo in Rust:

* Install package manager * Let package manager install toolchains * ??? * Profit

Of course! But there are some tendencies, or else OP's comment wouldn't have made sense even in the context of the US.

My first few times in the US were in NYC, where I found a way of life that is very close to what I know as a Parisian. Imagine my surprise discovering basically any other city in the US.

You might not be part of that population, but the US problem goes way beyond a problem of perception, and there are numbers to confirm it.

Ok! Sorry about the violent agreement message then. Yes, there is definitely a balance to be found between individual freedom and collective well being here.

I guess what I'm getting at is that if people drive less, they'll realize that their car-centered lifestyles don't work anymore, and will have to find alternatives. Let's hope that's easier than what I envision :)

Interesting. I'm symmetrically not used to think about those problems from an american perspective. Thanks for the insight.

I can indeed see a world where working from home might in the short term infuse some life in local life, from neighbors to associations etc.. So maybe it's actually a positive change!

I'm used to the conversation in here being extremely US-centric, but realize that this is much less true for European cities with good public transportation. I haven't ever used a car to go to work in my life.

I'm also very concerned about this better world where people stay home to save the planet. The common level of social interactions in the modern world is already low enough in my opinion.

EDIT: It rarely happens this way but in retrospect I feel my comment is way too tame. You think your problem is going to work. The problem is the whole american lifestyle where you live in an individual house and need a car to do anything, your house is an ecological disaster in terms of how much energy you need to keep it warm/cold, and even bringing food to your house will incur a large carbon footprint.

I know the system is hard to changes, but some people need to see the bigger picture, even if you can't do anything about it yet.

As said in another comment, that's completely and demonstrably false.

As soon as a coding standard for C/C++ doesn't completely forbid the use of pointers (which is completely impossible at least in C), then it will be much more unsafe than Ada (or other alternatives like Rust).

You can have - very painfully - near pointer free programming in C++, but it requires the use of high level constructs (smart pointers, RAII, etc) that most if not all safety critical standards forbid the use of.

Some people like the Frama-C people are trying to make programming in - a restricted an enhanced subset of - C, safe. They're basically doing Ada/SPARK with annotations in C, and it's horribly painful.

So, despite its informed and documented appearances, your comments are spreading misinformation about what it's like to program in C/C++ for safety critical systems.

> C/C++ is used over Ada just for familiar syntax. From a safety perspective, the choice of language is inconsequential. With C/C++ the code analyzers used must do more work than with Ada but not that much.

That is completely and utterly false despite the millions (billions ?) invested in trying to make sound & safe static analysis tools for C/C++. I know you're trying to push that message but it couldn't be further from the truth. The nature of C & C++ is such that you cannot avoid unsafety, even with very restricted subsets.

Disclaimer: I work on Ada tools, but have also worked on C/C++ tools. I have also studied MISRA C and worked on such static analyzers for C & C++.

> I just think the FSF (and opensource as a whole) would be more successful with someone other than RMS as the figurehead.

I appreciate the moderation you show in your comment. That's why I'm going to answer that here rather than on a less thoughtful comment: free software and open source are not the same. Open source is a movement that today is trying to increase rentability and profits via information and code sharing. The rules that apply make it completely straightforward for a company to share only the part of code that they feel won't diminish profits, or even will increase them.

On the other hand, free software is a militant movement and ideology that is seeking to destroy a large part of the proprietary software that exists. While you would expect an open source proponent to shower, and even wear a tie, because he has to be entreprise friendly, the same codes don't necessarily apply to militantism. Going further, what you seek as the figurehead of some kind of consensual vision of open source will probably not be the same as for a militant organization.

I'm of course exaggerating a bit, but this is at the core of a lot of misguided arguments I see here and there. RMS is basically being accused of being shocking in his viewpoints and in who he is. Well, the very idea of free software was extremely shocking 30 years ago, so maybe it's no coincidence. I'm not condoning all he did or all he said, but I certainly wouldn't like some watered down open source ideologist as the head of the FSF, which has so far been a necessary uncompromising force in the ideological landscape of open source software.

It'll be alt-n on mac's I think!

As a musician I kind of strongly disagree with that. I was never able to adjust to latency above ~8ms. Some people might. I can't. I spent as much effort as necessary to ensure that my setup has low latency.

Of course if you're playing with quantization on, or sequencers, it's not as much of a problem

Affine types, which Rust more or less implements with its ownership system are very close to linear types, see https://en.m.wikipedia.org/wiki/Substructural_type_system#Af...

I'm not young anymore (35) but I really don't care about albums

> sane countries like France

You might want to look at what's going on in France right now before calling our democratic institutions sane :)

I have a completely opposite experience (on chess.com). Playing a lot of games lately at a low level, never stumbled upon a cheater.

I'm not sure why you are being downvoted, that sounds pretty reasonable to me. The idea that we'll have to make (at least) this level of compromise to survive as a species seems to still not be taken seriously in the tech world.