Live data from Hacker News

Writing Linux Modules in Ada (2016)

nihamkin.com

11–20 of 87 posts

Re: Writing Linux Modules in Ada (2016)

#11
post #7

Hah, my perfect niche! I think that an ada-like language could make a real resurgence in embedded programming. Ada gets all the things about bare-metal right that C got wrong. However, it's held up by legacy tooling, clunky syntax, and obtuse compiler errors. Adacore has gone a long way towards alleviating those issues over the last few years, with alire and the ada_language_server. Time will see where this language…

I completely agree. 'Design-by-committee' gets a bad rap, but Ada's designers got a lot of things right when it came to bare-metal programming. The ability to specify the in-memory representation of a type is one of my personal favourites. I don't think Ada's syntax has aged well. I wish it would get a 21st-century overhaul. I don't think that's likely though, but we can all dream. AdaCore do great work, and contribu…

It's unclear exactly what you mean by your remark that Ada's syntax hasn't aged well, let alone what a 21st-century overhaul would look like.

Is there any chance you'd expand on that? I'm curious to know your thoughts.

Re: Writing Linux Modules in Ada (2016)

#12
post #11
post #7

Earlier quoted context omitted.

I completely agree. 'Design-by-committee' gets a bad rap, but Ada's designers got a lot of things right when it came to bare-metal programming. The ability to specify the in-memory representation of a type is one of my personal favourites. I don't think Ada's syntax has aged well. I wish it would get a 21st-century overhaul. I don't think that's likely though, but we can all dream. AdaCore do great work, and contribu…

It's unclear exactly what you mean by your remark that Ada's syntax hasn't aged well, let alone what a 21st-century overhaul would look like. Is there any chance you'd expand on that? I'm curious to know your thoughts.

I think it's evident to most people that write Ada that the language is too English-heavy. This gets in the way of actually representing the computations. This was a design decision when the language was created, since the emphasis was put on maintainable code

Re: Writing Linux Modules in Ada (2016)

#13
post #5

Memory safety might not be a bad idea for Linux in general.

Ada’s take on memory safety is pretty limited. Heap allocation is explicit; there’s a procedure literally named Unchecked_Deallocation to free a pointer. It does have thread-scoped locals and arenas, but nothing like declared lifetimes or borrowing. The spec allows for GC but I believe it’s rarely offered.

It’s safer than C, but I’m not quite sure where recent specs line up against C++.

Re: Writing Linux Modules in Ada (2016)

#14
A very long time ago The University of York (UK) secured the contract from the UK Science and Engineering Council (SERC) to write a unix Ada compiler.

It was a multi pass, 5-10 stage process (or more. I want to say 13 but time plays tricks) Very costly language to compile, in those days. (Vax 11/780 running Unix 32V, a precursor to BSD and Ultrix by some years)

The story was it emitted an error/warning code along the lines of "Congratulations you have used the most abstruse feature of the ADA language" -which the approval people made them take out before it got certified.

Wirth had a sabbatical residency in York around the time of the Ada language selection process, his choices didn't make it through the strawman/steelman process, I think they resurfaced in Modula-II. It was a pascal teaching department like many others in the UK of the time, so it made sense for him to spend time there. Modula-II is said to be a systems programming language too.

Ada was very hard to teach. The ideas of asynchronous, and exception handling didn't sit very well on young minds. Maybe now they're well enough understood to teach in Rust. At the time, the absence of a rationale around "why" was very strong. York had a miniature 2-lift engine model which it used as a proving ground for Ada programs and undergraduate projects. Lift sequencing is a bit of a black art in itself but if you put that optimality of "which lift, which direction, which floor" to one side, the mixture of real-time controls and sensors were probably a good fit. (lift == elevator for the other side of the Atlantic)

I remember some concern in the department the only logical endpoint for Ada was to code military flight control/weapons/radar systems, and people felt uncomfortable about the implicit participation in the UK War economy. This was during the time of the Greenham common protests against US nuclear forces on UK soil.

During the Alvey 5th Generation funding debacle ("Catch up with Japan at all costs") there was another round of this using GEC400 computers, again very directly related to Uk MOD needs for weapons control systems and what I think became the Nimrod airborne radar. Probably signals processing is a very good fit for Ada. (I didn't work on that project, or the compiler)

People said that the consistency of mapping data structures to devices, chip signal lines, real things, and the abstractions around that in types worked well in Ada. I found it horrendously complicated to understand. People might say C is a hack but the literal directness of C structs on a PDP11 or Vax to the underlying architecture worked pretty well to me. I guess the problem is that C was always too close to Assembler for some people. Bliss/32 was the systems programming language of choice in Digital, and I think continued to be used to write VMS, although I read now it was almost entirely written in DEC Macro assembler.

Re: Writing Linux Modules in Ada (2016)

#15
post #11

Earlier quoted context omitted.

It's unclear exactly what you mean by your remark that Ada's syntax hasn't aged well, let alone what a 21st-century overhaul would look like. Is there any chance you'd expand on that? I'm curious to know your thoughts.

I think it's evident to most people that write Ada that the language is too English-heavy. This gets in the way of actually representing the computations. This was a design decision when the language was created, since the emphasis was put on maintainable code

Is this meant as a joke, too English-heavy?

Re: Writing Linux Modules in Ada (2016)

#16
post #7

Hah, my perfect niche! I think that an ada-like language could make a real resurgence in embedded programming. Ada gets all the things about bare-metal right that C got wrong. However, it's held up by legacy tooling, clunky syntax, and obtuse compiler errors. Adacore has gone a long way towards alleviating those issues over the last few years, with alire and the ada_language_server. Time will see where this language…

I completely agree. 'Design-by-committee' gets a bad rap, but Ada's designers got a lot of things right when it came to bare-metal programming. The ability to specify the in-memory representation of a type is one of my personal favourites. I don't think Ada's syntax has aged well. I wish it would get a 21st-century overhaul. I don't think that's likely though, but we can all dream. AdaCore do great work, and contribu…

Usually many forget that their beloved C, JavaScript, Webassembly, OpenGL, Vulkan, Web, POSIX,... are equally design by committee.

Re: Writing Linux Modules in Ada (2016)

#17
post #5

Memory safety might not be a bad idea for Linux in general.

Ada’s take on memory safety is pretty limited. Heap allocation is explicit; there’s a procedure literally named Unchecked_Deallocation to free a pointer. It does have thread-scoped locals and arenas, but nothing like declared lifetimes or borrowing. The spec allows for GC but I believe it’s rarely offered. It’s safer than C, but I’m not quite sure where recent specs line up against C++.

Only true for those stuck in Ada83.

People keep repeating this nonsense without updating themselves beforehand.

EDIT: To simply education on Ada,

Yes there was an optional GC, no one ever implemented it, so in Ada2012 got removed from the standard.

Almost everything can be allocated on the stack, so a strategy is to catch exceptions of not enough stack space and retry the same function with a smaller size for the data structure.

Ada95 introduced controlled types, which is basically Ada's version of RAII, no need to call Unchecked_Deallocation outside implementation details. Hardly any different from Rust code that uses unsafe underneath.

Ada/SPARK, now part of regular Ada specification, provides theorem proving capabilities, and contracts, allowing another safety level still not available in Rust.

Additionally Ada Core is contributing improving lifetime rules for access types, to have a kind of borrow checker light, when needed.

Finally, there are still 7 Ada vendors in business, with 40 years of experience deploying Ada into safety critical scenarios.

Re: Writing Linux Modules in Ada (2016)

#18
post #5

Memory safety might not be a bad idea for Linux in general.

Ada’s take on memory safety is pretty limited. Heap allocation is explicit; there’s a procedure literally named Unchecked_Deallocation to free a pointer. It does have thread-scoped locals and arenas, but nothing like declared lifetimes or borrowing. The spec allows for GC but I believe it’s rarely offered. It’s safer than C, but I’m not quite sure where recent specs line up against C++.

Recent work have introduced lifetimes and an ownership model into SPARK (the reduced easier-to-prove Ada subset) https://blog.adacore.com/using-pointers-in-spark and hopefully it'll trickle down soon in Ada.

Edit: there's also reference counting and controlled types of course. And the secondary stack makes many uses of heap allocation go away.

Re: Writing Linux Modules in Ada (2016)

#19

Earlier quoted context omitted.

I think it's evident to most people that write Ada that the language is too English-heavy. This gets in the way of actually representing the computations. This was a design decision when the language was created, since the emphasis was put on maintainable code

Is this meant as a joke, too English-heavy?

They likely mean the pascal-like syntax

Re: Writing Linux Modules in Ada (2016)

#20

Earlier quoted context omitted.

I think it's evident to most people that write Ada that the language is too English-heavy. This gets in the way of actually representing the computations. This was a design decision when the language was created, since the emphasis was put on maintainable code

Is this meant as a joke, too English-heavy?

I think it’s a reference to keyword heavy in an effort to mimic natural language similar to what COBOL tried to do.
Post reply on HN