5 ms·

I learned Ada because I took a new job back in 2008 (at Boeing, doing spacecraft modeling and simulation) and discovered on my first day that I would be using A

by jcadam 8y ago

I learned Ada because I took a new job back in 2008 (at Boeing, doing spacecraft modeling and simulation) and discovered on my first day that I would be using Ada. Naturally, I was expected to just pick it up on my own (Not complaining, that's pretty much how it goes these days). My mother (who found it amusing I was going to be coding Ada in 2008) gave me her old Ada books from the 80s (her employer at the time sent her to an actual course to learn the new DoD mandated language, back in the days when employers invested in their people), which I still have. I ended up programming in Ada up until 2012, when I managed to get a job using Java. The language itself I rather liked (better than Java, for sure). It's the only language I've ever used that tended to produce programs that worked correctly on their first run (getting them to compile was the difficult part). The aerospace industry OTOH, I don't miss.

majewsky 8y ago
> It's the only language I've ever used that tended to produce programs that worked correctly on their first run I've had the same experience with Rust. (Never used Ada/Spark myself.)
bibyte 8y ago
> It's the only language I've ever used that tended to produce programs that worked correctly on their first run From my experience that is generally true with languages that have strong static type systems (like Haskell and Rust).
- syrrim 8y ago
  From my experience it's true in python (ie not a static type system). Removing the distinction between compiling and running makes this point even stronger.
  - 59nadir 8y ago
    This is not at all my experience, neither with my own code or code other people produce. Unless the problem is extremely trivial the solution is very unlikely to work without a few test runs. The bigger point in all of this is that statically typed languages at least have some kind of check mark they can put on your code to say "Yeah, at least the types make sense". They also encourage designing with types in order to enforce business logic, which is something you don't get in any of the dynamic languages.
    - randomsearch 8y ago
      Agreed. Have written a lot of code in Ada and Python, I have taught both of them. The fact that Ada code often works first time is something almost every student notices at some point. I have far more experience in Python, and I don’t think I’ve ever made non-trivial code work the first time.
  - j88439h84 8y ago
    In python this can be true, if you invest in the various protections like pylint, mypy, and full test coverage. Python doesn't force you to do those things if you dont need the reliability for a prototype or one-off code. But if you want to make a reliable system, even convert your prototype into a reliable system, you can.
- kazinator 8y ago
  The trick is to produce programs that also run correctly on their second and third run, and multiple other runs where the user is someone other than the creator with different ideas for the inputs. There isn't anything special about the first run, other than emotionally. Also, if we define "run" as everything that happens when you feed that source program to the machine, then your first run actually bombed with compile errors. You can't sit there pretending that the compile errors are the only mistakes you made, such that your first compile-error-free run that made it all the way to program startup and through to successful termination is also bug-free. If you were that good, you wouldn't be making trivial errors flagged by a compiler.
- eeZah7Ux 8y ago
  Scientific research on the source of bugs shows that type-related bugs are a minority.
  - OneWingedShark 8y ago
    Well, there's a bit of a problem in how you're qualifying things. For example, certain things that aren't obviously handled by the type-system might be. One example would be loops and off-by-one errors. For the case of For-loops on arrays Ada's solution arguably does so via the type-system; in Ada arrays "know" their own length, start- and stop-index and these are query-able via attributes. So, given Function Sum( Input : Integer_Array ) return Long_Long_Integer you could for-loop on the parameter, querying the 'Range attribute -- yielding a possible implementation of: Function Sum( Input : Integer_Array ) return Long_Long_Integer is Begin Return Result : Long_Long_Integer := 0 do For Index in Input'Range loop Sum:= Sum + Long_Long_Integer( Input(Index) ); End Loop; end return; End Sum; And the entire problem is avoided via the type-system.
  - kqr 8y ago
    That is a reflection on which language you use. I prefer a language where a large majority of bugs are type-related. How about you?
ainar-g 8y ago
The aerospace industry OTOH, I don't miss. At least three people ITT have said something similar to this. Can you elaborate about what is so bad about working as a software developer in the aerospace industry? Or would that require breaking all sorts of NDAs?
- acomjean 8y ago
  I worked in defense for 10 years then left. I'm assuming its similar to the defense industry I guess (Radar and we were a Boeing sub contractor). There a few things I don't miss: 1) It can be a little stressful, knowing that your software is controlling things that if wrong could go bad (people's lives are at stake). The strong process we had makes you abstract that away, but still its serious work. 2) Yesterdays technology tomorrow. We were using stable releases from years ago on hardware I couldn't buy in a a language hardly anyone uses (we were an Ada/C shop). I do like Ada, but it made it harder for employees let go to find new work. it was somewhat satisfying when the end result got built and it was operational. My software probably running today, somewhere. Even though I left a while ago.
  - Jtsummers 8y ago
    I have a few more points but yours are a good start. It's software work run by hardware companies. They don't schedule or budget or staff correctly. They often put engineers (of any sort) into decision making positions that should belong to computer scientists (or at least those trained in programming). Writing software is often treated as "just typing" when it's really an engineering and design activity. Waterfall is also pervasive as a project management methodology. Even "modified Waterfall" (Vee model and others) are still subpar. What's frustrating is that, on the physical engineering side, they actually get the idea and value of prototypes and iterative development/design. But back to my first point, they still view software writing as a manufacturing activity, and not a design activity. So software shops get compared to the production line and not the engineering offices. Regarding 2: Oh man, yeah. We've got people straight of school stuck on projects written in JOVIAL. Literally put them into a dead-end job straight out of school, we can't retain them. And we don't have the money (from customers) to hire the old timers, they're enjoying retirement too much.
sanxiyn 8y ago
Comment on training, comparing 80s and now, rings so true. Shame on Boeing.
- bpyne 8y ago
  It's not just Boeing, though. Formal training, at least in my limited perspective, is seen as a luxury now. A related point is that training used to signify a ramp up time for an employee with an unfamiliar technology. Employees didn't go onto projects until they passed through a training course. Companies now expect zero ramp up time. Hence, they pass over highly qualified software engineers, who may not have a lot of experience in a particular technology, to get less experienced engineers who don't need training in the technology.
coldtea 8y ago
>My mother (who found it amusing I was going to be coding Ada in 2008) gave me her old Ada books from the 80s (her employer at the time sent her to an actual course to learn the new DoD mandated language, back in the days when employers invested in their people), which I still have. The fact that most employees don't invest in their people today, is egregious. The fact that an employer like Boeing lets their developers "just pick it up on their own" doubly so. And probably explains some of their quality issues.
- 4thaccount 8y ago
  This quote from the parent comment made me sad because it is true. With that being said, why is this so? Is it because the internet learning makes it possible to not need training classes to learn a language like you once did? Would the poster's mother prefer a week long off site course led by instructor or going through learnadacore.com (or whatever) at her own pace?
  - Jtsummers 8y ago
    Companies used to invest in their workers, there was an assumption (reasonably accurate for many employers and employees) that people would remain with a company for decades. It was to their benefit to train and improve the employees (NB: Layoffs and other things still happened, not claiming this was a golden age, just different). At some point (1980s and 1990s in particular) things like retirement benefits started disappearing, replaced by 401k contributions and the like. Employees started moving more between companies so that long-term investment in employees became a problem. If I'm an employer and I spend 3 years getting you the equivalent of a graduate degree in software engineering (training on best practices, training in languages and design, attending conferences) and then you move, I have nothing to show for my effort. You could add clauses requiring people to work for some period of time after receiving specific kind of training (like if you pay them for a degree) or requiring them to reimburse you if they leave early. But you can't do that for everything. So companies have assumed that employees are mercenaries, and employees have become mercenaries. In the end, we still work 40+ hour weeks, but get worse compensation and companies refuse to invest in us.

by jcadam 8y ago

majewsky 8y ago

> It's the only language I've ever used that tended to produce programs that worked correctly on their first run I've had the same experience with Rust. (Never used Ada/Spark myself.)

bibyte 8y ago

> It's the only language I've ever used that tended to produce programs that worked correctly on their first run From my experience that is generally true with languages that have strong static type systems (like Haskell and Rust).

syrrim 8y ago
From my experience it's true in python (ie not a static type system). Removing the distinction between compiling and running makes this point even stronger.
- 59nadir 8y ago
  This is not at all my experience, neither with my own code or code other people produce. Unless the problem is extremely trivial the solution is very unlikely to work without a few test runs. The bigger point in all of this is that statically typed languages at least have some kind of check mark they can put on your code to say "Yeah, at least the types make sense". They also encourage designing with types in order to enforce business logic, which is something you don't get in any of the dynamic languages.
  - randomsearch 8y ago
    Agreed. Have written a lot of code in Ada and Python, I have taught both of them. The fact that Ada code often works first time is something almost every student notices at some point. I have far more experience in Python, and I don’t think I’ve ever made non-trivial code work the first time.
- j88439h84 8y ago
  In python this can be true, if you invest in the various protections like pylint, mypy, and full test coverage. Python doesn't force you to do those things if you dont need the reliability for a prototype or one-off code. But if you want to make a reliable system, even convert your prototype into a reliable system, you can.
kazinator 8y ago
The trick is to produce programs that also run correctly on their second and third run, and multiple other runs where the user is someone other than the creator with different ideas for the inputs. There isn't anything special about the first run, other than emotionally. Also, if we define "run" as everything that happens when you feed that source program to the machine, then your first run actually bombed with compile errors. You can't sit there pretending that the compile errors are the only mistakes you made, such that your first compile-error-free run that made it all the way to program startup and through to successful termination is also bug-free. If you were that good, you wouldn't be making trivial errors flagged by a compiler.
eeZah7Ux 8y ago
Scientific research on the source of bugs shows that type-related bugs are a minority.
- OneWingedShark 8y ago
  Well, there's a bit of a problem in how you're qualifying things. For example, certain things that aren't obviously handled by the type-system might be. One example would be loops and off-by-one errors. For the case of For-loops on arrays Ada's solution arguably does so via the type-system; in Ada arrays "know" their own length, start- and stop-index and these are query-able via attributes. So, given Function Sum( Input : Integer_Array ) return Long_Long_Integer you could for-loop on the parameter, querying the 'Range attribute -- yielding a possible implementation of: Function Sum( Input : Integer_Array ) return Long_Long_Integer is Begin Return Result : Long_Long_Integer := 0 do For Index in Input'Range loop Sum:= Sum + Long_Long_Integer( Input(Index) ); End Loop; end return; End Sum; And the entire problem is avoided via the type-system.
- kqr 8y ago
  That is a reflection on which language you use. I prefer a language where a large majority of bugs are type-related. How about you?

ainar-g 8y ago

The aerospace industry OTOH, I don't miss. At least three people ITT have said something similar to this. Can you elaborate about what is so bad about working as a software developer in the aerospace industry? Or would that require breaking all sorts of NDAs?

acomjean 8y ago
I worked in defense for 10 years then left. I'm assuming its similar to the defense industry I guess (Radar and we were a Boeing sub contractor). There a few things I don't miss: 1) It can be a little stressful, knowing that your software is controlling things that if wrong could go bad (people's lives are at stake). The strong process we had makes you abstract that away, but still its serious work. 2) Yesterdays technology tomorrow. We were using stable releases from years ago on hardware I couldn't buy in a a language hardly anyone uses (we were an Ada/C shop). I do like Ada, but it made it harder for employees let go to find new work. it was somewhat satisfying when the end result got built and it was operational. My software probably running today, somewhere. Even though I left a while ago.
- Jtsummers 8y ago
  I have a few more points but yours are a good start. It's software work run by hardware companies. They don't schedule or budget or staff correctly. They often put engineers (of any sort) into decision making positions that should belong to computer scientists (or at least those trained in programming). Writing software is often treated as "just typing" when it's really an engineering and design activity. Waterfall is also pervasive as a project management methodology. Even "modified Waterfall" (Vee model and others) are still subpar. What's frustrating is that, on the physical engineering side, they actually get the idea and value of prototypes and iterative development/design. But back to my first point, they still view software writing as a manufacturing activity, and not a design activity. So software shops get compared to the production line and not the engineering offices. Regarding 2: Oh man, yeah. We've got people straight of school stuck on projects written in JOVIAL. Literally put them into a dead-end job straight out of school, we can't retain them. And we don't have the money (from customers) to hire the old timers, they're enjoying retirement too much.

sanxiyn 8y ago

Comment on training, comparing 80s and now, rings so true. Shame on Boeing.

bpyne 8y ago
It's not just Boeing, though. Formal training, at least in my limited perspective, is seen as a luxury now. A related point is that training used to signify a ramp up time for an employee with an unfamiliar technology. Employees didn't go onto projects until they passed through a training course. Companies now expect zero ramp up time. Hence, they pass over highly qualified software engineers, who may not have a lot of experience in a particular technology, to get less experienced engineers who don't need training in the technology.

coldtea 8y ago

>My mother (who found it amusing I was going to be coding Ada in 2008) gave me her old Ada books from the 80s (her employer at the time sent her to an actual course to learn the new DoD mandated language, back in the days when employers invested in their people), which I still have. The fact that most employees don't invest in their people today, is egregious. The fact that an employer like Boeing lets their developers "just pick it up on their own" doubly so. And probably explains some of their quality issues.

4thaccount 8y ago
This quote from the parent comment made me sad because it is true. With that being said, why is this so? Is it because the internet learning makes it possible to not need training classes to learn a language like you once did? Would the poster's mother prefer a week long off site course led by instructor or going through learnadacore.com (or whatever) at her own pace?
- Jtsummers 8y ago
  Companies used to invest in their workers, there was an assumption (reasonably accurate for many employers and employees) that people would remain with a company for decades. It was to their benefit to train and improve the employees (NB: Layoffs and other things still happened, not claiming this was a golden age, just different). At some point (1980s and 1990s in particular) things like retirement benefits started disappearing, replaced by 401k contributions and the like. Employees started moving more between companies so that long-term investment in employees became a problem. If I'm an employer and I spend 3 years getting you the equivalent of a graduate degree in software engineering (training on best practices, training in languages and design, attending conferences) and then you move, I have nothing to show for my effort. You could add clauses requiring people to work for some period of time after receiving specific kind of training (like if you pay them for a degree) or requiring them to reimburse you if they leave early. But you can't do that for everything. So companies have assumed that employees are mercenaries, and employees have become mercenaries. In the end, we still work 40+ hour weeks, but get worse compensation and companies refuse to invest in us.