I do a daily writing exercise that is to write at least 1000 words, whatever comes to mind. No editing. Just let it flow and see where it takes you. When you get used to it (which you will do very quick) you will be surprised how it improves your writing skills.
You absolutely do not have the best behind you! My bug "turnaround" came in the beginning of mt 50ies. Finally got to a stage in job life I like and also meet the woman of my life (after many years as single) and got married. I still feel that I haven't had the best yet when it come to job life and I plan to continue at least 20+ years working and have no plans of retirement. Today it make no sense at all to think about age, just keep up your motivation, drive and stay healthy and you can go on "forever". Find out what you really want to do and do it. There are no limits here in life
"Also, Ada’s strictness and correctness may be perceived as an anti-feature. When talking about general-purpose programming, businesses need fast development cycles and short delivery times. For the companies, to be successful, it’s far more important to be ahead of the competition even with an incomplete product than to let the customers wait and eventually abandon the project."
That is not necessary true when it comes to aerospace and defense projects. In these cases it not important to be ahead and have short delivery times, so here Ada is still suitable.
That the language is a general-purpose programming language does not mean that it is suitable for all application domains. You always need to use your common sense and experience too to choose the right tool for your task.
That is not necessary true when it comes to aerospace and defense projects
They chose to use C++ for the F35, which is buggy as hell, because they thought there were no Ada programmers available. But if you are planning a multi-decade project wouldn't you just... train some yourself?
Points to a general problem (in the US at least) of a complete failure of any sense of on the job training, or internal advancement.
Companies complain when they can't find purple squirrels, even where they could find someone with great general skills in the profession and train them, in about the same amount of time it takes to onboard someone with precisely the skills you want.
Let's say you get a job offer from a company which the worst case of NIH syndrome you've ever seen, and all their code is written in a programming language that the company created and the only code in the world written in this language is at this company. Even if the company agreed to train you, would you take the job offer?
Chances are, no, because if you were to ever switch jobs in the future, you want to still be employable, and not have invested years and years into a stack that's completely irrelevant to the rest of the world.
So if the company is of such a literally enormous size and permanent standing to be able to make you a believable offer of lifetime employment / tenure for learning their untransferable skills, like a military or other government body, then maybe. For a defense contractor which could go belly up after some upper-management scandal? No way. For anybody else in the private sector? No way.
Either way, it's still problematic because your hiring mechnanics now revolve around unfirable employees, and the easiest way to demotivate employees is by putting them in an environment where mediocrity is accepted because the perpetrators of the mediocrity can't be fired.
Ada's problem is that it was only a defense-sector language, for reasons specified by others in the thread e.g. compiler cost. Ultimately, targeting tooling to only a specific industry is dooming it to failure; the tooling must stay relevant to many companies and industries both so that people will see it as a career-advancing skill and so that the labor market remains fluid.
Even if the company agreed to train you, would you take the job offer? Chances are, no, because if you were to ever switch jobs in the future, you want to still be employable
A counter-example would be Goldman Sachs, with their own language (Slang) and their own database (SecDB), former Goldmanites have no trouble finding work after.
An interesting point which I will concede. But I doubt the exception disproves the rule for the general case.
For what it's worth, GS was founded in 1869, which makes it older than most of the behemoth systems companies like IBM (1911) or AT&T (1880). Big banks like GS may not be as invincible post-2008 as they used to appear to be, but if there are institutions which you could say "this institution is not going to evaporate in the next few decades which will make up my career", GS would not be a bad bet.
Which brings an interesting question, how many former Goldmanites a) worked primarily in Slang (given that not all Goldmanite engineers work on SecDB) b) were laid off or otherwise left GS without having a job lined up and c) then found work? If you can prove that you can work on a different stack and get a job with no frictional unemployment, is a much different picture compared to engineers who stay out of work (the parallel question being, why is Slang so much more de-facto employable than COBOL or other languages which for one reason or another are now unpopular or unused in the wider industry?).
How do you ensure they stick around? Training has a high cost that isn't worth it if the people jump ship 2 or 3 years later as is the norm in this industry.
Well, it's a reason as good as any other to start paying good salaries AND good raises, instead of just the former. And don't skim on the benefits.
As a general rule, treat your employees fairly (which includes updating their salaries up to market value, as often as needed) and, lo and behold, they will stay. There is a lot of talk about changing jobs because of a lack of challenge, wanting to try new technologies, etc., but 99% of the time, it's about money (and benefits).
Admittedly, this idea might not be very well received by most companies.
I dunno, nobody I know is actually looking to job hop. If you treat people decently, give them raises, train them, why would they have any incentive to leave?
Hiring somebody new costs 15-25% of the raw salary cost for the year. Pay people 10% more instead, no incentive to leave.
Plus however long it takes to ramp them up, could be 6 months on a reasonably complex codebase. And the time of other engineers both in the hiring process and bringing the new engineer up to speed. I’d say the cost of replacing an engineer could be as much as their entire first year’s comp.
Perhaps if you invest in people, they wouldn't do that? I mean people job hop because that is the only way to advance, but what if there was another way? Job hunting, interviewing etc are a royal pain in the backside. If there was a way to have a career without all that everyone would be happier, employers included
People jumping ship 2 or 3 years later is a result of the market correcting itself. There was a point in time when people stayed for 20 years in a company. Why? You could switch, but the pay would be the same.
There is a cultural factor too, many companies seem to have an aversion to promoting from within. It's usually far easier to get promoted by interviewing elsewhere for a higher position than it is to deal with the internal politics of moving up within the same org. But it could be a clear expectation: complete this training, get this experience, move up a rung.
Defense is all done by contractors or lifers, far away from the competitive tech hubs. I don't think they have a retention problem, unlike companies in the Valley.
Also, the alternative is C++ and C++ developers are not a replaceable commodity either.
There are plenty of defense contractors near tech hubs. Defense was a big business in the SF Bay Area long before there were software companies there, and it's still big today:
Yes we are, mostly. There are very few programming jobs for which the laborers aren't essentially replaceable commodities, including programmers who are proficient with C++.
My tiny aerospace knowledge also tells me that there's a ton of cpp tooling that is already known to shops and they rely on this rather than switching culture to ADA even if it may provides greater value in mid to long term.
I never implied it was useful, just that people are more likely to take cpp and coat it with tools to feel getting things done by juggling masses of files.
Is this really the fault of C++? Ada was appreciated for providing static code analysis out of the box but they found out that coupling C++ with a (modern) static analyzer gave better results.
> > which is buggy as hell
> Is this really the fault of C++?
I'm not saying it necessarily is, but it clearly can be. When you fuck-up language semantics, as pointers in C and C++, making things vague and unspecifiable regarding important properties (aliasing, memory allocation, etc), then you lose something that is extremely hard to get back via static analysis.
For this reason, a language that has safe properties in a domain (like Rust or Ada) will always be safer in that domain, by construction, that a language where you graft static analysis on top of it.
This can be somehow alleviated by coding rules/standards and annotations for static analyzers, but then, you're not programming in the same language anymore, which has its own set of problems.
I think a time comparison of both would still show the F-22 had less software problems. The F-22 also has some seriously complicated software when you look at the capability.
Ada was relatively easy to learn by anyone in the past with Object Pascal or Modula-2/3 knowledge.
Which used to be quite common before C and C++ got widespread during the mid-90's.
Ada's biggest problem was the price of the compilers, and lack of adoption by OS SDKs, an issue that also pushed other languages outside of mainstream.
Businesses already had to pay for the OS developer tools, unless there were legal requirements on their domain, they weren't keen in buying extra compilers.
I can confirm teaching basic Ada to newbies to "go and correct logic bug X" is 2-3 weeks on-the-job training. We don't even go for Ada experience when hiring anymore, just programming experience, and low cowboy factor...
That Unix is the roadster that gave us c. But Linux was the one that drove c into our core operating system infrastructure. Windows did the same favor for c++.
One of the reasons why other languages failed? While c/c++ flourished in the oss environment, even with its tooling being sub-par at the time. imo.
I almost agree, just not quite regarding how it went.
C++ was already being adopted by all desktop systems, Mac, OS/2, Windows, even if at lower level it was a mix of Pascal (Mac) and C.
On proprietary UNIX systems, C++ major stronghold was CORBA based applications, while some companies were pushing C++ bindings for Motif.
Then GNU and Linux happened, with FSF suggesting that the best approach to write portable open source should be C, and then we arrived in the present situation.
There are more computers on this planet than just plain desktop.
Most of them are servers, mainframes and embedded devices running some form of UNIX based OS.
If you prefer I can rename it to nix, as I wasn't thinking about POSIX certification.
BSD, Minix (running on your Intel chip), Aix, HP-UX, POSIX layers in IBM and Unisys mainframes, RTOS, NuttX, QNX, and many other POSIX based OSes for embedded deployment.
Ada is much simpler than C++, the hard part about learning it is the lack of tutorials and general information. That has changed in the last few years, but for the longest time the Ada community would just point to the (freely available!) standards doc to answer all questions.
The spec isn't that useful if one doesn't already know the concepts being explained, making learning the ideas behind Ada not that easy, but fundamentally those ideas are not hard.
Everything that exists in C++ also exists in Ada under a different name and syntax.
The separation of cpp and header files, classes, inheritance, different kinds of inheritance, virtual, pointers, references, pointers of pointers, exceptions, meaningless errors from the compiler, etc...
Personally, I find both languages to be a complete clusterfuck. The difference is that C++ will compile anything and crash for no apparent reason whereas Ada will refuse to compile anything.
> But if you are planning a multi-decade project wouldn't you just... train some yourself?
The reality is most businesses are rather short sighted and prefer to save on up-front costs. Never mind how bad it can come back to haunt them in the future...
The others from that time period by the military and defense contractors showed something similar. In only one case did I see C++ and Ada tie but why wasnt evident. Note this was before automated proving in SPARK, Design-by-Contract in Ada 2012, and co tract/type/property-based testing tech. The numbers would likely be even higher. Of course, one would want a comparison against tech designed for same things in C which are plentiful now.
You'd be surprised how much code you can move from conditional instructions to
data types if you have a good type system, and if this type system is a static
one, you get it checked before your program even starts.
F# has this too. Other languages too, of course. Heck, even Pascal has a limited form of it - enumerated types and user-defined array types etc. - years ago.
You'll write different bugs in different languages. You can't leak memory in Java (you can, but it's very hard), for instance, as you can in C. In Python, I often write code that barfs when it gets an object of a wrong type because parameter types are simply not enforced. The bugs I write in Lisp are entirely different from the ones I write in C.
But if we agree that Ada reduces one kind of bug compared to, say, C, then we'd also have to come up with a class of bugs which Ada makes easier to write, in order to say that the number of total bugs stay constant while one kind decreases.
I can't come up with such an example.
You're right in that things are rarely black and white, but when it comes specifically to bug prevention, I think Ada is a strict improvement over many alternatives.
An incomplete product is one thing, but failing type checks implies a non-working product, not an incomplete product. Businesses need correct code. The real question is what is the fastest way to get correct code, using a language that isn't as strict and testing the heck out of your implementation, or using a language that is stricter but harder to learn and write?
It seems to me in both cases you'll still need to test your code thoroughly, so not an easy question to answer.
