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

Why Ada Is the Language You Want to Be Programming Your Systems With

hackaday.com

Post reply on HN
Print view View original

101–110 of 330 posts

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#101

Post by flavio81 »

vardump wrote: post #74
59nadir wrote: post #71

Earlier quoted context omitted.

It's incredibly silly to want to insert Rust into every discussion and suggest every article written about something that Rust (sort of) does should mention it. It's not a good look for people not yet into Rust that this stuff is still happening, IMO.

In this discussion, Rust is actually relevant, nearest comparison I can think of. It's not necessarily as much Rust as the desperate need to get something safer than C/C++ without compromising performance and interoperability.

>as the desperate need to get something safer than C/C++ without compromising performance and interoperability

Object Pascal

D

ATS

Common Lisp

Ada

even Fortran!!

the list can go on and on

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#102

Post by ddoolin »

haolez wrote: post #68
jeffdavis wrote: post #40

There is some overlap in the use cases between Ada-in-the-mainstream (which seems to be what the article is suggesting) and Rust. The existence of Rust will make it even harder for Ada to break out of its existing domains. Both seem to have good ecosystems, but quite different. Ada has more high-assurance tooling and practices. Rust has more in terms of packaging and general-purpose high level libraries. With Ada, it…

Having a big ecosystem of libraries is not even close to a big concern when developing critical applications like what Ada seems to be used for.

There was a post here recently about an attempt to bring those concerns to Rust: https://ferrous-systems.com/blog/sealed-rust-the-pitch/#

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#103

Post by hollerith »

wrp wrote: post #72

This article promotes a popular misconception of the programming situation for defense projects in the 1970s. There may have been "hundreds of specialized programming languages" in existence that could be used, but just a handful actually predominated. Most aeronautical projects were done in JOVIAL. I've talked about this history with engineers from the 1960s-70s. They did not regard the introduction of Ada as a good…

Ada exists because of the US Department of Defense. In particular, it formed a working group, headed by a military officer, which

>crafted the Steelman language requirements, a series of documents stating the requirements they felt a programming language should satisfy. Many existing languages were formally reviewed, but the team concluded in 1977 that no existing language met the specifications. Requests for proposals for a new programming language were issued and four contractors were hired to develop their proposals [1].

The success of the language resulting from this process was ensured by the D of D's strong desire for a standard programming language shared by all of its contractors.

[1] https://en.wikipedia.org/wiki/Ada_(programming_language)#His...

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#104

Post by LPDWORD »

vardump wrote: post #80
LPDWORD wrote: post #77

Earlier quoted context omitted.

> Why use floats when you can basically have doubles for the same cost? Floats costing the same as doubles is a myth stemming from x87 arithmetic, which is obsolete. On an x64 CPU running 64-bit code, your compiler can often pack four floats into one SSE register. Even when that doesn't happen, CPU microcode can likely do more with floats than with doubles. Lastly, memory bandwidth usage and cache occupancy doubles,…

The difference is meaningless in scalar code. Not everything is or can be vectorized. Pretty much no difference between one double and one float in a SSE XMM register. > Even when that doesn't happen, CPU microcode can likely do more with floats than with doubles. I have no idea what that means. As far as I know, there's no CPU microcode dealing with floating point numbers. > Lastly, memory bandwidth usage and cache…

If you already knew there was a cost difference, why didn't you just say so?

> The difference is meaningless in scalar code. Not everything is or can be vectorized.

Multiple scalars can be packed into one SSE register even in scalar code. This is not the same as vectorization.

> Pretty much no difference between one double and one float in a SSE XMM register.

Even then, some arithmetic operations have higher throughput with floats than with doubles.

> I have no idea what that means. As far as I know, there's no CPU microcode dealing with floating point numbers.

Your CPU doesn't execute the ISA directly in hardware, it first converts it into architecture specific micro-ops. That includes FP operations.

> So use floats when you have a lot of data.

That's not the point. A lot of the time, the cost difference will indeed be irrelevant. The point is that there is a cost difference.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#105

Post by falcolas »

vardump wrote: post #52
falcolas wrote: post #28

Earlier quoted context omitted.

> - Easy to implement the language specification. All features should be easy to understand. I'm not sure this is at all applicable to rust. Perhaps once there are more than the one, quickly mutating, implementation, we can say that it's easy to implement the specification. > - Reliability. The language should aid the design and development of reliable programs. This one feels a touch questionable, given the built-in…

> ...unsafe operation in one section of code (say, an imported library) can have negative impacts on unrelated sections of code otherwise deemed safe. Yeah. Just like every line in C/C++ code can have negative impacts on unrelated sections. While true, that talking point feels somewhat unfair or even in bad faith. Rust requires "unsafe" escape hatch to be able be a low level systems language. Or gasp, to call librari…

This comparison is against Ada's language criteria, not C/C++.

You're well above 100% right with your points, if we weren't looking at the language criteria put forth by Ada.

EDIT: It's worth nothing that Ada is also a system and embedded programming language.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#106

Post by falcolas »

swsieber wrote: post #33
falcolas wrote: post #28

Earlier quoted context omitted.

> - Easy to implement the language specification. All features should be easy to understand. I'm not sure this is at all applicable to rust. Perhaps once there are more than the one, quickly mutating, implementation, we can say that it's easy to implement the specification. > - Reliability. The language should aid the design and development of reliable programs. This one feels a touch questionable, given the built-in…

> given the built-in "succeed or die" macros that simplify code at the cost of reliability Most of those are linted for, so you can use them to speed development but still be aware that they shouldn't be there in production code.

These points are around language design and implementation; linting is an additional set of tools outside the scope of the language itself.

Whether it should or shouldn't be in production, following Ada's rules it wouldn't be allowed in the code in the first place.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#107

Post by Jtsummers »

galangalalgol wrote: post #98
fortran77 wrote: post #89

Earlier quoted context omitted.

Why can't someone write an article about Ada without it having to be about Rust?

Because they overlap almost entiely in use case?

From my own analysis, about a year ago, I do not believe this to be true. Rust is memory safe, but it does not offer the type system that Ada does. The type system is where a large portion of Ada's safety comes from. They're both tackling software/system safety, but from different directions and to different ends.

Additionally, modern Ada (after the introduction of SPARK, what 15 years ago now?) offers even more safety features that I've not seen in Rust, through the form of code contracts. Conttracts which can be used as run-time checks, and (to some degree) as static proofs about the code.

Extend Rust's type system and add a contract mechanism, then it'll have the same use-case that I have for Ada.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#108

Post by pkaye »

magduf wrote: post #69
opencl wrote: post #37

Earlier quoted context omitted.

A lot of people trained as EEs seem to end up in software dev jobs these days.

Yep. You don't find many EEs left in the US these days, unless they work at a military contractor. All the electronic hardware design work went to Taiwan and China, because that's where all the manufacturing for it is. What's left is government-related (military) stuff that obviously can't be outsourced to Asia, and some commercial stuff that they keep in-house for various reasons. Basically, the US is a really bad p…

> Basically, the US is a really bad place to be an electrical engineer specializing in electronic hardware, but it's a great place to be a software engineer or developer.

Its because software engineers get paid much better in addition to more options. As a firmware engineer I straddled both sides. So many of my EE colleagues lamented they should have done more on the software side. A few of the brilliant ones moved to places like Google, Amazon which need them for specialist roles.

I remember a decade back I was visiting a customer in Taiwan to help debug our product and saw a legion of Chinese engineers helping out some project. I knew eventually Taiwan would lose some of their R&D to China.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#109

Post by galangalalgol »

Jtsummers wrote: post #107
galangalalgol wrote: post #98

Earlier quoted context omitted.

Because they overlap almost entiely in use case?

From my own analysis, about a year ago, I do not believe this to be true. Rust is memory safe, but it does not offer the type system that Ada does. The type system is where a large portion of Ada's safety comes from. They're both tackling software/system safety, but from different directions and to different ends. Additionally, modern Ada (after the introduction of SPARK, what 15 years ago now?) offers even more safe…

SPARK contracts look super interesting. It seems like that could let an optimizer do some great stuff and decrease the mental burden of reasoning about mostly pure functions by calling out specific side effects. What is different about its types? I don't see anything obvious. What I'd miss about rust is the borrowchecker and const by default.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#110

Post by vardump »

LPDWORD wrote: post #104
vardump wrote: post #80

Earlier quoted context omitted.

The difference is meaningless in scalar code. Not everything is or can be vectorized. Pretty much no difference between one double and one float in a SSE XMM register. > Even when that doesn't happen, CPU microcode can likely do more with floats than with doubles. I have no idea what that means. As far as I know, there's no CPU microcode dealing with floating point numbers. > Lastly, memory bandwidth usage and cache…

If you already knew there was a cost difference, why didn't you just say so? > The difference is meaningless in scalar code. Not everything is or can be vectorized. Multiple scalars can be packed into one SSE register even in scalar code. This is not the same as vectorization. > Pretty much no difference between one double and one float in a SSE XMM register. Even then, some arithmetic operations have higher throughp…

> Multiple scalars can be packed into one SSE register even in scalar code. This is not the same as vectorization.

They can, but can you honestly call it a common case for scalar code?

> Even then, some arithmetic operations have higher throughput with floats than with doubles.

By far the most (90-99%) of FP computation is additions and multiplications (or fused multiply adds). For scalar case (1 double or float in SSE register), they take precisely as long on modern x86 hardware.

Sure, float div executes in 11 instead of 13-14 clocks for doubles and I'm sure transcendentals are even worse, but they're rarely needed. Even then, if the dependency chain allows, the cost is often OoO scheduled away in integer dominated code.

> Your CPU doesn't execute the ISA directly in hardware, it first converts it into architecture specific micro-ops. That includes FP operations.

Except that SSE instructions pretty much are micro-ops as-is. Despite similarly sounding term, microcode has nothing to do with micro-ops.

> That's not the point. A lot of the time, the cost difference will indeed be irrelevant. The point is that there is a cost difference.

Well, I've written a lot of SSE, AVX etc. SIMD code. There sure is a big difference when you're processing large amounts of data. But... I've seen floats introducing silly precision related bugs [0] and a ton of useless float -> double -> float conversion chains. Most of the time most programmers should default to double.

[0]: Example: https://randomascii.wordpress.com/2012/02/13/dont-store-that...

Post reply on HN