> However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release.
Users also request those features. You said yourself that programming languages are products. In that sense, people are always evaluating them through the lenses of utility (the economics concept), and if they have to pick between two languages, with similar capabilities, they will pick up the one that maximises that utility.
This to weird design decisions getting inserted into the fabric as a consequence (the current state of C++ comes to mind). And given developers are too opinionated about everything, we get politics as a side effect.
Ideally Swift would have been something with compile speed of Delphi, its RAD capabilities, strong typing with a good enough type system to support the transparent migration path from Objective-C, and that was it.
Instead we have quite a few type systems ideas going back and forth, with some hard changes across language versions, as if playing with Haskell type system, and GHC feature flags.
> Users also request those features.
Some users request those features, most of them come from team themselves roadmap, regarding what cool features to add next.
Then as politics get into the game, naturally the process of what features land into the stable implementation, and what fail by the wayside depends pretty much how they get pushed into adoption.
I am not sure if the average executive is dumb or just shortsighted. Imagine making decisions based solely on the optics of the Pareto principle when corporate history itself says that is fraught with risk.
Bean Counter Tim is going to drive Apple into the ground before he does anything useful. Just look at the current state of the ecosystem when it comes to UI/UX and software stability.
While others have mentioned plenty of reasons, for this particular case I want to highlight 3 things:
1. Julia has great tooling for operations research/linear programming. JuMP provides an standardise interface to interact with solvers (e.g., Gurobi, CPLEX) via wrapper libraries.
2. I like its overall ergonomics. It is fast enough that a programmer might not need to use a compiled language for performance. The type system allows for multiple dispatch. And the syntax is more approachable than say Python for matrix algebra.
3. I would say the performance is overstated by the community but out of the box it is good enough to avoid languages like C/C++ to build solutions. The two-language problem in academia is real, and Julia helps to reduce that gap somewhat in certain fields.
A very minor nit: Julia is a compiled language, but it has an unusual model where it compiles functions the first time they're used. This is why highly-optimized Julia can have pretty extreme performance.
> I would say the performance is overstated by the community but out of the box it is good enough to avoid languages like C/C++ to build solutions.
For about a year we had a 2-hour problem in our hiring pipeline where the main goal was to write the fastest code possible to do a task, and the best 2 solutions were in Julia. C++ was a close third, and Rust after that.
I would not call that very unusual, even Lisp and Dartmouth BASIC used such approach, BASIC only got the fame of being interpreted when the compiler was thrown away to fit the language with 8 bit home computers ROMs.
Or anyone living in any JIT ecosystem for that matter, when it actually kicks off is an implementation detail, and some ecosystems even have configuration options.
It was roughly "given this dataset with 100 time series, write code to calculate these statistics as performantly as possible. Make one single-threaded version and one using 4 cores."
The C++ versions were around ~250 lines long, and the developers generally only had time to try one approach. While the Julia versions were around ~80 lines long, and the developers had time to try several approaches. I'm sure the best theoretically possible C++ version is faster than the best Julia version, but given that we're always working with time constraints, the performance per developer hour in Julia tends to be really good in my experience.
The core issue with the article is that author mixes up bad management and "fog of management" with the fact that financial results have a disproportionate amount of influence in how things are organised. Every team and employee should do their part to contribute to the financial targets every quarter and within the fiscal year. Which clashes with Deming's points 11b and 12b [1].
The problem is that "every team and employee doing their part to contribute to financial targets", as-stated, is liable to produce suboptimization.
A person on the assembly line can "contribute to financial targets" taking a shortcut, reducing their local spend, but which emerges as a much more expensive problem down the road.
So it's true that every employee should do their part to contribute to financial targets, but defining "their part" is the hard part, something only management can do, and that MBO obscures and tries to make as simple as waterfalling the goal from above.
> Every team and employee should do their part to contribute to the financial targets every quarter and within the fiscal year
The inevitable result of this is however the devaluation of the future. Eg if the statement was true, it'd be the R&D workers responsibility to hand in their resignation ( or their managers layoffs) if their product won't get paying customers within the same fiscal year... And the same applies to any other long term expenditure/investment that company might be considering. E g building a new fab/production line etc pp
So no, that statement of yours is not actually true. It should not be entirely ignored, but it should not become a leading cause unless you want to run the company in the ground.
The statement holds true for a broad set of companies and management styles. I speak from personal experience: the wrong incentives are always there, and they run counter to many things listed by Deming. The obsession with "financial impact" is there with varying degrees, even in functions where it is hard to quantify said impact.
It might not apply to R&D-heavy companies, but we do see engineering companies pivoting into more finance-oriented management. Boeing is one such case and look at the damage.
Executives who focus on the financial side of things and do not care about correctness in operations are the ones steering lots of companies nowadays. Boeing is a good example/case study on how financialisation eats up companies from the inside by emphasising monetary results over actual engineering.
God forbid paying the masses a living wage or allowing them access to things their forebears had. They will own nothing and they will be thankful for it.
> It doesn't mean that people haven't tried or even succeeded. Android was successful in multiple fronts in replacing C. Its "intents" and low level interface description language for hardware interfaces are great replacement for C ABI. Windows' COM is also a good replacement that gets rid of language dependence. There are still newer OSes try like Redox or Fuchsia.
I am not sure I buy this from a system perspective, especially when taking this[1] into consideration.
Please elaborate.
> However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release.
Users also request those features. You said yourself that programming languages are products. In that sense, people are always evaluating them through the lenses of utility (the economics concept), and if they have to pick between two languages, with similar capabilities, they will pick up the one that maximises that utility.
This to weird design decisions getting inserted into the fabric as a consequence (the current state of C++ comes to mind). And given developers are too opinionated about everything, we get politics as a side effect.
reply