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

Ada: a C Developer's Perspective

methodsandtools.com

Post reply on HN
Print view View original

101–110 of 157 posts

Re: Ada: a C Developer's Perspective

#101

Post by [deleted] »

pavlov wrote: post #22
pathsjs wrote: post #19

Earlier quoted context omitted.

The problem is that it does not manage and version dependencies for you. Say I start a new C++ project where I want - say - use ZeroMQ and also Folly to parse JSON. Where do I start? Should I install ZeroMQ and its headers globally? What if the version changes? Will it conflict with other system libraries? Well, better start using Docker. What if the version I need is not in the Ubuntu repositories yet? I need to add…

To paraphrase JWZ... "Some people, when confronted with a dependency problem, think 'I know, I'll use Docker.' Now they have two problems." Unfortunately there's no single answer. Static libraries vs. dynamic? Global install or packages from a repo? Everything depends on the degree of control you have over the deployment environment.

[deleted]

Re: Ada: a C Developer's Perspective

#102

Post by nickpsecurity »

adrianN wrote: post #85
JohnStrange wrote: post #63

Earlier quoted context omitted.

Why? Ada libraries from 2002 without outside dependencies work perfectly fine. I'm using that old libraries all the time. Ada has been designed specifically for that, it's been used in the aviation industry that runs the same code for 20+ years minimum. That you think otherwise only shows that you've never seriously used Ada in a larger project.

The last version of DOS also works really well for the things it was designed for. You still wouldn't start new projects targeting DOS if you could help it, even if it would satisfy your current requirements.

Well, we're talking a safe language. So, if want an archaic red herring, you'd be better bringing up Burroughs written in an Ada predecessor that was immune to most forms of code injection or crashes in 1961. If you want small and Ada, then Martes RTOS is one written in Ada that's still around. For small and secure, the Muen separation kernel can handle it.

Re: Ada: a C Developer's Perspective

#103

Post by dagw »

andrepd wrote: post #70
adrianN wrote: post #37

Earlier quoted context omitted.

If you start a project today that depends on a library that was last updated in 2002, then may God help you.

Well, why? Why would a library be bad just because it hasn't been updated in 15 years? Does it spoil? Maybe it doesn't need to be updated.

The current RFC for the base LDAP protocol is from 2006, so that is at least 4 years of potential updates/changes that are missing from the library.

Re: Ada: a C Developer's Perspective

#104

Post by eutectic »

bitwize wrote: post #94

Puppy 1: And so, in conclusion, we have determined that Ada provides sufficient safety guarantees and features for our embedded system needs. Any questions? Puppy 2: Yes, I have a question. Why didn't you use Rust? Puppy 1: That's a good question. While Rust looks promising, we felt it was too immature for our needs and decided to go with the time-tested, standardized semantics and extensive tooling available with Ad…

Don't you find it's so much easier to argue against yourself? None of those pesky unpredictable arguments to worry about.

Re: Ada: a C Developer's Perspective

#105

Post by kqr »

hsivonen wrote: post #51
fghvbnvbnfe wrote: post #33

Earlier quoted context omitted.

This idea that Rust and Ada are somehow alternatives continually pops up, and I still don't understand it. They each have their own ideas on what "safety" is, and how to address it. I'll admit I'm biased towards Ada, but I think it is pretty safe to say that "Rust safety" is a subset of "Ada safety" - but Rust does it's section and run further with it than Ada. Rust is obsessed with memory safety. That's it's thing.…

How does Ada address the problems that Rust's borrow checker addresses? Use-after-free in particular. As for not being alternatives, how do they mix in the same project? Does Ada have C-compatible FFI that lets both Ada and Rust see each other as C?

The general mindset is "if you need high integrity, you probably also need to statically determine an upper bound on memory usage." The consequence is that the safest Ada variants do not allow dynamic memory management at all.

But the next step down is to do the memory management in an isolated module of your code, which is then supposed to be vetted thoroughly.

Vanilla Ada (i.e. not the safest variant) does provide RAII for dynamic management of resources in general.

Re: Ada: a C Developer's Perspective

#106

Post by yoz-y »

cormacrelf wrote: post #48
coldtea wrote: post #39

Earlier quoted context omitted.

> I think we all agree if we could program with simple functions that each do one thing and one thing well then combine those functions makes for a much simpler language and easier to think about. Well, I don't agree. You could end up with tons of small functions, and complex interactions between them (whether they are pure or not) than make for spaghetti logic. I also don't see how Ada's pre/post conditions make it…

> You could end up with tons of small functions, and complex interactions between them (whether they are pure or not) than make for spaghetti logic. I think 'one thing well' is pretty much the opposite of this idea. It implies encapsulation and composition, not smushing together. If some functions are pure, there is no such thing as 'complex interactions between them', only simple ones. On the other hand, it would de…

Not all things can be expressed by simple interactions between simple functions. A program doing complex tasks composed of pure functions will be either wide (fewer functions but having many parameters) or tall (long string of functions with few parameters).

I do not believe that a simple paradigm shift will help you create arbitrarily complex programs simply. At some point the complexity must be handled.

Re: Ada: a C Developer's Perspective

#107

Post by kqr »

AstralStorm wrote: post #92
rcxdude wrote: post #55

Earlier quoted context omitted.

Ironically, it's also Ada's asserts which contributed to the failure (though far from the root cause): The result of the erroneous calculation wasn't actually used, so just ignoring it like C would have would have been fine. It was the fact that the wrong cast caused the software to abort which resulted in the crash.

This is why static checking is better than runtime checking. Rust has some, but not enough. What is needed is something like Isabelle sledgehammer, quickcheck and metis logic and higher function correctness checkers. (Yes, Haskell has a bit more primitive version of Quickcheck.)

That's basically what SPARK Ada is.

Re: Ada: a C Developer's Perspective

#108

Post by phaylon »

sidlls wrote: post #93
Manishearth wrote: post #87

Earlier quoted context omitted.

I don't really understand the "Rust is obsessed with memory safety" meme. When pitching Rust to others of course memory safety and thread safety get hyped a lot; because it's talking about something that most languages just can't do -- safety without compromise. But actually ... memory safety is a small part of the reasons why I like Rust, and there are plenty of other cool bits in the language. It stands out a bit b…

I don't understand why the public marketing effort is so focused on safety, either, but it is. When I see Rust mentioned, e.g. here at HN, I cringe a little because odds are it's in the context of how unsafe everything else is, or there is at least some connection made to safety. "Obsession" seems loaded. Rust is a very nice language with many useful and interesting features which may exist because of the developers'…

By "public marketing effort" do you mean "people talking about Rust"?

Personally, I interpret the focus on memory safety as a response to "memory issues aren't a big deal" or "memory issues only come from incompetence" viewpoints.

Re: Ada: a C Developer's Perspective

#109

Post by kqr »

mhd wrote: post #43

Does someone have experience with Ada 2012s Design By Contract support (including tooling, preferably for GNAT)? Eiffel is yet another Pascal-ish language whose passing I lament, and lately I've been seriously considering giving Ada another try, given that Modula-3 and Oberon won't exactly come back to life miraculously, and I'm still a bit dubious about all the new kids on the block.

In a hobby capacity, yes. It's hard to go back to programming without contracts and invariants once I've had a taste for it.

Re: Ada: a C Developer's Perspective

#110

Post by jononor »

tom_mellior wrote: post #79
wBI8j2bsb wrote: post #76

Earlier quoted context omitted.

This is exactly what C does. #include typedef struct { double v; } Celsius; typedef struct { double v; } Fahrenheit; void print_celsius(Celsius temperature) { printf("Temperature is %f", temperature.v); } void compile_error(Fahrenheit temperature) { print_celsius(temperature); } I suspect LLVM will clean this up to plain floats as well.

Whether any compiler "cleans this up" depends in the system's ABI; parameter calling conventions are not up to the compiler to decide (unless it can prove that a given function cannot be called from code it does not control). That said, yes, modern ABIs for modern machines usually pass single-element structures of primitive types in registers of the appropriate type. x86 (32-bit) is not modern in this sense: dependin…

Or if the calls are inlined. Not sure if say Rust can/does this more aggresively than C or C++ (or vica versa).
Post reply on HN