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

Giving Ada a Chance

ajxs.me

Post reply on HN
Print view View original

251–260 of 261 posts

Re: Giving Ada a Chance

#251

Post by Lucretia9 »

MaxBarraclough wrote: post #218
rsj_hn wrote: post #177

Earlier quoted context omitted.

I really think a semantic facelift would do wonders for ADA, and shouldn't make much of a difference for readability. I know a lot of people are turned off by this.

I suspect overhauling the syntax is the kind of change that the committee would see as rather dramatic and with limited payoff. Introducing an optional alternative syntax alongside the existing one, would likely be seen as opening the door to syntactic inconsistencies, more likely to harm readability than to enhance it. The Python community has a relevant saying: There should be one -- and preferably only one -- obvi…

and then and or then are shortcut operations, not the same as && and ||, those are and and or.

Re: Giving Ada a Chance

#252

Post by MaxBarraclough »

Lucretia9 wrote: post #251
MaxBarraclough wrote: post #218

Earlier quoted context omitted.

I suspect overhauling the syntax is the kind of change that the committee would see as rather dramatic and with limited payoff. Introducing an optional alternative syntax alongside the existing one, would likely be seen as opening the door to syntactic inconsistencies, more likely to harm readability than to enhance it. The Python community has a relevant saying: There should be one -- and preferably only one -- obvi…

and then and or then are shortcut operations, not the same as && and ||, those are and and or .

In C and C++, the && and || operators both short-circuit. For eager semantics in C/C++ you could make do with the bitwise operators & and |, keeping in mind that they're bitwise and not logical. You could do something like (!!first_int) | (!!second_int). You'd be better off forcing eager evaluation by saving the results to local variables, and then use the short-circuit logical operators.

Ada's and and or operators have no direct equivalents in C or C++.

https://en.wikipedia.org/wiki/Short-circuit_evaluation#Suppo...

Re: Giving Ada a Chance

#253

Post by OneWingedShark »

Lucretia9 wrote: post #250
OneWingedShark wrote: post #246

Earlier quoted context omitted.

I have heard of it, and was tempted to grab a copy of the spec. -- The context in which I heard it, language design, Ada was put forth as the only language designed for both maintainability and correctness, someone responded that CHILL was another, but the only other they knew of. https://psc.informatik.uni-jena.de/publ/1999-T-REC-Z.200-199... https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Z.20...

Both those links are the same, btw. I can see why it's no longer used, with all those modes! But another language with ranges. Also has module inheritance.

>Both those links are the same, btw.

Yes, two different locations for freely getting the spec.

> I can see why it's no longer used, with all those modes! But another language with ranges. Also has module inheritance.

IIRC, "mode" used to mean (in some cases, historically, in CS) the equivalent of what we now call a "type" — I seem to recall Algol using the terminology, but may be misremembering.

Re: Giving Ada a Chance

#254

Post by OneWingedShark »

icedchai wrote: post #249
OneWingedShark wrote: post #235

Earlier quoted context omitted.

> How can you say C has no real value in a professional setting? Fairly easily. My professional career has been mainly in maintenance and, as such, I get to see the gritty back-end of things, the end-result of all the technical-debt... and being more correctness and security-minded than most, I often note how a good design could help prevent problems, both on the language being used to implement and on the project it…

I think you and I see "value" differently. C is literally everywhere. Other people know it and are able to work with it. Tons of existing code is written in C. Most other languages can interface with it. This combination makes it incredibly valuable in a professional setting. It is used inappropriately? Sometimes. Can there be better alternatives? Yes. But to say it has "no real value" is a bit extreme.

Pretty much all of my career has been in maintenance, so I tend to see the mess that gets made and while bad-design is always a killer, I notice there are languages that encourage/discourage it to varying degrees.

In the case of C, and other C-like languages, I most recently have four or five custom-made programs [some requiring specialized tools] that have little/nothing in the way of documentation: what it does, the "why-for"/motivation, any sort of high-level architecture-plan, or design-documents.

Fortunately for me, most of the programs actually do have documentation thanks to a true hero that left before I arrived.

Re: Giving Ada a Chance

#255

Post by 7thaccount »

OneWingedShark wrote: post #245
pkolaczk wrote: post #231

Earlier quoted context omitted.

Is Python not an OOP language? I think it is, so OOP design patterns still apply to it. So the differences you observed might be not because of a language itself, but the complexity of projects these languages are applied to and cultural differences of the teams. So far I haven't worked on Python projects as big (in terms of functionality) as Java projects I've seen. As for data science, so far I haven't stumbled upo…

> As for concurrency - gluing systems together sometimes needs concurrency to cut the latency down. And in data science parallelism also means performance, and often it is needed. I'm not that convinced Python is a clear winner here. Ada is really quite good here, the Task is something such that I would say that if your application is inherently going to be dealing with concurrent processes you should seriously consi…

I think the winners in data science are Python, R, Matlab with Ada's share being non-existent. There is a reason for that. Ada doesn't have the numerical or data frame or stats libraries or any REPL functionality or charting libraries...etc. Language ecosystems are the thing that matters. I'd rather write Avionics or high speed trading systems in Ada, but data science? Maybe for some very niche problems.

Re: Giving Ada a Chance

#256

Post by andi999 »

Blikkentrekker wrote: post #149
MaxBarraclough wrote: post #61

Earlier quoted context omitted.

> People found it frustrating how much work it'd take to get their programs to even compile Makes sense if they're students working on small projects. Ada is explicitly designed to make large programs readable, and willingly trades off on writeability when the two come into conflict. It isn't going to shine if you're writing small 'single shot' applications, that isn't what Ada is for. (Ada also commits to using many…

> (Ada also commits to using many English language words where languages like C use symbols. SQL does this too. I'm not sold on the idea that this improves readability. Of course, there's far more to Ada than the skin-deep matter of its wordy syntax.) Wasn't the hypothesis behind COBOL that this would allow managers to gain a certain level of understanding of the code? I find that it made COBOL code notoriously unrea…

C is actually middle ground, if you consider APL.

Re: Giving Ada a Chance

#257

Post by icedchai »

OneWingedShark wrote: post #254
icedchai wrote: post #249

Earlier quoted context omitted.

I think you and I see "value" differently. C is literally everywhere. Other people know it and are able to work with it. Tons of existing code is written in C. Most other languages can interface with it. This combination makes it incredibly valuable in a professional setting. It is used inappropriately? Sometimes. Can there be better alternatives? Yes. But to say it has "no real value" is a bit extreme.

Pretty much all of my career has been in maintenance, so I tend to see the mess that gets made and while bad-design is always a killer, I notice there are languages that encourage/discourage it to varying degrees. In the case of C, and other C-like languages, I most recently have four or five custom-made programs [some requiring specialized tools] that have little/nothing in the way of documentation: what it does, th…

I did some maintenance work on a fairly large C++ system that called into a custom lower level library written in C. Much of my work involved extending that lower level library. It processed several billion dollars a year in financial transactions, and was barely documented at all. It was intended to be "portable" so it had bizarre #ifdefs all over the place in case you happened to compile it on an ancient Unix with a K&R compiler from 1986. This was the early 2000's, so nobody ever did that. I doubt it would've worked, yet those #ifdefs remained "just in case."

The lower level C library was pretty clever. The original developer of most of it left about a year into my tenure there. He was one of the smartest guys I ever worked with.

The C++ "app" layer was a different story. The worst part it was a 3000 line switch/case block with about 100 different cases, chock full of copy-and-pasted code. It went on... and on... and on... I still have nightmares about it.

Re: Giving Ada a Chance

#258

Post by fulafel »

bee_rider wrote: post #244
fulafel wrote: post #195

Earlier quoted context omitted.

Beginners to programming don't agonize over variable types, they don't have the mental model of statically typed language in their head.

They might not "agonize over variable types," but they do encounter agony when they try to add a string to an integer.

Yes. But statically associating types to binding names does not relieve them of making and fixing these mistakes, it just makes it a runtime vs compile time error.

Re: Giving Ada a Chance

#259

Post by OneWingedShark »

7thaccount wrote: post #255
OneWingedShark wrote: post #245

Earlier quoted context omitted.

> As for concurrency - gluing systems together sometimes needs concurrency to cut the latency down. And in data science parallelism also means performance, and often it is needed. I'm not that convinced Python is a clear winner here. Ada is really quite good here, the Task is something such that I would say that if your application is inherently going to be dealing with concurrent processes you should seriously consi…

I think the winners in data science are Python, R, Matlab with Ada's share being non-existent. There is a reason for that. Ada doesn't have the numerical or data frame or stats libraries or any REPL functionality or charting libraries...etc. Language ecosystems are the thing that matters. I'd rather write Avionics or high speed trading systems in Ada, but data science? Maybe for some very niche problems.

> Ada doesn't have the numerical or data frame or stats libraries

Ada has a pretty nice set of numerics (Ada.Numerics.*), but the "lack of libraries" is almost a non-issue when the foreign-function interface is as simple as:

    Function Example_1(Item : Some_Matrix) result Some_Matrix
       with Import, Convention => Fortran,
            External_Name => "EX1";
> or any REPL functionality

There are a few people coming in from data-science who lament the lack of REPL, while I might do one, it's rather low on my list, though I think HAC is trying for REPL or something like it. (I haven't used HAC yet.)

> Language ecosystems are the thing that matters. I'd rather write Avionics or high speed trading systems in Ada, but data science? Maybe for some very niche problems.

I agree that the ecosystems are what matters, and this alone would be enough to fuel my general hatred of C: the amount of time, effort, and money spent on C, whether "making a better C" or crippling tools (eg text-diff vs real semantic diff) or making "it 'mostly' works" accepted is simply astronomical.

Re: Giving Ada a Chance

#260

Post by OneWingedShark »

icedchai wrote: post #257
OneWingedShark wrote: post #254

Earlier quoted context omitted.

Pretty much all of my career has been in maintenance, so I tend to see the mess that gets made and while bad-design is always a killer, I notice there are languages that encourage/discourage it to varying degrees. In the case of C, and other C-like languages, I most recently have four or five custom-made programs [some requiring specialized tools] that have little/nothing in the way of documentation: what it does, th…

I did some maintenance work on a fairly large C++ system that called into a custom lower level library written in C. Much of my work involved extending that lower level library. It processed several billion dollars a year in financial transactions, and was barely documented at all. It was intended to be "portable" so it had bizarre #ifdefs all over the place in case you happened to compile it on an ancient Unix with…

> The C++ "app" layer was a different story. The worst part it was a 3000 line switch/case block with about 100 different cases, chock full of copy-and-pasted code. It went on... and on... and on... I still have nightmares about it.

Ouch. That sounds brutal. If I had to do something similar, or maintain that, in Ada I'd leverage nested subprograms, local type/subtype definitions, and mandatory case-coverage — and I've done similar with VMs, particular opcodes — so you get something like:

    Type Opcode is ( NOP, Add_A, SUB_A, ..., Rem_D );

    Procedure Execute_Instruction( State : in out Machine_State; Instructions : in Instruction_Stream ) is
       Subtype A_Series is Opcode range Add_A..Sub_A;
       Subtype B_Series is Opcode range Add_B..Sub_B;
       Subtype C_Series is Opcode range Add_C..Sub_C;
       Subtype D_Series is Opcode range Add_D..Sub_D;
       
       Procedure Do_Add_A;
       -- other subprograms.
       
       Current : Opcode renames Decode( Next_Token( Instructions ) );
       --...
    Begin
       Case Current is
         when A_Series =>
           case A_Series'(Current) is
             when Add_A => Do_Add_A;
           end case;
         -- other series.  
       end case;
    End Execute_Instruction;
Of course you could structure it so that all the Do_OPCODE subprograms are local to the top-level switch, or local to the nested switches, as best suits the design; or decompose along 'families' of operation (Add_A, Add_B, Add_C, Add_D), but the important thing there is keeping things local/nested for maintainability.
Post reply on HN