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 JoeMerchant on Monday July 11 2022, @01:58PM (16 children)
>with so much ass-broken syntax means you end up with unjustifiable cognitive overhead
Chinese speakers say this (and quite justifiably) about English. English speakers are mostly too ignorant of Chinese to have a complaint like this. English speakers complain about how the French do their numbers, Parisian French complain about - well - everything.
Point? It took me 5+ years of (solo, unguided, unmentored) daily professional practice with C++ to learn the parts of the ass-broken syntax that I use frequently. That probably could have been cut down to a couple of years if I focused 20% of my time on learning the language instead of just using it to get stuff done. Could have been a year or less with a good mentor who spent 20% of our mutual time doing code reviews of what I, and they, had written in the other 80% of our time - there's a best practice that I have never ever seen implemented in the real world, entirely due to the perceived and actual values of management.
>C++ is often used specifically to keep the cost-of-entry so high that the competition won't bother.
More than twice, I was hired to to untangle a bunch of academic code written in user-unfriendly combinations of: Matlab, Fortran, Python, Squirrel Script (yes, it's actually a thing...), ancient C, of course Java, and various other junk, and translate it into a user friendly and maintainable package. Being a Qt/C++ speaker, that's what I recommended, and implemented in, and reduced the various toolchain + language towers of Babel to a single language, single API code base that ported to all kinds of target systems in a single click to launch (or auto-launch on power-up) user experience. The "powerful abstraction" Matlab code was hiding an un-necessary nesting of a loop which, when untangled, sped up execution of the C++ code 100x - just translating Matlab to C++ was good for another factor of about 2, but the real gain was in our multi-programmer code review of the guilty module which the profiler pointed out. C++ has pretty much all those fancy toys easily available, like highly developed runtime profilers, which tend to have spotty availability and less robust development in newer languages.
That's where I really balk at flavor of the day languages: in the toolchains' setup and maintenance. You can literally spend days getting the tools figured out before even starting on your code, and if you need to update to version x.y every few months that adds to the cost. The Qt/C++ has some toolchain setup overhead, particularly in the Microsoft influenced domains, but in general it's one of the quickest and easiest environments I have used for setup from scratch. Of course, I'm biased, because it's what I've been practicing for 16 years now, but during those 16 years I've watched so many man-months sunk into other toolchain setup and maintenance efforts it only reinforces that aspect of my prejudice.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by RamiK on Monday July 11 2022, @10:19PM (15 children)
My Chinese isn't even HSK 1 - I've basically learned just enough pinyin and some grammar to pull off wo bu hui shuo hanyu in a pinch and more or less catch basic keywords - but from what I've seen and heard, Chinese grammar is a delight compared to English.
A rewrite of interpreted academic code into a compiled language is expected to yield 10-100x performance improvements regardless if it's C++, C or whatever. Python specifically is officially quoted as being 10-100x slower than C exactly because it's simply the unavoidable cost of dynamic type and garbage collection. The thing is, the question isn't how pure interpreted dynamic code performs, but what would have happened if you'd write the performance-hungry loops in C libraries and binded everything else in python, go or lisp for all I care so it won't take 5 years of training and 15 years of practice to be able to maintain and develop the code going forward?
Toolchain setup and maintenance is a big part of the overall picture but it doesn't explain Java, C# or even, albeit after many years of dedicated focused work, Go's lack of adoption within the C++ ranks.
Qt is a good example of everything that's wrong with C++: Instead of having a few widgets that can be used with different rendering engines and what not, the Qt devs just went full retard and implemented their own memory management, types and main loop. Admittedly, the GTK and EFL devs screwed it up as well in much the same way... And I suppose at least with C++ you can override the methods so it's not quite as awful as GTK and EFL ended up being... But really, even if you claim to like C++, Qt isn't really C++ anymore. It's a dialect of C++. A horrible, mutated dialect running on some fubar garbage collected OS...
compiling...
(Score: 2) by JoeMerchant on Monday July 11 2022, @10:54PM (14 children)
>what would have happened if you'd write the performance-hungry loops in C libraries and binded everything else in python, go or lisp for all I care
So, your suggestion is to learn just enough C or C++ (or Fortran would do the job too) to implement the stuff that Python or whatever is too hobbled to handle, then hybridize that with the training wheels language so we have the opportunity to experience the worst of both worlds plus the grafting of multiple languages into a single project?
I am actually a fan of message broker systems, AMQP, MQTT, DDS, whatever. Build a system with whatever (single) environment makes sense for the task at hand, be that embedded microcontrollers, or C++ or whatever and let them coordinate through the (well established and debugged) message broker. Due to the ability to have tiny microcontrollers and heavy lift operating systems in a single device, it makes a lot of sense to me.
Qt has gone full retard in many ways, but it is a robust enough environment that I can not only shill/plug the company line: code once run anywhere, but also step out to straight C++ or other included libraries when the Qt answers are lacking, or otherwise undesirable. All without having to graft multiple languages and tool chains into a single executable.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by RamiK on Tuesday July 12 2022, @05:50AM (13 children)
I'm not sure what you're complaining about. Between templates and C itself, C++ is already trilingual. The problem is the tool-chains. But, between how Go embeds C and Lua is embedded in C, you obviously have better choices than python when you want to have C++ expressiveness and performance without C++ syntax so just do that.
And it's not my solution. Again, it's what already being done in most, if not all, large successful C++ project. Less so with C since you can still write large scale C code at the kernel and library problem space without deteriorating everything C touches into an unsafe language. However, I can't say the same about C++. Most C++ libraries assume method overrides so binding to them creates issues. It's not always the case (protocol and file-type C++ libraries typically avoid this so there's no issue with using them...). But it's the exception that proves the rule.
Careful there. Generalizing communication protocols and IPC as "message broker" might work on paper but context switching and most data sharing makes IPC slow (well, on general purpose machines at least...) so that generalized design only really applies to networked machines and specific services/daemons. You don't want to end up with Plan 9...
As previously mentioned, the company line often trends towards "the tools we know and that keep the competition away are good enough". It clearly doesn't reflect the market seeing how Qt somehow managed to lose market to dog slow abominations like Electron.
The company line is the market and the market has decided in favor of Electron so it might be best not to refer to the company line going forward.
compiling...
(Score: 2) by JoeMerchant on Tuesday July 12 2022, @10:35AM (12 children)
Qt marketing has been a schizophrenic shit show for the past sixteen years. The fact that the product survived a Microsoft acquisition and still remains useful is a testament to the strength of open source licensing, yet even today aggressive rent seeking by Qt marketing continues to scare away long time large and small users.
As for the tech, they lost me when they introduced quick/JavaScript, the timing and horrible state of uselessness when it was rolled out suggest to me that the whole thing is/was a Microsoft plot to kill Qt market share.
Still, it is a (the?) great cross platform desktop environment and is very widely used in embedded devices with touch displays. Pretty much anytime you encounter a product that runs on Linux and Windows and OSx Qt will be behind the curtain.
As for having a choice to avoid Python, I don't find that to be the case in AI/ML circles, and the effort there seems to be 90% in the data gathering, 9% in the tool chain setup and less than 1% in the coding. Ironic that they spend so much time waiting for each learning cycle to run and have such an optimization hostile environment. Sure, there is plenty of pre baked hardware acceleration, but how many Python coders does it take to tweak a hardware acceleration module?
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by RamiK on Tuesday July 12 2022, @05:39PM (11 children)
You know, half the apps on my phone are webkit front-ends and they launch instantaneously. I know it's because webkit is constantly cached in RAM for about ~100-350MB worth (platform and model dependent)... But, the thing is, RAM is cheap, abundant and a prerequisite for 4k anyhow so you knew you'll get plenty of it even 10 years ago. So, what were they supposed to do as the market shifted away? Downsize? They had to deliver the product the clients wanted and the clients wanted .JS since C++ devs were too expensive and time-consuming to train.
It's all hardware accelerated. Each and every function. I've used some of those libraries for dataset clustering (nothing fancy. basically a few dozen lines of sklearn and numpy for DBSCAN) and it felt like writing gl shaders whereby the pipeline was so stupid obvious that you'd actually have to go out of your way and forcibly use the python standard library and data types instead of relevant libraries' functions and data types to screw up. And mind you, numpy actually forces explicit casting to do un-optimized operations so you're really going to have to make a conscious effort to fuck things up here.
Are you paying per individual or per working and training hour? Industrial scaling costs is what drives automation so I don't see why you'd measure in number of coders instead of man-hours. C++ devs are scarce and costly. Python devs and faster hardware is cheaper and more readily available. The point is that there's a middle way: Have the low-level written in actual low-level C and the high-level written in actual high-level python/go/flavor-of-the-month. It's the most cost-effective approach as the market repeatedly shown.
Besides, don't forget that very well funded, modern, all-C++ desktop OS is falling behind the antiquated 70s-mainframe knockoff C linux really is. So, there's a fundamental fallacy behind C++ puritanism that isn't easy to reconcile with reality unless you squint real hard to avoid the entirety of your software stack.
compiling...
(Score: 2) by JoeMerchant on Tuesday July 12 2022, @07:12PM (10 children)
>C++ devs are scarce and costly. Python devs and faster hardware is cheaper and more readily available.
I agree about the abundance of RAM and fast hardware - I regularly read entire, fairly large, files into a QString and toss 'em around in RAM before writing them back out, something that would have been considered "amateurish and unscalable" back in 8 bit days.
However, there's a bit of a fallacy about Python devs being cheaper, and I think it's driven in-part by miserly management. Follow me here: in _generic big city_ C++ devs earn $150K/yr while starting Python devs make $50K. Sounds like you can afford 3:1 Python:C++ devs, and I know far too many managers who think that way. But... the first year of work at most jobs is about 80% productive, at best, often much worse, so turnover makes your employees costlier, and those low-cost devs will turn over faster for lots of reasons. Then there's the overhead cost that doesn't scale with salary, particularly with "back in office" management demands - something on the order of $50K per developer / year when you're at a place that does real HR and more than one level of management. So, to retain those Python devs for more than 9 months, you'll be giving them raises to $75K fairly quickly - putting your "loaded" costs at $200K / head for C++ vs $125K / head for Python. Also, don't forget your mythical man month cost of communication, the more devs you have, the more time they have to spend talking to each other to be effective, and all these "cheap and readily available" Python programmers will be needing more of both communication and mentoring time, particularly considering that people who whine about C++ being "too hard" are likely to need much more hands-on mentoring and guidance vs those who can figure stuff out for themselves, given some time and a broadband connection.
I walked into a shop that had about 6 junior devs, heavy Python preference but some C/C++ and Matlab going on too. One of the junior devs was every bit my equal in productivity and ability, though he didn't know how to push back on management when they were being obtuse. The other 5 didn't add up to the two of us, not even close. Some had compensating other talents, like communication with the academic community and grant sources, but all those "cheap" programmers were costing far more than two of me.
I started near ground zero at another startup and hired in two programmers with limited C experience to meet the requirement: "Build a GUI app on OS-X" - that's where I started using Qt, and the three of us learned enough to be productive in it in the space of a few months, and had our first decent looking translation of the Fortran/Matlab mess we were handed within about 4 months from "go." Python wouldn't have gotten us any closer to the OS-X "native look and feel" goal at that time, and I don't think the learning curve for my two hires was particularly steep for Qt - one had some OpenGL experience, the other could at least follow examples in C. Should mention: pickings were really slim in that job market, had to turn away about 8 interviewees who literally couldn't program their way out of a paper bag given sample code that cut an opening from top to bottom. Hiring them to program in Python would have been just as pointless as teaching them Qt.
The real cost of using developers who have trouble with "hard languages" is that they have all kinds of other challenges too... they put 4 levels of nested loop in a place where 3 will do the job, and your execution time is 100x what it should be, and it doesn't matter how great the syntax of your language is, unless you have a library that calculates a value histogram of a volume ready to hand, they will be writing their own loops to get it done. Hardware acceleration is easily overwhelmed by bad implementations.
Re: C vs C++, I have no great loyalty to C++ and objects. One really great aspect of the torturous syntax of C++ is that C "just works" anywhere you drop it in to a C++ program. C++ and objects are really good analogies for Windowed GUI widgets, they're pretty good for containers like strings, lists of strings, hash tables, etc. but they definitely got overwrought in the late 1990s into things they had no business displacing a simple struct from.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by RamiK on Tuesday July 12 2022, @09:24PM (9 children)
If python was a new language I'd say you might have a point. But many big companies have been hiring python developers for a decade now and they aren't in any way looking to replace python with c++.
Besides, don't be so naive to believe your cost analysis is even remotely close to what your boss has in mind when making those hiring decisions. Big companies have whole teams of statisticians and HR writing 40 page cost/risk-analysis reports for every project that weigh-in on everything in such resolutions you wouldn't believe. e.g. There's reports that look into different school districts bus ride times to measure potential performance implications cut against marital state, age and gender.
So, when they look at the C++ hiring market and decide to diversify into python, they're not doing it by mistake.
That's true for all entry positions, C++ included. The reason you're not seeing it is because there's so very few young people going into C++ these days.
But how many good developers does a team need to correct the mistakes of bad ones? Certainly they don't all need to be super stars. And we agree they can't all be terrible at their jobs... So, already, the premise is mixed skill levels. And from there it's pretty obvious you'd want to leverage the tools for the job by having the less skilled work with the training wheels on while having the more skilled work on their end. i.e. The Golang approach.
Quick observation: Note how everything you've listing + parallelism readily falls into dataflow so if we only had a sane, domain specific dataflow language that didn't try to replace C, but to complement it in those very specific use cases, it would have yielded more agreeable results than C++'s OO.
compiling...
(Score: 2) by JoeMerchant on Tuesday July 12 2022, @09:46PM (8 children)
>when they look at the C++ hiring market and decide to diversify into python, they're not doing it by mistake.
Of course that depends on the sophistication of the management group. Credit Suisse First Boston did all kinds of interesting due diligence when acquiring a new spin of a tech that we developed over the course of about 10 man-years, with about 6 man-years in the research and development of the analysis software component. On the hardware side, they flew us up to DEKA to have Mr. Kamen (Segway inventor, among other more significant less well known things) himself give them a read on the electronics side of things and whether or not it really did what we had been selling it for for the previous 20 years. For the software, they basically opened the newspaper and found 10x as many ads for the Microsoft API of the moment as they did for the (then quite superior) Borland environment. So, drop of a hat, they hired a team of 4 - which grew to 8 - to recode the application in the MS API with an initial projected completion of 3 months, growing to 12 before they got it done. They easily paid more for those programmers than they did for the rest of the acquisition, simply because the MS API had more ads in the paper. P.S. if you're involved with investment bankers at any time, you should know that CSFB incorporated the new entity in Delaware, then proceeded to issue debt from their own bank to the company which they had bought with 80% stock, then when they had issued enough debt to make the net value of the organization $0 they reissued the stock giving all the investors checks for $0.01 in exchange for their shares, some of which had invested over $1M of their own money to obtain about 5 years earlier. Me? I only had stock given as bonuses, nominally worth about $80K at one point, I also received a check from CSFB for $0.01. Debt takes precedence over equity, and in Delaware you can pull shit like that and screw the equity holders legally. End of the day: they put a lot more effort into controlling the legal framework the acquisition deal happened under than they did language / API selection.
>OO
Don't forget, OO as a concept comes from the 1980s. Think about the hardware that was available in 1985. OO has been widely abused since, and earned some of its bad reputation - just because you have a buggy whip on your electric sports car doesn't mean you have to pull it out and use it.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by RamiK on Wednesday July 13 2022, @07:40AM (7 children)
I've heard a similar Microsoft vs. Borland account where the decision fell in favor of Microsoft since they were offering free on-site support where Borland weren't even willing to put down a rough quota on paper. Also note that while engineering consider having all your software come from the same vendor as putting all your eggs in one basket, for acquisitions it means having better leverage since the bigger you are as a client, the better are the deals and treatment in general. So, from management's of view, out-spending a single development effort is often worth deepening a service deal. And note how it's yet another side to that "c++ is often chosen to lock out competition" thing: A lot of what we think of as pure technical decisions goes down to job market, hiring options and third-party corporate connections.
Yeah that's pretty typical to the east coast. The legal and finance frameworks in New York and Texas are damn right hostile to startups.
Anyhow, this ties well to my point: C++ isn't simply just a (bad) programming language. It's a specific supply chain of HR, tooling and compiler/OS providers that is not only unjustified on technical considerations, but also involves some dubious business practices. i.e. It's always support package deals here, vendor lock there type things... And to most businesses, especially the small-to-medium ones, it's not only a bad technical choice, it's that entering into that particular ecosystem is damn right hazardous. And when you think about it like that, the whole Nukia-Microsoft and Qt/Trolltech situation doesn't become one bad anecdote. It's simply the nature of heavy weight tools: If you depend on a big language and a big os, you're going to need to be able to deal with big companies. So, unless you are a big company, that's not a bed you want to get into.
compiling...
(Score: 3, Insightful) by JoeMerchant on Wednesday July 13 2022, @11:34AM (6 children)
Thank you for sharing your opinions. We agree on most of the facts, but from the perspective of small startups to medium sized dev teams in larger corporations, I arrive at different conclusions.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 4, Insightful) by RamiK on Wednesday July 13 2022, @12:14PM (5 children)
Yeah I can't argue with that.
compiling...
(Score: 2) by JoeMerchant on Friday July 15 2022, @02:06PM (4 children)
And if you really want to program in Lisp, it isn't all that far away: https://github.com/Robert-van-Engelen/tinylisp [github.com]
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by RamiK on Friday July 15 2022, @07:06PM (3 children)
Meanwhile in Texas: https://www.youtube.com/watch?v=DXvJ8duZqdA [youtube.com]
compiling...
(Score: 2) by JoeMerchant on Friday July 15 2022, @07:38PM (2 children)
Cool. When I was in school my programmable calculator had the one true language: BASIC. Graphing calculators weren't a thing yet.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by RamiK on Saturday July 16 2022, @08:37AM (1 child)
Did it have an alpha-numeric display or a dot matrix? If it's running BASIC, it has indirect addressing and conditional branching so you only need the high-res display to draw graphs...
compiling...
(Score: 2) by JoeMerchant on Saturday July 16 2022, @01:27PM
It was dot matrix but resolution was something like 128x8 and I believe it was only character addressable from the software layer.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end