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

11–20 of 157 posts

Re: Ada: a C Developer's Perspective

#11

Post by breeze_em_out »

yoz-y wrote: post #3

I am going to be that guy and say: Poorly compressed JPEG images for text examples?

Every time I see that shit I think, "Man, I'm glad we learned how stupid that is." but then immediately after I realize that people are still doing it all the time, because I think that same thought all the time.

People are so STUPID!

"Oh my god breeze, you are so rude, just because people programming critical infrastructure systems literally can't copy and paste things doesn't mean they're stupid!"

-- Stupid people'

Why yes. Yes, it actually does. That you don't like me saying it, doesn't make it any less true, and in fact gives me great pleasure in saying it.

Re: Ada: a C Developer's Perspective

#12

Post by evacchi »

pavlov wrote: post #10
evacchi wrote: post #5

It's such a pity these days there is no modern tool chain/workflow for Ada (or C++ for that matter). I mean, a package manager, a build tool with integrated dependencies. As far as I know, there is very little open source software for Ada. It's a shame, because I feel like the language would become more mainstream, if only better tooling was easily available.

For C++, I'm reasonably happy with CMake and the Jetbrains CLion IDE. CMake makes it relatively painless to wrap multi-platform dependencies without having to explicitly know whether they come from a Unix package manager or from Windows DLLs.

I wish there were a simplified (as in automated) and "community-blessed" workflow at least for static binaries with source dependencies, like all the popular "modern" PLs are doing these days. I'm saying this as a newcomer (in C++ land) that finds the lack of this kind of tooling a bit intimidating.

Re: Ada: a C Developer's Perspective

#13

Post by breeze_em_out »

pavlov wrote: post #8
flukus wrote: post #4

So how does Ada go speed wise (real world not micro benchmarks)? Were/are there legitimate reasons to opt for c over Ada?

On early PCs, Pascal and C were pretty much tied in popularity. Both were free to implement, and small enough that you could make a fast compiler on a typical PC with only 256-640 kB RAM. C won because it was more flexible and was chosen by Microsoft, but Pascal definitely had a strong following (it was the original Mac's API language, and on PC it was a major contender thanks to the nice and fast Turbo Pascal IDE).…

Ada is the F14. Expensive, works well, but ya really just don't need it most of the time.

Re: Ada: a C Developer's Perspective

#14

Post by pjmlp »

pavlov wrote: post #8
flukus wrote: post #4

So how does Ada go speed wise (real world not micro benchmarks)? Were/are there legitimate reasons to opt for c over Ada?

On early PCs, Pascal and C were pretty much tied in popularity. Both were free to implement, and small enough that you could make a fast compiler on a typical PC with only 256-640 kB RAM. C won because it was more flexible and was chosen by Microsoft, but Pascal definitely had a strong following (it was the original Mac's API language, and on PC it was a major contender thanks to the nice and fast Turbo Pascal IDE).…

The sad part is that it turned out that Ada compilers were actually easier to implement than C++ ones.

And while we can do Ada style programming in C++, the lack of control over the C copy-paste compatibility features hinders that, unless one is allowed to turn all security knobs on (warnings as errors, sanitizers, code guidelines compliance).

Re: Ada: a C Developer's Perspective

#15

Post by JohnStrange »

flukus wrote: post #4

So how does Ada go speed wise (real world not micro benchmarks)? Were/are there legitimate reasons to opt for c over Ada?

It depends on which compiler you use. Assuming you use GNAT, the compiler is written in Ada and the backend is gcc, and you have the same optimization options as C in gcc.

I'd say its performance is usually in the range of C++ performance. You can make it as fast as C, of course, because nobody forces you to do object-oriented programming (tagged types in Ada) and all runtime checks can be switched off with pragmas. However, I don't think that many Ada programmers are interested in that.

In a nutshell, speed is not a reason to opt for Ada over C. Safety and maintainability are. As for reasons for going the other way, there are plenty of them. Getting Ada programs to compile can take a long time, especially when you're learning the language, and the learning curve is relatively steep. Ada is a huge language in comparison to C and it's syntax is "per-construct" - it looks easy but there is a lot more to learn in comparison to, say, Pascal. Another reason: Lack of external libraries. C has way more.

Re: Ada: a C Developer's Perspective

#17

Post by reacweb »

"Code should be easy to write, easy to read, easy to maintain, and most importantly, it should be reliable". Ada is not easy to write. Perl is easy to write (but not easy to read or maintain).

When I was student, Ada was the main language at my school. It was used the first year to teach algorithms and the second year to teach parallelism. During the first year, I have also learned C by myself for curiosity. After the summer holidays between first and second year, I had forgotten most of the syntax needed to start a new program in Ada, but I was remembering perfectly well how to code in C.

Even After 8 years of usage of Ada, I still needed the user manual regularly. After less than 1 year of usage of C, I could sell my R&K.

Re: Ada: a C Developer's Perspective

#18

Post by reacweb »

reacweb wrote: post #17

"Code should be easy to write, easy to read, easy to maintain, and most importantly, it should be reliable". Ada is not easy to write. Perl is easy to write (but not easy to read or maintain). When I was student, Ada was the main language at my school. It was used the first year to teach algorithms and the second year to teach parallelism. During the first year, I have also learned C by myself for curiosity. After th…

As a disclaimer, I love Ada (and Perl) and I regularly despise C++.

Re: Ada: a C Developer's Perspective

#19

Post by pathsjs »

pavlov wrote: post #10
evacchi wrote: post #5

It's such a pity these days there is no modern tool chain/workflow for Ada (or C++ for that matter). I mean, a package manager, a build tool with integrated dependencies. As far as I know, there is very little open source software for Ada. It's a shame, because I feel like the language would become more mainstream, if only better tooling was easily available.

For C++, I'm reasonably happy with CMake and the Jetbrains CLion IDE. CMake makes it relatively painless to wrap multi-platform dependencies without having to explicitly know whether they come from a Unix package manager or from Windows DLLs.

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 the dockerfile instructions to download and install the dependencies... you see, things get out of hand real fast

Re: Ada: a C Developer's Perspective

#20

Post by pavlov »

evacchi wrote: post #12
pavlov wrote: post #10

Earlier quoted context omitted.

For C++, I'm reasonably happy with CMake and the Jetbrains CLion IDE. CMake makes it relatively painless to wrap multi-platform dependencies without having to explicitly know whether they come from a Unix package manager or from Windows DLLs.

I wish there were a simplified (as in automated) and "community-blessed" workflow at least for static binaries with source dependencies, like all the popular "modern" PLs are doing these days. I'm saying this as a newcomer (in C++ land) that finds the lack of this kind of tooling a bit intimidating.

I know what you mean. It's just really hard to bolt dependency management on C family languages, and so many ways it can exacerbate the problem by adding another layer of accidental complexity... (IMHO, CocoaPods is a good example of how a community-managed library dependency manager can end up creating a worse mess than the one it tried to solve.)

The Rust team started working on a package manager early as part of the language design, which seems like the only way to make it actually work.

Post reply on HN