I wonder what stage companies people that have the freedom to do these types of explorations work at. I barely have time to work on core components of my system at a deep level. I usually have to leverage existing work and move on
How an Engineering Company Chose to Migrate to D
81–90 of 170 posts
Re: How an Engineering Company Chose to Migrate to D
#82... and went bankrupt because of not being able to finding Engineers.
...which is why we’re all still programming COBOL, Fortran, and LISP.
Nothing wrong with the languages you mentioned; they do what they do best. COBOL and Fortran are both fantastic and nothing yet truly replaces them. COBOL is accurate out to 38 digits, which is amazing for such an "old" language. Banks still like their COBOL and it just works. No stupid "libraries and/or frameworks of the month" to worry about, it compiles cleanly and every time, and it's easy to write and maintain. Modern doesn't always mean best. I still write tons of stuff in sh. If it's under 100 lines, it's shell, awk, or similar. COBOL and Fortran still have tons of life left in them. Every time someone undertakes a massive project to replace COBOL in the financial sector (usually driven by a latte-sipping hipster and his recently graduated ilk), it goes pear shaped. We still use hammers. They work.
Re: How an Engineering Company Chose to Migrate to D
#83This article seems to ignore two of the most important reasons to choose one language over another. Specifically: 1)Expressiveness in the given problem domain. Some languages are really great in particular niches. 2)Availability of devs. The ability to hire and retain a really great team makes or breaks projects, and while a smart, motivated dev can learn any language, it's definitely a factor in their choice to work…
I sometimes think people use "availability of devs" to mean "cheap, expendable service". If you're working in an industry where you bank more on hitting the ground running more than retaining developers then this makes sense, and totally valid.
But I've found that lots of places seem to be focused on if you know X rather than being a well versed, developer who enjoys growth. And it feels more and more like the reason is because they don't expect anyone to stay there for more than a few years tops.
Re: How an Engineering Company Chose to Migrate to D
#84Earlier quoted context omitted.
...which is why we’re all still programming COBOL, Fortran, and LISP.
Nothing wrong with the languages you mentioned; they do what they do best. COBOL and Fortran are both fantastic and nothing yet truly replaces them. COBOL is accurate out to 38 digits, which is amazing for such an "old" language. Banks still like their COBOL and it just works. No stupid "libraries and/or frameworks of the month" to worry about, it compiles cleanly and every time, and it's easy to write and maintain.…
I have nothing against any of them, I just was surprised anyone thinks that a new(ish) language can't find engineers to use it.
Re: How an Engineering Company Chose to Migrate to D
#85How do they plan to solve the hiring problem? I am curious.
Re: How an Engineering Company Chose to Migrate to D
#86Earlier quoted context omitted.
Nothing wrong with the languages you mentioned; they do what they do best. COBOL and Fortran are both fantastic and nothing yet truly replaces them. COBOL is accurate out to 38 digits, which is amazing for such an "old" language. Banks still like their COBOL and it just works. No stupid "libraries and/or frameworks of the month" to worry about, it compiles cleanly and every time, and it's easy to write and maintain.…
I have nothing against any of them, I just was surprised anyone thinks that a new(ish) language can't find engineers to use it.
From my admittedly cursory look at D, I find nothing persuasive enough to get me to take it on and learn it when the chances of my ever using it are slim. I guess I'm just old school. It seems that every week there is a new language, framework, etc., and most of them are really not doing anything radically different. As a back end guy, I see most of the churn happens in the web dev world. I prefer old, stable, and very little churn, hence my continued love for COBOL in particular. I also like C++ and Python, but there is something fantastic about COBOL, sh, and awk, which are oft-used. I'm getting less and less enthusiastic about systems stuff now that I'm getting older and more into writing useful tools to help my guys. Call it an easy exit...
Re: How an Engineering Company Chose to Migrate to D
#87... and went bankrupt because of not being able to finding Engineers.
Just tell your new hires here is a book on the language go learn it - which is what I was told at my first Job (world leading RnD).
I am usually not against learning new stuff. But I would also like my learning from current work generalize to my future career. From a pragmatic perspective, learning D is probably going to have less ROI.
Either the company focus solely on finding enthusiasts or they pay the premium to overcome this.
Re: How an Engineering Company Chose to Migrate to D
#88While the article states that other languages were evaluated, it seems as though the project was motivated entirely by the author and the evaluation was just paying lip service to what was basically a foregone conclusion. Don't get me wrong, I like D from the small amount of playing I've done with it -- and maybe it is the best tool for their purposes -- but this doesn't strike me as an impartial evaluation. The need…
>The need for nested functions bugged me as well. That seems like an odd deal-breaker and hints at code smell
Nested functions were a very common pattern on languages like Pascal, Modula or oberon. They are equivalent to code blocks inside a function in C.
Re: How an Engineering Company Chose to Migrate to D
#89Earlier quoted context omitted.
The biggest problem is they have engineers who have turned their hands to programming, one would expect, without the formal training and so have latched onto various antipatterns without knowing any better because Pascal allowed them to get away with it - painting themselves into a corner. He mentioned an awful lot of code that would have to be refactored, and it could be that they are just too far down the rabbit ho…
In this case, I'd look into compiling the existing code into .dll/.so files, and just linking between Extended Pascal and ${NEW_LANGUAGE}. Then, convert the code to ${NEW_LANGUAGE} as needed, if needed. That solution is probably the lowest cost / safest course... Assuming the Extended Pascal compiler they have supports it. But I suspect choosing D was a fait accompli.
This is the approach I took to modernise Fairway (which is just one component of our suite). It doesn't free us from the limitations of the Extended Pascal compiler. It still works, but we want a way out.
Re: How an Engineering Company Chose to Migrate to D
#90While the article states that other languages were evaluated, it seems as though the project was motivated entirely by the author and the evaluation was just paying lip service to what was basically a foregone conclusion. Don't get me wrong, I like D from the small amount of playing I've done with it -- and maybe it is the best tool for their purposes -- but this doesn't strike me as an impartial evaluation. The need…
>The need for nested functions bugged me as well. That seems like an odd deal-breaker and hints at code smell Nested functions were a very common pattern on languages like Pascal, Modula or oberon. They are equivalent to code blocks inside a function in C.
Indeed, it serves encapsulation.