3 ms·
Ha ha. I'd been reading HN on my phone, saw the parent comment, thought 'I should write a post about Ada', and when I got back to my computer, saw this... Yes,
by david-given 11y ago
Ha ha. I'd been reading HN on my phone, saw the parent comment, thought 'I should write a post about Ada', and when I got back to my computer, saw this...
Yes, ranges work. They (and ordinary integers) throw exceptions on overflow:
type NonoverflowingByte is integer range 0..255;
If you want modulus arithmetic, you specify it:
type OverflowingByte is mod 256;
Modulus types seem to be always unsigned and are always 0-based. Anyone know different?
For saturating arithmetic, there doesn't seem to be built-in language support. (There isn't even a standard library package. That seems to be a bit of an omission. Isn't saturating arithmetic common in the kind of real-time environment where Ada is used?)
Ada so totally deserves to be better known.
- pjc50 11y ago> Ada so totally deserves to be better known I do wonder why it isn't. It's probably handicapped by its history: once people have written off a language they'll never look at it again, despite improvements to fix the very problems they fled. As an Ada advocate, what does it do badly? String processing? Networking?
- david-given 11y agoIt's got a lot of historic warts. e.g. the OO system is a retrofit with invisible syntax: functions defined immediately after the type representing the object are methods, but you can't interleave them with other statements. It desperately needs an explicit `class...end` structure. The OO model is kinda weird, too, although once you've beaten your head against it it makes sense. Another wart is that you can only define an expression function in a module specification and not in a module body. Huh? Likewise, you can only define pre- or post-conditions on public data, so you can't have a module assert on its private state; you must export the state first. String processing is both really nice and a pain. Built-in strings are fixed size, but the `array<>` magic means you do string processing using functional style without needing to explicitly size anything. The string libraries are a bit of a mess, with `Wide_String` and `Wide_Wide_String`, because they made the same mistake as Java and Windows about UCS-2 vs Unicode. The standard library is mostly really cool, but it makes the same mistake C++ does in that entries in collections are always initialised by copying, so you can't have collections of non-copyable objects. I forget the details but I think the last time I tried to do collections of pointers I couldn't make it work properly. Ada's generics are awesome. Nested functions that work properly are awesome. The compilation time is awesome. Access semantics that prevent you leaking pointers to inner stack frames are awesome. in-out parameters are awesome (they mostly replace pointers). Being unable to pass a nested function to a procedure as a callback parameter is less awesome; the access semantics forbid it. To my mind, though, the biggest showstopper in Ada is a technically fairly trivial thing: it's case insensitive. This means that any programmer used to case sensitive languages, which is basically any programmer, will have to drastically revamp their coding style to work with Ada, because none of the usual conventions about separating locals from globals by capitalisation work any more. It also makes Ada code look ugly to the untrained eye. It's hard to convert people when the first thing they say when looking at code is 'ugh'.
- CyberDildonics 11y ago> same mistake C++ does in that entries in collections are always initialised by copying, so you can't have collections of non-copyable objects Cool breakdown. This isn't true anymore in C++11 with move semantics. Also the expression functions only being in module specifications is probably due to their source code being needed to inline them.
- i_feel_great 11y agoAda is up against C, C++, C# and Java. They all have larger everything - libraries, pool of programmers, support companies etc. Ada is doomed to spend its lifetime in the shadows. Pity, it is superior to all these languages, at least in my experience.
- CyberDildonics 11y agoWith LLVM and the JVM making languages is easy, but making tools and the whole experience is difficult.