sinnsro

Shopify uses Ruby extensively and I don't think they are considering moving away from it (at least I am not aware of anything).

As a consequence, they have made lots of contributions and improvements to Ruby infrastructure. That includes two JIT compilers (YJIT and ZJIT) and a new parser.

FWIW, he even riffs on his own boss when referencing the "slop grenades".

I want to think that ConTeXt is that successor. While has a slightly different markup from LaTeX but is still familiar enough, I find it typesetting/markup to be both consistent and flexible.

It has the added bonus of being a monolithic tool —it packs everything one needs to typeset a document— but it is not as adopted as LaTeX, so there is not a lot of material on it.

Reading your post, it is clear to me that management and engineers will rediscover the theory of constraints at some point if they can connect the dots.

I fail to see your point, as the base pipes can be combined with blocks and wrapping the target function into another function.

Although, IMHO, if that many operations are crammed into a single pipe pass, then something is amiss.

The base pipe has an underscore as a placeholder. From the docs:

Usage:

     lhs |> rhs

Arguments:

     lhs: expression producing a value.

     rhs: a call expression. 

Details: [...]

     It is also possible to use a named argument with the placeholder
     ‘_’ in the ‘rhs’ call to specify where the ‘lhs’ is to be
     inserted.  The placeholder can only appear once on the ‘rhs’.

> we wanted Delphi and got Haskell instead

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.

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.

> A very minor nit: Julia is a compiled language

Caught. Should have just listed the usual suspects (C, C++, maybe Rust nowadays?).

> and the best 2 solutions were in Julia. C++ was a close third, and Rust after that.

Awesome. Which type of problem was this, if you can share?

Now that the money is gone

What are we supposed to do?

After all that we've been through

When everything that felt so right is wrong

Now that the money is gone (money is gone)

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.

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.

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].

_________

1. https://deming.org/explore/fourteen-points/

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.

[/s just in case it goes over someone's head]

Again, another great move sponsored by bean counter boy Tim.

> 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.

______

1. Alexis King's reply to "Why do common Rust packages depend on C code?". Link: https://langdev.stackexchange.com/a/3237

Thanks for sharing! Every time I see a post about Elixir and how it Just Works™, I get an urge to learn and build something with it.

Another outstanding decision vetted by Tim Cook.

In all seriousness, finance people see everything through the lens of margins and money primarily. Since any company's function is to deliver value to its shareholders, if allowed, bean counters will scorch the earth for it.

Ultimately, this is at odds on how Jobs approached things, i.e., money was not the end all be all.

I wonder if it is even possible to get such measurements. With so many things affecting output, how can one establish a baseline or avoiding to compare apples to oranges?