10 ms·

Learning from Ada

144 points by rspivak 10y ago

trott 10y ago
IMHO Ada violated the most fundamental principle of programming, which is DRY (Don't repeat yourself). You have to invoke the name of every function twice while defining it, etc. The language seems to be designed for multi-page blocks, which are a bad idea to begin with. It also lacks memory safety, despite being a safety-oriented language. If someone added a better syntax to Ada (probably easy) and Rust-like memory safety (probably hard), that would make it a higher-value proposition. EDIT: There's also an article demonstrating a hole in Ada type safety: http://www.enyo.de/fw/notes/ada-type-safety.html http://www.enyo.de/fw/notes/ada-type-safety.html
- bitwize 10y ago
  I'm a big believer in RYINTBDIMOTB (Repeating Yourself Is Not The Big Deal It's Made Out To Be). In a safety-oriented language, checking for consistency in all of the repeated instances of a thing is one form of low-hanging-fruit safety check. If you're restricting yourself to access types you have good memory safety. Access types cannot be aliased unless declared so, and are subject to accessibility checks to verify that they are "live". Unsafe stuff in Ada must be used explicitly; you cannot, in general, accidentally the whole stack or heap unless you are using a pathological coding style.
  - wyager 10y ago
    > checking for consistency in all of the repeated instances of a thing is one form of low-hanging-fruit safety check. I shouldn't have to make such checks in the first place. Not making a mistake in the first place is preferable to detecting it later on.
    - jacques_chester 10y ago
      > Not making a mistake in the first place is preferable to detecting it later on. Not trying to detect a mistake is a great way to form the impression that you're not making them in the first place.
      - wyager 10y ago
        Perhaps I was not clear. A preferable alternative to detecting mistakes is to ensure that they are impossible to make in the first place.
    - asimuvPR 10y ago
      We should also consider the mistakes of others and runtime errors.
    - bitwize 10y ago
      If you're a human, you make mistakes. It's what you do. Having the compiler check your work for mistakes and flagging them up early is better than letting them slide.
      - wyager 10y ago
        >If you're a human, you make mistakes. Unless you can design your compiler to make a class of mistake impossible, as we were discussing.
- EdwardCoffin 10y ago
  I think there's a huge gulf between repeating oneself with multiple snippets of code which would cause problems if not kept in sync (prone to people changing one without realizing there are others that must be updated too) and merely repeating the name of something at the termination of its definition in addition to naming it at the start. I regard the latter as a species of Poka-yoke [1], and am relatively happy to accept the extremely minor cost of repetition. [1] https://en.wikipedia.org/wiki/Poka-yoke https://en.wikipedia.org/wiki/Poka-yoke
  - 205guy 10y ago
    And Ada's repetition could easily be automated in the IDE or smart editor (does sublime have an Ada-syntax--and I probably don't even need to ask for emacs). The repetition is there for readability and maintainability, so the author loses nothing if it is automated.
- agumonkey 10y ago
  ADA wasn't made for the average human, in large project a DRY means dozens of duplicated content, not just a small name redundancy. For the DOD I'm sure this wasn't even a question.
- dozzie 10y ago
  > IMHO Ada violated the most fundamental principle of programming, which is DRY (Don't repeat yourself). DRY is far from being "most fundamental". Much more fundamental and important are keeping modules composable, not mixing things of different abstraction level in the same block of code, avoiding circular dependencies, or avoiding unnecessary dependencies are more fundamental. DRY is just most easily enforcable, that's why it's so popular.
  - trott 10y ago
    > keeping modules composable, To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition will have made it composable. > not mixing things of different abstraction level in the same block of code Never heard this one, frankly. I happily mix addition (arithmetic, machine-level operation) and, say, Dice Coefficient in the same line of code. > avoiding circular dependencies Probably a good principle, but not fundamental: https://en.wikipedia.org/wiki/Meta-circular_evaluator https://en.wikipedia.org/wiki/Meta-circular_evaluator > avoiding unnecessary dependencies are more fundamental Avoiding anything that's unnecessary is generally a good idea.
    - dozzie 10y ago
      >> keeping modules composable, > To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition will have made it composable. You don't get composability from DRY, as merely extracting common snippet of code into a function doesn't make magically the function easy to put somewhere else. Just "reusing code" doesn't make it composable. You can reuse body of a car for something different, but it doesn't make it composable, so there's no "by definition". DRY is just a different thing than composability. >> not mixing things of different abstraction level in the same block of code > Never heard this one, frankly. I happily mix addition (arithmetic, machine-level operation) and, say, Dice Coefficient in the same line of code. It's a practical thing. You don't put opening TCP connection to a database service in the same chunk of code as building SQL query to be sent through the connection. >> avoiding circular dependencies > Probably a good principle, but not fundamental Oh yes it is. If code doesn't adhere to it, it ends up being a tangled, monolitic mess of brittleness. As with every rule, there are cases when it makes sense not to apply it, but this doesn't make it less fundamental than DRY.
- lobster_johnson 10y ago
  Ada requiring the redundant name after "end" isn't a violation of DRY at all. The DRY principle is about the codebase as a whole, where repetition can lead to elements getting out of sync. For example, instead of having an ORM define a mapping between classes and tables in, say, XML, DRY dictates that the mapping ought to be where it belongs, namely in the class declaration itself. Ada's repetition is really more about readability. If you see an "end", you always knows what it matches. (Personally, I think it's useless.)
  - trott 10y ago
    > Ada requiring the redundant name after "end" isn't a violation of DRY at all. Yours is an arbitrarily narrow interpretation of the principle. To quote Dave Thomas, DRY states that "Every piece of knowledge in the development of something should have a single representation." The name of your function or block is one such piece. I agree that having the compiler check the consistency of the redundant statements ameliorates the situation somewhat, but it would be better if the problem wasn't there at all. [1] http://www.artima.com/intv/dry.html http://www.artima.com/intv/dry.html
    - deleted 10y ago
      [deleted]
    - lobster_johnson 10y ago
      The page you linked to directly refutes your claim of narrowness: Most people take DRY to mean you shouldn't duplicate code. That's not its intention. The idea behind DRY is far grander than that. [...] DRY says that every piece of system knowledge should have one authoritative, unambiguous representation Note the terms knowledge and representation. He's referring to things like declarations, data models, schemas, facts. Duplicate source code symbols has nothing to do with it. DRY is not "be terse". For example, turning a literal into a constant is DRY, because it reduces to a single "authorative, unambiguous representation". But "x = x + 1" (which certainly looks redundant) is not anti-DRY, nor is "end Foo;".
nostrademons 10y ago
"The C compiler made me feel adequate. Unlike Ada, I regularly got my programs to compile. And so, I made my choice and went with C." I think this dynamic plays out in a lot of technology evaluation decisions. It's probably why techs like Javascript, MongoDB, Ruby on Rails, Java, PHP, MySQL, Wordpress, etc. have gotten widespread adoption despite numerous technical flaws. They have a very low barrier to getting something useful up on screen, and feed peoples' need for instant gratification. When you feel good about yourself while using the language, you feel good about the language. The interesting thing about the software industry is that network effects are often so strong that it's rational for a disciplined, expert developer to use one of these technologies rather than something more niche that plays to their expertise. You may hate Java, but if you need to use Hadoop/Storm/SparkML/OpenNLP and the myriad of well-tested libraries, it may be a lot better choice than building your own distributed big-data stack. I guess this is the idea behind "Worse is Better" [1]. It makes me wonder if "better" will ever be "better" (perhaps after the pace of adoption in the software industry slows down, and we start spending time getting known product architectures right rather than finding the next big unknown product architecture), or whether by that time the entrenched base written on top of ad-hoc technologies will be too big to change. [1] https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html
- jakub_h 10y ago
  > It's probably why techs like Javascript, MongoDB, Ruby on Rails, Java, PHP, MySQL, Wordpress, etc. have gotten widespread adoption despite numerous technical flaws. They have a very low barrier to getting something useful up on screen, and feed peoples' need for instant gratification. It might not be just about that. Sometimes you don't know what you're doing, and you have to find out first. What use is it if you painstakingly design and craft a perfectly engineered program, only to find out that you actually needed something else? Being able to experiment is precious. Being forced to handle everything before the thing even compiles is not all that useful at times. There's a reason why interactive environments like Lisp and Smalltalk don't force you to define all functions that could plausibly get called (and when they do get called, you can even add them on the fly and continue).
  - 10y ago
microcolonel 10y ago
Sean misses the irony that he would have given up on writing a lot of software if he tried to do it in Ada rather than C. I think C is an excellent and useful language which doesn't attempt to change the way you program. While one can argue that one shouldn't be able to compile mistakes; the cost of avoiding mistakes often exceeds the cost of amending them. A sort of personal “It's easier to ask for forgiveness than for permission” situation. I often ponder whether the time I spend debugging C programs is worth it. Each time I conclude that I wouldn't have bothered to write it without C.
- PeCaN 10y ago
  It depends what you're writing. I wrote an incremental generational garbage collector in C, and rather regretted the time I spent debugging it. If I wanted it to be at all concurrent, I think I would've given up doing it in C. Right tool for the right job and all that. But lately I've strongly been preferring Rust, Ada, and ATS for anything I'd use C for.
  - microcolonel 10y ago
    Fair enough, I do like ATS as well; but there are a lot of programs which are just too frustrating to write at all without being paid a lot of money for a decade.
- pjmlp 10y ago
  Somehow I managed to write lots of software between 1986 and 1993, the year I used C for the first time with Turbo C 2.0 for MS-DOS. Turbo Basic, Turbo Pascal, Modula-2 did the job just fine.
  - microcolonel 10y ago
    No disagreement here. :-) Turbo Pascal, Turbo BASIC, and Modula-2 don't have any of the ugly formality of Ada though. I'm not making the point that C and C alone is the only language less frustrating than Ada. I'm saying that for many systems, the comfort and simplicity of C allow you to solve problems which would be too frustrating to solve in Ada. I find Modula-2 pretty dreamy; it's a shame that it's mostly dead.
lanestp 10y ago
Ada has a lot of cool stuff going for it. I liked the type system well enough and a well written Ada program is very easy to read. My problem with it was I always had trouble with the stuff like while ... loop if ... then case ... is The number of times that a program failed to compile because I got the magic words wrong drove me nuts! The author is bang on in the comparison to C which despite its flaws is very internally consistent.
- PeCaN 10y ago
  I agree. I've thought of writing a CoffeeScript-for-Ada thing with slightly nicer syntax. (I don't dislike Ada's syntax, but it's occasionally quirkier than necessary.) That said, its easy range types and discriminated unions make writing C-level code SO much nicer.
- david-given 10y ago
  There's actually sense to the magic words. Each word which opens a block has a unique word which ends the block. So, begin..end, if..end if, loop..end loop, etc. The advantage of this is that it's much harder to screw up block terminations --- one thing I've done many times in C is when closing a chain of blocks with: } } } do_something(); } } is to miscount the braces and put do_something() in the wrong place. In Ada, that'd be: end if; end; end case; do_something(); end loop; end; ...which is far more meaningful.
  - user12357z7 10y ago
    You should read about how to write clean code... (instead of switching to another programming language)
    - deleted 10y ago
      [deleted]
  - flukus 10y ago
    That sounds like the cyclomatic complexity is too high.
siscia 10y ago
To me is sound a lot like the internal fight that I am having between rust and go. I already write go professionally but sound like in the long term rust will be a better deal...
qwertyuiop924 10y ago
I don't think a tool has to be hard to use to be better. You can learn most of Lisp and Smalltalk very fast, but they're regarded as some of the most useful and effective tools out there.
- sportanova 10y ago
  How does smalltalk compare to objective-c? It's on my list of languages to learn because it started with message passing, but if it's user experience is as bad as objective-c I might pass
  - qwertyuiop924 10y ago
    It depends on how you think objective-c's UX is bad. Smalltalk's syntax is much simpler than O-C's. It has three message passing formats: object message. object + arg. "There are very few valid names for these sorts of messages" object argNameOne: argOne argNameTwo: argTwo. Double quote is a comment, period is the statement delineator, and semicolon is the cascade operator, allowing you to send multiple messages to one object. It has a block (or lambda) syntax similar to Ruby's, although multiple blocks can be passed to a function. This is pretty much all of SmallTalk's synax. Yes, really. There's also syntax for local variables, and returning values from method calls, and maybe one or two other things. That's it. It should also be noted that Smalltalk is inseparable from its IDE and image. GNU Smalltalk tries, but it's not the same. To speak of one is to speak of the other, so I shall speak of both. Smalltalk code exists entirely within its image, along with all the tools that make up the IDE. It's sort of an OS in and of itself, although you can interact with the native system. The practical upshot is that when you edit smalltalk code, you have all the source code for the entire implementation along for the ride: You can not only query Smalltalk about your own code, you can query it about itself using the same mechanism. You can also edit and debug your app in real time, as it runs. Smalltalk's debugger allows to to inspect every single stack frame, and make changes to your source as necessary. You aren't editing text that will become objects: You are editing objects. And because the entire system state is saved to the image, none of the changes you make to the running code will be lost, unlike most Lisps, where changes you make at the REPL go away as soon as your app shuts down. It's truly unlike anything else you will see.
opk 10y ago
I worked with Ada in the early part of my career. For the most part, the strong typing really helps but it can often make the logic messier that you can't push an integer subtype one past the maximum value. Unlike C, the code base tends to remain quite readable and understandable even in big projects and it is more fun to use than Java (which I find to be soulless and dull).
- 35bge57dtjku 10y ago
  How is it more fun than Java???
  - na85 10y ago
    Anything is more fun than java.
leoh 10y ago
I loved this article. I never knew about Userland Frontier Kernel and enjoyed looking it up. I also enjoyed other bits of history sprinkled in the article especially about Macintosh switching from Pascal to C and about what it was like to use the Ada and Pascal compilers. The author's central argument is "don't give up on a language that's hard because it might have significant, practical advantages." In particular, he argues that Ada might be superior to C because C suffers from segfaults or other memory-related issues that Ada does not suffer from. Because C was initially easier to write, he went with it. I think this principle — that it is worth sticking with a language despite difficulty in writing it — is flawed. While Ada was both difficult and resolved memory issues, languages like Python graceful avoid memory issues without being difficult to write. Naturally, language safety is greater than ensuring memory integrity. Haskell ensures memory integrity and type safety and happens to be a hard language. I think that Haskell is a stepping stone. That in the future, languages will be safer, but also easier to write. That we haven't solved this paradox — that a language can be both safe and easy to use — is merely a matter of time. For now, I'll keep writing Python.
- JohnStrange 10y ago
  Ada is fairly easy to use once you know it. It has a few quirks and many nice features. It just takes a bit more time to learn, because its way more strongly typed than most other languages. IMHO, its main advantage is not safety, though, but readability and long-term maintainability. You can take a 30 year old Ada program and compile it with the latest version of GNAT. Anyway, please don't compare languages like Ada and Python. That's like comparing Forth and Smalltalk or apples with oranges. They have different purposes. Ada compiles to executables that run around as fast as C and C++, and like those languages it's not very suitable for rapid lego-brick type programming. For gluing together existing libraries, languages like Python are awesome but you wouldn't want to write an Operating System in Python.
  - icebraining 10y ago
    You can compile any Python program to C using Cython, hence Python is as fast as C.
voycey 10y ago
I was taught Ada at university, it is a complete bitch of a language but it forces you to be disciplined and do things "Properly" - something that is crucial in real-time systems. I don't regret being taught it, I do however regret that it was used as the main teaching language meaning that real world usage was an after thought!
Marazan 10y ago
Ada is a large verbose language where the verbosity actually gives you something (unlike, say, late nineties Java).
Annatar 10y ago
And now whenever I encounter a difficult moment learning new languages like Haskell or Pony, I try to remember my Ada/C decision and stick will the language whose compiler is trying to tell me I'm doing it wrong. What this tells me is that the author gained some insight, but still did not learn his lesson: one of the worst mistakes one can make in programming is learning new languages, just because they are there. Pick at most three languages covering 95-99% of required functionality, then master the living daylights out of them; you'll become seemingly superhuman at programming, writing small, portable code in fraction of the time it will take dingle-dongs out there to do the same thing. Just because you know your tools so well. To be clear: it takes about a decade working in a language every day, eight hours per day, to begin to master it. So that's per language, and I wrote pick three languages. Don't cater to fashion, because there is always some dingle-dong out there thinking he can invent a new language where things can be done easier and better, but that's not true at all.

144 points by rspivak 10y ago

trott 10y ago

IMHO Ada violated the most fundamental principle of programming, which is DRY (Don't repeat yourself). You have to invoke the name of every function twice while defining it, etc. The language seems to be designed for multi-page blocks, which are a bad idea to begin with. It also lacks memory safety, despite being a safety-oriented language. If someone added a better syntax to Ada (probably easy) and Rust-like memory safety (probably hard), that would make it a higher-value proposition. EDIT: There's also an article demonstrating a hole in Ada type safety: http://www.enyo.de/fw/notes/ada-type-safety.html http://www.enyo.de/fw/notes/ada-type-safety.html

bitwize 10y ago
I'm a big believer in RYINTBDIMOTB (Repeating Yourself Is Not The Big Deal It's Made Out To Be). In a safety-oriented language, checking for consistency in all of the repeated instances of a thing is one form of low-hanging-fruit safety check. If you're restricting yourself to access types you have good memory safety. Access types cannot be aliased unless declared so, and are subject to accessibility checks to verify that they are "live". Unsafe stuff in Ada must be used explicitly; you cannot, in general, accidentally the whole stack or heap unless you are using a pathological coding style.
- wyager 10y ago
  > checking for consistency in all of the repeated instances of a thing is one form of low-hanging-fruit safety check. I shouldn't have to make such checks in the first place. Not making a mistake in the first place is preferable to detecting it later on.
  - jacques_chester 10y ago
    > Not making a mistake in the first place is preferable to detecting it later on. Not trying to detect a mistake is a great way to form the impression that you're not making them in the first place.
    - wyager 10y ago
      Perhaps I was not clear. A preferable alternative to detecting mistakes is to ensure that they are impossible to make in the first place.
  - asimuvPR 10y ago
    We should also consider the mistakes of others and runtime errors.
  - bitwize 10y ago
    If you're a human, you make mistakes. It's what you do. Having the compiler check your work for mistakes and flagging them up early is better than letting them slide.
    - wyager 10y ago
      >If you're a human, you make mistakes. Unless you can design your compiler to make a class of mistake impossible, as we were discussing.
EdwardCoffin 10y ago
I think there's a huge gulf between repeating oneself with multiple snippets of code which would cause problems if not kept in sync (prone to people changing one without realizing there are others that must be updated too) and merely repeating the name of something at the termination of its definition in addition to naming it at the start. I regard the latter as a species of Poka-yoke [1], and am relatively happy to accept the extremely minor cost of repetition. [1] https://en.wikipedia.org/wiki/Poka-yoke https://en.wikipedia.org/wiki/Poka-yoke
- 205guy 10y ago
  And Ada's repetition could easily be automated in the IDE or smart editor (does sublime have an Ada-syntax--and I probably don't even need to ask for emacs). The repetition is there for readability and maintainability, so the author loses nothing if it is automated.
agumonkey 10y ago
ADA wasn't made for the average human, in large project a DRY means dozens of duplicated content, not just a small name redundancy. For the DOD I'm sure this wasn't even a question.
dozzie 10y ago
> IMHO Ada violated the most fundamental principle of programming, which is DRY (Don't repeat yourself). DRY is far from being "most fundamental". Much more fundamental and important are keeping modules composable, not mixing things of different abstraction level in the same block of code, avoiding circular dependencies, or avoiding unnecessary dependencies are more fundamental. DRY is just most easily enforcable, that's why it's so popular.
- trott 10y ago
  > keeping modules composable, To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition will have made it composable. > not mixing things of different abstraction level in the same block of code Never heard this one, frankly. I happily mix addition (arithmetic, machine-level operation) and, say, Dice Coefficient in the same line of code. > avoiding circular dependencies Probably a good principle, but not fundamental: https://en.wikipedia.org/wiki/Meta-circular_evaluator https://en.wikipedia.org/wiki/Meta-circular_evaluator > avoiding unnecessary dependencies are more fundamental Avoiding anything that's unnecessary is generally a good idea.
  - dozzie 10y ago
    >> keeping modules composable, > To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition will have made it composable. You don't get composability from DRY, as merely extracting common snippet of code into a function doesn't make magically the function easy to put somewhere else. Just "reusing code" doesn't make it composable. You can reuse body of a car for something different, but it doesn't make it composable, so there's no "by definition". DRY is just a different thing than composability. >> not mixing things of different abstraction level in the same block of code > Never heard this one, frankly. I happily mix addition (arithmetic, machine-level operation) and, say, Dice Coefficient in the same line of code. It's a practical thing. You don't put opening TCP connection to a database service in the same chunk of code as building SQL query to be sent through the connection. >> avoiding circular dependencies > Probably a good principle, but not fundamental Oh yes it is. If code doesn't adhere to it, it ends up being a tangled, monolitic mess of brittleness. As with every rule, there are cases when it makes sense not to apply it, but this doesn't make it less fundamental than DRY.
lobster_johnson 10y ago
Ada requiring the redundant name after "end" isn't a violation of DRY at all. The DRY principle is about the codebase as a whole, where repetition can lead to elements getting out of sync. For example, instead of having an ORM define a mapping between classes and tables in, say, XML, DRY dictates that the mapping ought to be where it belongs, namely in the class declaration itself. Ada's repetition is really more about readability. If you see an "end", you always knows what it matches. (Personally, I think it's useless.)
- trott 10y ago
  > Ada requiring the redundant name after "end" isn't a violation of DRY at all. Yours is an arbitrarily narrow interpretation of the principle. To quote Dave Thomas, DRY states that "Every piece of knowledge in the development of something should have a single representation." The name of your function or block is one such piece. I agree that having the compiler check the consistency of the redundant statements ameliorates the situation somewhat, but it would be better if the problem wasn't there at all. [1] http://www.artima.com/intv/dry.html http://www.artima.com/intv/dry.html
  - deleted 10y ago
    [deleted]
  - lobster_johnson 10y ago
    The page you linked to directly refutes your claim of narrowness: Most people take DRY to mean you shouldn't duplicate code. That's not its intention. The idea behind DRY is far grander than that. [...] DRY says that every piece of system knowledge should have one authoritative, unambiguous representation Note the terms knowledge and representation. He's referring to things like declarations, data models, schemas, facts. Duplicate source code symbols has nothing to do with it. DRY is not "be terse". For example, turning a literal into a constant is DRY, because it reduces to a single "authorative, unambiguous representation". But "x = x + 1" (which certainly looks redundant) is not anti-DRY, nor is "end Foo;".

nostrademons 10y ago

"The C compiler made me feel adequate. Unlike Ada, I regularly got my programs to compile. And so, I made my choice and went with C." I think this dynamic plays out in a lot of technology evaluation decisions. It's probably why techs like Javascript, MongoDB, Ruby on Rails, Java, PHP, MySQL, Wordpress, etc. have gotten widespread adoption despite numerous technical flaws. They have a very low barrier to getting something useful up on screen, and feed peoples' need for instant gratification. When you feel good about yourself while using the language, you feel good about the language. The interesting thing about the software industry is that network effects are often so strong that it's rational for a disciplined, expert developer to use one of these technologies rather than something more niche that plays to their expertise. You may hate Java, but if you need to use Hadoop/Storm/SparkML/OpenNLP and the myriad of well-tested libraries, it may be a lot better choice than building your own distributed big-data stack. I guess this is the idea behind "Worse is Better" [1]. It makes me wonder if "better" will ever be "better" (perhaps after the pace of adoption in the software industry slows down, and we start spending time getting known product architectures right rather than finding the next big unknown product architecture), or whether by that time the entrenched base written on top of ad-hoc technologies will be too big to change. [1] https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html

jakub_h 10y ago
> It's probably why techs like Javascript, MongoDB, Ruby on Rails, Java, PHP, MySQL, Wordpress, etc. have gotten widespread adoption despite numerous technical flaws. They have a very low barrier to getting something useful up on screen, and feed peoples' need for instant gratification. It might not be just about that. Sometimes you don't know what you're doing, and you have to find out first. What use is it if you painstakingly design and craft a perfectly engineered program, only to find out that you actually needed something else? Being able to experiment is precious. Being forced to handle everything before the thing even compiles is not all that useful at times. There's a reason why interactive environments like Lisp and Smalltalk don't force you to define all functions that could plausibly get called (and when they do get called, you can even add them on the fly and continue).
- 10y ago

microcolonel 10y ago

Sean misses the irony that he would have given up on writing a lot of software if he tried to do it in Ada rather than C. I think C is an excellent and useful language which doesn't attempt to change the way you program. While one can argue that one shouldn't be able to compile mistakes; the cost of avoiding mistakes often exceeds the cost of amending them. A sort of personal “It's easier to ask for forgiveness than for permission” situation. I often ponder whether the time I spend debugging C programs is worth it. Each time I conclude that I wouldn't have bothered to write it without C.

PeCaN 10y ago
It depends what you're writing. I wrote an incremental generational garbage collector in C, and rather regretted the time I spent debugging it. If I wanted it to be at all concurrent, I think I would've given up doing it in C. Right tool for the right job and all that. But lately I've strongly been preferring Rust, Ada, and ATS for anything I'd use C for.
- microcolonel 10y ago
  Fair enough, I do like ATS as well; but there are a lot of programs which are just too frustrating to write at all without being paid a lot of money for a decade.
pjmlp 10y ago
Somehow I managed to write lots of software between 1986 and 1993, the year I used C for the first time with Turbo C 2.0 for MS-DOS. Turbo Basic, Turbo Pascal, Modula-2 did the job just fine.
- microcolonel 10y ago
  No disagreement here. :-) Turbo Pascal, Turbo BASIC, and Modula-2 don't have any of the ugly formality of Ada though. I'm not making the point that C and C alone is the only language less frustrating than Ada. I'm saying that for many systems, the comfort and simplicity of C allow you to solve problems which would be too frustrating to solve in Ada. I find Modula-2 pretty dreamy; it's a shame that it's mostly dead.

lanestp 10y ago

Ada has a lot of cool stuff going for it. I liked the type system well enough and a well written Ada program is very easy to read. My problem with it was I always had trouble with the stuff like while ... loop if ... then case ... is The number of times that a program failed to compile because I got the magic words wrong drove me nuts! The author is bang on in the comparison to C which despite its flaws is very internally consistent.

PeCaN 10y ago
I agree. I've thought of writing a CoffeeScript-for-Ada thing with slightly nicer syntax. (I don't dislike Ada's syntax, but it's occasionally quirkier than necessary.) That said, its easy range types and discriminated unions make writing C-level code SO much nicer.
david-given 10y ago
There's actually sense to the magic words. Each word which opens a block has a unique word which ends the block. So, begin..end, if..end if, loop..end loop, etc. The advantage of this is that it's much harder to screw up block terminations --- one thing I've done many times in C is when closing a chain of blocks with: } } } do_something(); } } is to miscount the braces and put do_something() in the wrong place. In Ada, that'd be: end if; end; end case; do_something(); end loop; end; ...which is far more meaningful.
- user12357z7 10y ago
  You should read about how to write clean code... (instead of switching to another programming language)
  - deleted 10y ago
    [deleted]
- flukus 10y ago
  That sounds like the cyclomatic complexity is too high.

siscia 10y ago

To me is sound a lot like the internal fight that I am having between rust and go. I already write go professionally but sound like in the long term rust will be a better deal...

qwertyuiop924 10y ago

I don't think a tool has to be hard to use to be better. You can learn most of Lisp and Smalltalk very fast, but they're regarded as some of the most useful and effective tools out there.

sportanova 10y ago
How does smalltalk compare to objective-c? It's on my list of languages to learn because it started with message passing, but if it's user experience is as bad as objective-c I might pass
- qwertyuiop924 10y ago
  It depends on how you think objective-c's UX is bad. Smalltalk's syntax is much simpler than O-C's. It has three message passing formats: object message. object + arg. "There are very few valid names for these sorts of messages" object argNameOne: argOne argNameTwo: argTwo. Double quote is a comment, period is the statement delineator, and semicolon is the cascade operator, allowing you to send multiple messages to one object. It has a block (or lambda) syntax similar to Ruby's, although multiple blocks can be passed to a function. This is pretty much all of SmallTalk's synax. Yes, really. There's also syntax for local variables, and returning values from method calls, and maybe one or two other things. That's it. It should also be noted that Smalltalk is inseparable from its IDE and image. GNU Smalltalk tries, but it's not the same. To speak of one is to speak of the other, so I shall speak of both. Smalltalk code exists entirely within its image, along with all the tools that make up the IDE. It's sort of an OS in and of itself, although you can interact with the native system. The practical upshot is that when you edit smalltalk code, you have all the source code for the entire implementation along for the ride: You can not only query Smalltalk about your own code, you can query it about itself using the same mechanism. You can also edit and debug your app in real time, as it runs. Smalltalk's debugger allows to to inspect every single stack frame, and make changes to your source as necessary. You aren't editing text that will become objects: You are editing objects. And because the entire system state is saved to the image, none of the changes you make to the running code will be lost, unlike most Lisps, where changes you make at the REPL go away as soon as your app shuts down. It's truly unlike anything else you will see.

opk 10y ago

I worked with Ada in the early part of my career. For the most part, the strong typing really helps but it can often make the logic messier that you can't push an integer subtype one past the maximum value. Unlike C, the code base tends to remain quite readable and understandable even in big projects and it is more fun to use than Java (which I find to be soulless and dull).

35bge57dtjku 10y ago
How is it more fun than Java???
- na85 10y ago
  Anything is more fun than java.

leoh 10y ago

I loved this article. I never knew about Userland Frontier Kernel and enjoyed looking it up. I also enjoyed other bits of history sprinkled in the article especially about Macintosh switching from Pascal to C and about what it was like to use the Ada and Pascal compilers. The author's central argument is "don't give up on a language that's hard because it might have significant, practical advantages." In particular, he argues that Ada might be superior to C because C suffers from segfaults or other memory-related issues that Ada does not suffer from. Because C was initially easier to write, he went with it. I think this principle — that it is worth sticking with a language despite difficulty in writing it — is flawed. While Ada was both difficult and resolved memory issues, languages like Python graceful avoid memory issues without being difficult to write. Naturally, language safety is greater than ensuring memory integrity. Haskell ensures memory integrity and type safety and happens to be a hard language. I think that Haskell is a stepping stone. That in the future, languages will be safer, but also easier to write. That we haven't solved this paradox — that a language can be both safe and easy to use — is merely a matter of time. For now, I'll keep writing Python.

JohnStrange 10y ago
Ada is fairly easy to use once you know it. It has a few quirks and many nice features. It just takes a bit more time to learn, because its way more strongly typed than most other languages. IMHO, its main advantage is not safety, though, but readability and long-term maintainability. You can take a 30 year old Ada program and compile it with the latest version of GNAT. Anyway, please don't compare languages like Ada and Python. That's like comparing Forth and Smalltalk or apples with oranges. They have different purposes. Ada compiles to executables that run around as fast as C and C++, and like those languages it's not very suitable for rapid lego-brick type programming. For gluing together existing libraries, languages like Python are awesome but you wouldn't want to write an Operating System in Python.
- icebraining 10y ago
  You can compile any Python program to C using Cython, hence Python is as fast as C.

voycey 10y ago

I was taught Ada at university, it is a complete bitch of a language but it forces you to be disciplined and do things "Properly" - something that is crucial in real-time systems. I don't regret being taught it, I do however regret that it was used as the main teaching language meaning that real world usage was an after thought!

Marazan 10y ago

Ada is a large verbose language where the verbosity actually gives you something (unlike, say, late nineties Java).

Annatar 10y ago

And now whenever I encounter a difficult moment learning new languages like Haskell or Pony, I try to remember my Ada/C decision and stick will the language whose compiler is trying to tell me I'm doing it wrong. What this tells me is that the author gained some insight, but still did not learn his lesson: one of the worst mistakes one can make in programming is learning new languages, just because they are there. Pick at most three languages covering 95-99% of required functionality, then master the living daylights out of them; you'll become seemingly superhuman at programming, writing small, portable code in fraction of the time it will take dingle-dongs out there to do the same thing. Just because you know your tools so well. To be clear: it takes about a decade working in a language every day, eight hours per day, to begin to master it. So that's per language, and I wrote pick three languages. Don't cater to fashion, because there is always some dingle-dong out there thinking he can invent a new language where things can be done easier and better, but that's not true at all.