Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing Linux Modules in Ada (2016)

nihamkin.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Writing Linux Modules in Ada (2016)

#71

Post by nrr »

ajxs wrote: post #39
nrr wrote: 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.

Sure. I write a lot of Ada, and I'm a big fan of the language overall. My criticisms are minor, and it doesn't stop me enjoying the language: I feel like the 'begin', and 'end' tokens can be a bit verbose, and their verbosity doesn't add much to the language's clarity; I also dislike the fact that I need to place the same subprogram specification in both the specification and body file; I'm also on the fence about so…

Hey, thanks for following up.

I always felt that repeating myself to the compiler (down to `procedure subprogram is begin`…`end subprogram`) or otherwise being verbose was something of a feature in the vein of defense in depth than the syntax not aging well. It never seemed to me like it was meant to impose clarity on the code, just that you were meant to file your subprograms and types in triplicate. It's useful as a backstop against trying to do things quickly instead of doing them deliberately.

At least, Ada's use of verbosity stands in stark contrast to COBOL, which does have the explicit aim to make things clear.

I'm mostly of the same mind as you in re Python's (and Haskell's and F#'s) whitespace-oriented ways of doing things, at least until the real world creeps in. I've had problems with early block termination because of mixed tabs and spaces that weren't readily apparent, and the language's toolchain wasn't particularly helpful in diagnosing them, leading me to lean on external tools. (COBOL at least has the heritage of being column-oriented, so indentation being significant is less problematic there.)

Re: Writing Linux Modules in Ada (2016)

#72

Post by glacia01 »

Galanwe wrote: post #70
glacia01 wrote: post #68

Earlier quoted context omitted.

>I know berating C is trendy, but it feels a bit gratuitous and uncalled for in your comment... Sorry about that, English is not my first language so i might sound rude sometimes. I actually dont hate C, but if you used it you know its flaws. I think stuff i mentioned about C is objectively bad, hence why i called them dumb stuff. >Not sure I would like fat pointers, exceptions and threads in my embedded code though…

> Sorry about that, English is not my first language so i might sound rude sometimes No offense taken, not a native here either ;-) > if you used it you know its flaws Indeed, I've been using C for almost 20 years now. I won't say it's without flaw for sure, it has its quirks, but overall I do think it's quite okay for the job. > Fat pointers are just pointer + size of an object Yeah I know what fat pointers are, I e…

>But the thing is, we're talking embedded here. Most ucontrollers I use have 8b address space, no MMU or any form of virtual memory, separated instruction/data bus (MVHA). That kind of thing don't play well with funky fat pointers.

You can definitely use Ada on 8bit microcontrollers, for example on 8bit AVR: https://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ug...

You can make runtime as small as you want.

As for exceptions and threads: I mentioned them because thats what comes to mind first, there are more benefits obviously.

Re: Writing Linux Modules in Ada (2016)

#73

Post by touisteur »

another2another wrote: post #56
touisteur wrote: post #18

Earlier quoted context omitted.

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.

That secondary stack is cool! I want it for my C++ programs, particularly std::string which always heap alloc. begin return "Forty Two"; end Get_Answer;

You're returning a string which size might be known at compile time through inter procedural analysis. Too easy.

The secondary stack would better be used for 'functions returning objects, of which you don't know the size, at call time'.

   function Any_Number (A : Natural) return String is
   begin
      if A = 42 return "A = Quarante Deux";
      end if;
      return "A =" & A'Image;
   end Any_Number;
Or for those allergic to begin/end

   function Any_Number (A : Natural) return String is (if A = 42 then "A = Quarante Deux" else "A =" & A'Image);

Re: Writing Linux Modules in Ada (2016)

#74

Post by tomcam »

BirAdam wrote: post #52
tomcam wrote: post #22

Earlier quoted context omitted.

What’s your sense of the size of the Ada job market? High hundreds? Close to 10,000? Is it static or growing or shrinking? Is there a preferred online community for Ada devs?

The Ada job market is still large in aerospace and defense industries where lives are on the line.

When you say large, what do you guess in actual numbers? Just a rough impression; I'm not going to hold you to anything.

Re: Writing Linux Modules in Ada (2016)

#75

Post by pjmlp »

peppermint_gum wrote: post #55
pjmlp wrote: post #48

Earlier quoted context omitted.

Yeah, that is what happens when one doesn't understand contracts and formal proofs are used, my dear newly created account to advocate for Rust.

I've noticed a pattern that many Ada advocates on HN don't really seem to know the language. So they often conflate SPARK with Ada (as you just did) and make unfounded claims about Ada's memory safety, portraying it as being on par with Rust. It isn't on par, Ada has no lifetime management whatsoever. It doesn't even provide C++ style smart pointers out of the box. It is possible to implement something like shared_pt…

SPARK is part of Ada, time to update your ISO Ada knowledge.

Re: Writing Linux Modules in Ada (2016)

#76

Post by lionkor »

augustk wrote: post #25
lionkor wrote: post #19

Earlier quoted context omitted.

They likely mean the pascal-like syntax

Standard Pascal has 35 reserved words compared to ANSI C 89 which has 32. Not a big difference in terms of English-heaviness. https://wiki.freepascal.org/Standard_Pascal https://en.cppreference.com/w/c/keyword

Pascal uses words in a lot of places where C uses symbols

Re: Writing Linux Modules in Ada (2016)

#77

Post by peppermint_gum »

pjmlp wrote: post #75
peppermint_gum wrote: post #55

Earlier quoted context omitted.

I've noticed a pattern that many Ada advocates on HN don't really seem to know the language. So they often conflate SPARK with Ada (as you just did) and make unfounded claims about Ada's memory safety, portraying it as being on par with Rust. It isn't on par, Ada has no lifetime management whatsoever. It doesn't even provide C++ style smart pointers out of the box. It is possible to implement something like shared_pt…

SPARK is part of Ada, time to update your ISO Ada knowledge.

No, it isn't. I think you're confusing contracts (added in Ada 2012) with the entirety of SPARK.

Re: Writing Linux Modules in Ada (2016)

#78

Post by eggy »

I always recommend this book, "Building High Integrity Applications with SPARK" as an introduction to how SPARK can be used for high-integrity, safe programs for mission-critical applications. SPARK has a legacy of large, high-integrity applications over the past two decades. This puts it ahead of Rust in real-world usage for such applications. SPARK2014 the latest, is a formally verified PL along with verification tools/ecosystem made for these type of uses.

I am trying to write show control software in SPARK2014 at the moment. Show control are critical since it is used to power lifts and stage machinery as well as performer flying systems where safety and high-integrity software is critical. I like Rust, but I feel it is not quite there yet especially in terms of the number of real-world systems in this niche. I also find SPARK2014 easier to write and read. I have been programming since 1978, and although I gravitate towards terse, functional languages like Haskell, APL/BQN/J, I experience a lot of friction whenever I dive back into Rust. SPARK2014 is very verbose and Pascal-like, but this is tedium vs. confusion or confidence in what I am writing. I know AdaCore is working with Ferrous Systems to bring Rust more up to the features of Ada/SPARK2014, but for now I needed to make a pragmatic choice based on real-world usage and ease of use and understanding.

Re: Writing Linux Modules in Ada (2016)

#79

Post by jk4930 »

eggy wrote: post #78

I always recommend this book, "Building High Integrity Applications with SPARK" as an introduction to how SPARK can be used for high-integrity, safe programs for mission-critical applications. SPARK has a legacy of large, high-integrity applications over the past two decades. This puts it ahead of Rust in real-world usage for such applications. SPARK2014 the latest, is a formally verified PL along with verification t…

Just want to add that I prefer Ada over C++ despite it having less mind share, tools, and libraries because its productivity is so high. (Not saying that I dislike C++.)

And, speculating here, with the encroachment of AI into programming/software engineering, I assume that it's convenient to use languages that are declarative (e.g. Haskell) and/or designed for verification/formal methods (e.g. Ada/SPARK) to integrate AIs of various kinds.

Re: Writing Linux Modules in Ada (2016)

#80

Post by touisteur »

mkovach wrote: post #40

Ahh, Lovely Ada. When I was a wee lad, toiling as an Email consultant, having my mind slowly destroyed by Sendmail configurations, the constant fear induced by anything related to Microsoft and Email, and, well, let's not mention Lotus Notes, some wounds never heal, I had the grand idea of writing a secure collection of Email tools. This included SMTP, IMAP, POP3 daemons, and various other tools. I was going to write…

Look up Ada Web Server :-) no IMAP though. And no QUIC yet, sadly. I hope someone is going to write a whole HTTPS stack using RecordFlux. One can dream.
Post reply on HN