SoylentNews is people
SoylentNews
Over at ACM.org, Doug Meil posits that programming languages are often designed for certain tasks or workloads in mind, and in that sense most languages differ less in what they make possible, and more in terms of what they make easy:
I had the opportunity to visit the Computer History Museum in Mountain View, CA, a few years ago. It's a terrific museum, and among the many exhibits is a wall-size graph of the evolution of programming languages. This graph is so big that anyone who has ever written "Hello World" in anything has the urge to stick their nose against the wall and search section by section to try find their favorite languages. I certainly did. The next instinct is to trace the "influenced" edges of the graph with their index finger backwards in time. Or forwards, depending on how old the languages happen to be.
[...] There is so much that can be taken for granted in computing today. Back in the early days everything was expensive and limited: storage, memory, and processing power. People had to walk uphill and against the wind, both ways, just to get to the computer lab, and then stay up all night to get computer time. One thing that was easier during that time was that the programming language namespace was greenfield, and initial ones from the 1950's and 1960's had the luxury of being named precisely for the thing they did: FORTRAN (Formula Translator), COBOL (Common Business Oriented Language), BASIC (Beginner's All-purpose Symbolic Instruction Code), ALGOL (Algorithmic Language), LISP (List Processor). Most people probably haven't heard of SNOBOL (String Oriented and Symbolic Language, 1962), but one doesn't need many guesses to determine what it was trying to do. Had object-oriented programming concepts been more fully understood during that time, it's possible we would be coding in something like "OBJOL" —an unambiguously named object-oriented language, at least by naming patterns of the era.
It's worth noting and admiring the audacity of PL/I (1964), which was aiming to be that "one good programming language." The name says it all: Programming Language 1. There should be no need for 2, 3, or 4. Though PL/I's plans of becoming the Highlander of computer programming didn't play out like the designers intended, they were still pulling on a key thread in software: why so many languages? That question was already being asked as far back as the early 1960's.
The author goes on to reason that new languages are mostly created for control and fortune, citing Microsoft's C# as an example of their answer to Java for a middleware language they could control.
Related:
Non-Programmers are Building More of the World's Software
Twist: MIT's New Programming Language for Quantum Computing
10 Most(ly dead) Influential Programming Languages
(Score: 2) by DannyB on Friday July 08 2022, @02:01PM
Development time.
Development cost. (yes, this is a real thing! Believe it or not!)
Maintainability.
Easy refactoring tools.
Multi platform. I want to take my compiled binary and run it on different operating systems, different types of processors -- and have it become machine code at the very last possible moment. This is a HUGE advantage. I took a Mandelbrot viewer program I wrote in Java in 2004 and years later ran it (the binary!) on a Raspberry Pi which didn't exist when I wrote the program.
Optimization. Once you have the complete program to optimize, it is possible to do optimizations that are not possible in an ahead of time compiler. For example, the global optimizer could realize that a certain function does not need a vtable entry and could make the calling convention more efficient -- throughout the entire program wherever this function is called. Aggressive inlining of code is possible that an ahead of time compiler and linker cannot do. Once you have the WHOLE program, you can inline some function from one library into where it is called in some other library, in machine code form. The optimizer could rewrite a single function into two variations of that function with slightly different parameter lists so it is called more efficiently depending on how it is used. A class member function that never references the class itself (eg, a 'static' function) could be turned into a static function at runtime -- but this affects every single place in the global program where that function may be called from. This cannot be done in an ahead of time compiler and linker.
Maybe a human can do some optimizations better than a machine. But that is debatable. There are now experiments in using ML (machine lernin') to optimize code in LLVM.
Finally that brilliantly written, beautifully crafted, macro assembler code -- which is a true work of art -- probably becomes obsolete in five years and is scrapped. Today's micro controllers are more powerful than the mainframes of
youryou'reyore.If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious