|
|
|
|
|
|
by ajxs
1024 days ago
|
|
|
Sure. I write a lot of Ada, and I'm a big fan of the language overall. My criticisms are minor, and it doesn't stop me enjoying the language: I feel like the 'begin', and 'end' tokens can be a bit verbose, and their verbosity doesn't add much to the language's clarity; I also dislike the fact that I need to place the same subprogram specification in both the specification and body file; I'm also on the fence about some of Ada's pointer semantics; For what it's worth, I'm also not a big fan of the particular style that the Ada language server auto-formats code into. I'll use this chance to say that I'm a fan of Ada's declarative blocks, which you could say are part of its syntax. There's a lot to like about Ada, and I'd encourage anyone interested in bare-metal programming to give it a try. Even if you don't intend to use it long-term, there's a lot of good language design ideas in Ada that can be learned from. To address a sibling comment alleging that I'd rather it look like C, that's not necessarily true. I know this is much more controversial, but I'm actually more of a fan of Python's syntax. |
|
|
I always felt that repeating myself to the compiler (down to `procedure subprogram is begin`…`end subprogram`) or otherwise being verbose was something of a feature in the vein of defense in depth than the syntax not aging well. It never seemed to me like it was meant to impose clarity on the code, just that you were meant to file your subprograms and types in triplicate. It's useful as a backstop against trying to do things quickly instead of doing them deliberately.
At least, Ada's use of verbosity stands in stark contrast to COBOL, which does have the explicit aim to make things clear.
I'm mostly of the same mind as you in re Python's (and Haskell's and F#'s) whitespace-oriented ways of doing things, at least until the real world creeps in. I've had problems with early block termination because of mixed tabs and spaces that weren't readily apparent, and the language's toolchain wasn't particularly helpful in diagnosing them, leading me to lean on external tools. (COBOL at least has the heritage of being column-oriented, so indentation being significant is less problematic there.)