All Rust, D and Go pass as "better C++" To me, the evaluation goes solely as ecosystem vs. ecosystem There D is ahead not so much by number of features, than by lack of showstopper flaws
I would add Ada and Swift as well.
How an Engineering Company Chose to Migrate to D
151–160 of 170 posts
Re: How an Engineering Company Chose to Migrate to D
#152While 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…
Framing closures as a “requirement” is pretty strange. Depending on the context they can be an ergonomic nice-to-have, but it’s not like you can’t express a program without them.
If you have a half million codebase that you need to migrate, I would say that every heavily used Extended Pascal feature is required to be easily translatable. If it's simply possible but the translation is not direct or easy, then the maintainers may be better off staying with Ext Pascal than maintaing a half million uglified code base.
Re: How an Engineering Company Chose to Migrate to D
#153Earlier quoted context omitted.
I see mostly imaginary. As a back end systems guy for over 20 years, I deal with guys all the time wanting to introduce new tools into the mix that add zero value. There is a reason why *nix tools are still around. There is nothing that Python can do better than awk for grabbing data columns and piping them into some other tool. There is a reason why COBOL still exists, for example, what with its ability to ensure ac…
You never said "C" but perhaps you think there is "a reason" why C still exists too. The only reason ineffective tools like C exist is because there are people at the other extreme from those kids: Not take any risk but stick with tried and wrong tools.
Nope, there are tons of other reasons.
Huge pool of programmers. Huge pool of libraries. Tons of existing code that should continue to run. Excellent documentation. Very fast compilers. Debuggers and profilers a plenty. Top notch vendor support. Choices of IDEs. Works great in embedded. Predictable.
The alternatives being what, e.g. Rust, a 5 year old language with a single implementation that still tries to find its place, and brings extra baggage to the table?
>Not take any risk but stick with tried and wrong tools.
Engineers don't take risks. You wouldn't want risks in the people building your bridges and planes, why would you want in your OSes and network infrastructure?
Re: How an Engineering Company Chose to Migrate to D
#154very impressive and ambitious project
exactly my words!
Re: How an Engineering Company Chose to Migrate to D
#155Earlier quoted context omitted.
C still has it's place. It's not glamorous, but it works. COBOL has no decent replacements. Yet. Some have tried. Almost all have failed. Old does not mean useless. If it works, then it's not wrong.
On UNIX clones and embedded developers that won't take anything else even at point gun. .NET, Java are good COBOL replacements. http://www.fujitsu.com/global/products/software/developer-to... https://www.microfocus.com/products/visual-cobol/
>.NET, Java are good COBOL replacements.
Not even close.
As for the links, those are still about COBOL the language.
Re: How an Engineering Company Chose to Migrate to D
#156Earlier quoted context omitted.
On UNIX clones and embedded developers that won't take anything else even at point gun. .NET, Java are good COBOL replacements. http://www.fujitsu.com/global/products/software/developer-to... https://www.microfocus.com/products/visual-cobol/
> .NET, Java are good COBOL replacements. Not even close. As for the links, those are still about COBOL the language.
I guess you need to inform yourself about migration projects that use those products to bring COBOL codebases to modern platforms, where new features are then written in Java/.NET languages, while the old working code is left as is.
Re: How an Engineering Company Chose to Migrate to D
#157Earlier quoted context omitted.
if you mean "hiring d programmers", i think it's somewhat of a nonissue. afaik d isn't particularly esoteric, so any new hire should be able to get up to speed quickly.
I'm not so sure about that. For the basics that's definitely true, and no doubt if you're a C++ programmer then it will be an easier transition, but if you're coming from a higher level language like Java, C#, PHP etc then there's a lot to get your head around. That said, it's absolutely worth it :-)
I come from a Perl/Js background and find D quite easy to pick up and be productive in, as opposed to C, C++ or Rust. With Rust and C I always find myself fighting the compiler.
Re: How an Engineering Company Chose to Migrate to D
#158> Nowadays, whenever D is publicly evaluated, the younger languages Go and Rust are often brought up as alternatives. Here, we need not go into an in-depth comparison of these languages because both Rust and Go lack one feature that we rely on heavily: nested functions with access to variables in their enclosing scope. Maybe I've misunderstood, but aren't Rust's closures [1] exactly what the author is describing? Spe…
D nested functions don't 'capture' variables from their enclosing scope. They can access them just like other code in the enclosing function. This is achieved by adding a hidden parameter that is a pointer to the enclosing function's stack frame. This forms a threaded list so variables in nested enclosing functions can be accessed by walking that list. This is the same way Pascal does it. It also means that taking th…
It's the same way that MetaWare implemented nested functions in its C/C++ compiler in the 1980s and 1990s, too. On top of that, MetaWare built iterators and an iterator-driven for mechanism. The yield() in an iterator was actually a nested function callback from the iterator to the body of the invoking for statement, which was turned into a nested function under the covers.
* http://jdebp.info./FGA/metaware-iterator-driven-for.html
In theory, the extra frame pointer mechanisms of the ENTER and LEAVE instructions in the Intel ISA were there for supporting this kind of nested function. MetaWare High C/C++ did not use them, preferring to use a variant calling convention where (if I recall correctly) ECX contained the extra hidden parameter.
Re: How an Engineering Company Chose to Migrate to D
#159Earlier quoted context omitted.
> .NET, Java are good COBOL replacements. Not even close. As for the links, those are still about COBOL the language.
I guess you need to inform yourself about migration projects that use those products to bring COBOL codebases to modern platforms, where new features are then written in Java/.NET languages, while the old working code is left as is.
Nobody argued that new features could be "written in Java/.NET languages".
Not even that COBOL codebases could be bridged and work "left as is" alongside those.
The main objection was with the word "good".
Re: How an Engineering Company Chose to Migrate to D
#160Earlier quoted context omitted.
I guess you need to inform yourself about migration projects that use those products to bring COBOL codebases to modern platforms, where new features are then written in Java/.NET languages, while the old working code is left as is.
Nobody argued that new features could be "written in Java/.NET languages". Not even that COBOL codebases could be bridged and work "left as is" alongside those. The main objection was with the word "good".
Except you have your definition of "good" and I have mine.
This statement is meaningless without additional information.
> COBOL has no decent replacements.