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, Insightful) by anubi on Saturday July 09 2022, @09:34AM (10 children)
Thanks for that post.
I am another C++ fan, and will gladly code another library and define new objects as needed.
Yes, C++ let's me do anything. Including shoot myself. I am careful with it, and it allows me to write concise clean fast code. But I've had my learning curve of "what's going on here?" just as anyone else has. After a while, I have developed my own little toolsets and ways of doing things that work for me.
Your post is a refreshing read for me, giving me more ideas of how to counter arguments of why I am avoiding some languages that I consider to compile to bloaty code that I can't verify that what I need done is all it's doing.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by DannyB on Saturday July 09 2022, @04:23PM (9 children)
You are optimizing for cpu cycles and bytes.
I am optimizing for dollars.
Different problems, different solutions.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 2) by JoeMerchant on Tuesday July 12 2022, @10:56AM (8 children)
If you are optimizing for dollars by choosing tools that ill-trained low cost developers can use relatively more safely due to their constraints, I would say you are doing it wrong. One good developer is more productive than five cheap ones. Better to spend your low budget headcount on test and quality and procedure mavens. Software isn't a sawmill, mistakes on work in progress are only costly if they are released to customers. Best to force your genius developers to explain their work to newbie testers who are backed up by management to have the power to hold releases as long as it takes to get them right.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by DannyB on Tuesday July 12 2022, @01:56PM (7 children)
Good developers can make simple mistakes. It happens. Sometimes it takes a lot of time to find it. Even given your very obvious advice of explaining code, that gee nobody else would have thought of, mistakes still happen. It is better to eliminate the possibility of making some of the most obvious and worst blunders. Especially ones that are purely mechanical and have nothing to do with the problem domain. Such as double freeing a pointer.
The language should fit the problem domain. When you talk to accountants they don't ever seem to mention bits, bytes, cpu cycles, pointers, etc. Your programming language should not force you to consider details irrelevant to the problem.
Even in a low level language like C++ you end up building abstractions upon abstractions. Like auto pointers, just for example. Other languages are merely abstractions that shield you from the raw sharp edges.
Garbage Collection is also a huge advantage for most everyday programmers. Most modern languages all have GC. Especially in the last twenty years. GC eliminated the three biggest sources of bugs (and vulnerabilities) that have cost billions of dollars. Here on SN I've explained before how GC is actually a performance (latency) advantage for a big busy commerce server doing business.
You must be right and everyone else is wrong. How did Java get to be the top #1 language for over 15 years straight? Even today it stays in the top three. What is wrong with all these people? How do they not have your wisdom to understand their problems and how they should solve them.
I'll say it again, but it will fall on deaf ears:
If there were one perfect programming languages that was ideal for all possible uses, we would all be using it already.
Do you not think that in my business we all understand the problems and how to best solve them? And that this has been going on for decades? We explore alternatives and choose things that work best for our problems.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 2) by JoeMerchant on Tuesday July 12 2022, @02:39PM (6 children)
>Good developers can make simple mistakes. It happens.
Absolutely, which is why independent test is key to quality.
>It is better to eliminate the possibility of making some of the most obvious and worst blunders.
It is better to make an obvious blunder than a subtle one. Also, the frequency of automatically or otherwise flagged obvious blunders is a good indicator of how many subtle problems you can expect from the same source.
>GC is actually a performance (latency) advantage for a big busy commerce server doing business.
GC has its place, but it should be an easy choice to make, not a default difficult to change.
>How did Java get to be the top #1 language for over 15 years straight?
Sloppy web developers and other quick-fix junkies. And it's good for that. If you want tiny projects, Java, Python and friends are great quick fix tools to replicate common things. Want to replicate that cool AI project? Just open your jupyter notebook and copy-paste what the previous guy did, just don't expect to be able to dig in deep for changes like processing your images in HSL instead of RGB without a 10x jump up in the learning curve. Were it all coded in C++ to start with, that would be a 5 minute change to the source.
>We explore alternatives and choose things that work best for our problems.
Kudos, most businesses suffer from horrendous inertia, Not Invented Here syndrome, susceptibility to vendor lock-in and incentives, and a general apathy of management to herd the cats in development.
Anything can be coded in any (Turing complete) language. The tendency I have seen for the training wheel languages is for little projects to get started, show a blinking light or hello world in record fast time, generate enthusiasm as they customize to do one or two domain specific things, then get mired in horrendous maintenance overhead when somebody says something like: "Let's go back and make all the buttons perform closed loop communication verifications after activation." Rather than capability scaling with code supporting arrays or matrices of functions that get easier to add as you grow, each new widget or feature seems to take a bit more effort than the last. Of course you can do great things in any language, trac is a pretty impressive python project that I have used daily for 15+ years, but most python projects I have seen developed in-house reach a point where they just stop growing due to effort required for expansion and the suggestion to start over - usually in another language - starts coming up more and more often as they grow.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by DannyB on Tuesday July 12 2022, @05:40PM (5 children)
I'm glad you know everyone's business better than they do. And you know the one perfect language they should all be using.
GC has its place. That place is in most modern languages. There are still languages that do not have GC for uses where GC is wholly inappropriate.
This is the one that tells me you really don't know what you're talking about. Maybe you are thinking of Javascript not Java?
Java is for huge gigantic projects. Millions of lines of code. Written by many developers. Maintained for years even decades by many different people who have no contact with the original authors. Java does very well for this use. Unlike Python 2 vs 3 you can take the very oldest compiled binary or source code and run it on the latest Java versions. Java has a very carefully maintained backward compatibility. I think you do not understand the sheer amount of Java code in existence. I'm not saying you should like Java. Just realize that it really does have its place and is not some kind of mistake just because it is not suitable for YOUR purposes.
Python is at the opposite end. Great for small projects because it is interactive and dynamic. Fantastic for prototyping. Even for good sized programs. But not for an enterprise application that I just described. Refactoring is a big problem with dynamically typed languages.
I like Python. I like Lisp (various lisps). Java. Other languages. I use the right tool for the right job. Not a one size fits all.
I take the view that any successful language must be doing something right for someone.
That actually proves my point. We could, and you could write everything in assembly language. Do away with C and all higher level languages and mandate only assembly language worldwide for all programming. Period. No exceptions.
Yes, it could actually be done. But at what cost?
There is a reason Java exists. There is a reason it is successful. Java it not the right language for all possible uses.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 2) by JoeMerchant on Tuesday July 12 2022, @07:21PM (4 children)
>And you know the one perfect language they should all be using.
There is no one perfect language. GC has its place, but the languages that use it tend to become unmaintainable byzantine disasters when you put them in the hands of people who "need" GC and ask them to do a large, long lived project with it.
>I think you do not understand the sheer amount of Java code in existence.
I have encountered plenty of it. I have also encountered a great number of management types who thought that Java was their answer for high performance cross platform solutions, and could never quite grasp why it would be unacceptably slow for any of our applications. I even encountered a couple of "Java prototypes" where management steamrollered the crew into "doing it in Java" and had to translate it out to something faster to make it anywhere near competitive in the marketplace. For my purposes, Java usually isn't the answer. I'm sure there are plenty of places where it makes sense, but I also suspect there are many places where it was a bad choice that got implemented anyway because nobody who knew better stood up to explain the issues.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by DannyB on Tuesday July 12 2022, @08:45PM (3 children)
Java is not slow. It is quite fast actually. You use commercial web sites that are Java without knowing it. All of the java bytecode is compiled down to native code. Unlike, say, PHP or Perl which is interpreted, or Python, when Java services an HTTP request, it is pure native compiled machine code that services that thread.
When a Java program starts up, the java bytecode is interpreted (slow). As soon as any (at this point every) function is using a disproportionate amount of cpu, that function is immediately rapidly compiled into poorly optimized machine code by the C1 compiler, and is put on a list to be recompiled again soon by the C2 compiler. When the C2 compiler comes around, it spends a lot of time and effort producing highly optimized code. Better than an ahead of time compiler is capable of (such as C).
Why better? Because the C2 compiler in Java has the WHOLE PROGRAM, not just part of it. When you compile in C, the compiler is only compiling part of the program. The linker may see the machine code of all the component parts which it links together, but it does not globally optimize them in any deep way.
Java's C2 compiler can aggressively inline code and it does. It optimizes for speed over size. You can always buy more memory but you can't buy back time. With a compiled and linked program in C, a function in my precompiled library cannot be inlined into your code where you call my function. Your code and my code are independent development efforts. The C2 compiler has the entire program, in java bytecode form, to work with. It can rewrite function parameter calling conventions. It can recognize when certain methods in an object do not need a vtable entry because they are the only possible call target. (Something C++ cannot do)
Because of all of this, a Java program seems to start up slowly and then "warm up" and run fast. Thus, Java is not a good solution for writing a replacement for the 'ls' command. But it is fantastic for a very large program running on giant servers where the program runs for a very long time without being interrupted or restarted.
I almost never hear anyone complain about Java unless they really don't know much about Java.
My journal article: It's fashionable to hate Java [soylentnews.org]
That article explains a lot, and some SN readers were surprised.
It is funny that the marketplace, for enterprise applications, has already decided two decades ago.
Ask yourself, why does Red Hat do research on the latest state of the art Java garbage collectors? Why are they spending money on this? See Red Hat's Shenandoah GC for Java. This can work with 16 Terabyte memory heaps with a max GC pause time of 1 millisecond. See for yourself. Yeah, Java is slow.
Or Oracle's ZGC garbage collector which is also state of the art and has similar specs to the previous paragraph.
Or why does IBM build its own Java runtime called J9?
And why oh why does Microsoft, yes Microsoft contribute to Java development? Here's why: because their biggest mega customers all use Java extensively.
If you're using Java for dinky programs that run in less than 32 GB of memory you're doing it wrong.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 2) by JoeMerchant on Tuesday July 12 2022, @09:29PM (2 children)
>I almost never hear anyone complain about Java unless they really don't know much about Java.
I had to actively start defending against Java being used on desktop PCs for heavy-lift analysis software 20 years ago. The primary Java cheerleaders had no idea of what they were talking about. At the time, bytecode interpretation in dedicated silicon was one of the "visions of the near future" which, to my knowledge, never materialized.
Since then, Java (not Javascript) as web based applications have occasionally haunted me, forcing end-runs around modern browser security improvements. Small time stuff, 2-3 man-months to implement, that would have been better implemented in something else to achieve their "low maintenance cross platform" objectives.
No doubt the large scale web-apps have benefited from advances in JIT compilation, but if you tell me that much of Facebook runs on Java and owes its elegant user experience to the power of Java I'm going to have to laugh you off the board.
I wouldn't advocate for C++ to implement a big web based app, although I'm listening to an http interfaced mp3 player I coded up last year right now, it is pretty good for simple-ish stuff.
>why does Red Hat do research on the latest state of the art Java garbage collectors? Why are they spending money on this?
Because the customers want it. Doesn't make it "the best" answer for all problems. If you're at scale with 1000+ coders in a single playground, I see the need for sandboxes, garbage collection, etc. I play more on teams of 50 or less, often times over the past 30 years on teams of 5 or fewer engineers. We have always made self-contained widgets, not web-facing million+ user monsters. The widgets tend to have 5 to 100 man-years in their development, and serve a handful of users at a time, often just one.
>If you're using Java for dinky programs that run in less than 32 GB of memory you're doing it wrong.
Agreed. Our latest box only has 16GB of RAM.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by DannyB on Wednesday July 13 2022, @07:17PM (1 child)
It sounds like you have been influenced by Java long long ago and are unaware of what modern Java is like. Java has come a very long way. Java's C2 compiler is one of the most sophisticated compilers there is. Similarly some of its modern GC's.
It was a mistake for browsers to ever support:
* Java applets
* Flash
* ActiveX
* Silverlight
Java's C2 compiler can rewrite functions. For instance, produce two versions with two parameter lists and calling conventions. It can do this because it has the WHOLE program to work with at runtime.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 2) by JoeMerchant on Wednesday July 13 2022, @08:19PM
>Java's C2 compiler can rewrite functions. For instance, produce two versions with two parameter lists and calling conventions. It can do this because it has the WHOLE program to work with at runtime.
That's nice. Right now, I'm fighting with gcc over optimizing a "whole module" at one time. We have a system backbone of ~3000 properties with message broker getters, setters, default values, value changed signals, etc. and the biggest of our property using applications is causing the gcc linker-optimizer to balloon in optimization time such that the total system build is taking 14 minutes with 2900 properties, 15 minutes with 2925 properties, 17 minutes with 2950 properties, 20 minutes with 2975 properties, 24 minutes with 3000 properties, etc. The basic problem is: all the properties are written to a single module and when gcc is optimizing this "whole module" at one time, it is scaling at something like O(n^3) optimization time, and we're getting to the point where that is starting to hurt.
I believe we're coming down to horses for courses. If you're writing a Facebook competitor, Java may be your horse. I live in a world of 5-50 developers writing apps that are used by 1-5 users at a time running on a single machine of the Core i7-6xxx class. We've got some STM-32 accessory boards playing in the system, and might network out for 2% of the total functionality of the system, otherwise we're focused on delivering the best user experience to our local user(s) on ~10K copies of this mostly self-contained system running in 40+ countries around the world. We sell the system for $10K-$40K at a build cost of around $8K, but that's not the point, the point is to sell $200 disposable "razor blades" (that we make for $50 net per copy after $5M development costs) that the system enables our users to benefit from during their $2-5K operations. Our best users do ~1500 operations a year, for a profit of $225K annually per device to us on the "blades" alone. So, we're not Facebook, but just this one device (of about 6 that we make) nets around $700M per year - not all users are "best" users, some only do 10 operations per year per device. Our software dev team for this device might run a total headcount cost of around 30 (coders, testers, quality, etc.), at maybe $220K per head (not that we take home anywhere near that), so we're only costing about 1% of gross revenue - not a bad margin, and not an insignificant business model. Over the last 30+ years, I have worked for a dozen similar companies with similar products, and Java is just not our horse, though we are starting to let the Javascript camel's nose under the tent flap, in the name of diversity and accommodating the available hiring pool which includes our latest programmer who took a maternity leave last month.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end