I'm not disputing anything, but would it have killed arstechnica to include some primary source links to back up their assertions?
842 karma · joined October 30, 2021
That's a lot of people contributing.
How many of them will be less willing to contribute in the future, and less productive when they do if a sizable portion is in Rust? Maybe there'll be more contributions and maybe there'll be less. I don't know. If you've managed to develop a community of 1200 developers who are willing to advance the project why upset the applecart?
That's not recent at all. They've, for a long time, had large allocations to PE funds.
https://en.wikipedia.org/wiki/U_and_non-U_English
This was a, tongue in cheek, distinction between the language used by the posh and by the aspiring-posh. It's seems analogous to the OP's sense of boss vs non-boss language and diction, which I believe exists.
The best definition of "culture" I've ever found is "how we do things 'round here". It's valid in both the large and in the small.
Of course, why and how we converge on those norms is mysterious, and the anthropologists, the psychologists, and etc. can have a go at explaining those parts. I can't.
Unfortunately, it's somewhat of a religious argument about the one true way. I've worked on both sides of the fence, and each field is equally green in its own way. I've use OCaml, with static typing, and Clojure, with maybe-opt-in schema checking. They both work fine for real purposes.
The big problem arrives when you mix metaphors. With typing, you're either in, or you're out - or should be. You ought not to fall between stools. Each point of view works fine, approached in the right way, but don't pretend one thing is the other.
I don't agree with that. If I want to add two numbers I'd like to write `a = b + c`. I do not want to write the machine code that effects the same result on whatever computer architecture I'm targeting. Precisely _how_ one adds two numbers is accidental complexity. Whether they need to be added, and what numbers should be added, is essential complexity.
Fortran removed that accidental complexity and left the essential stuff in place. There were no fuzzy lines.
I find myself in the uncomfortable position of sympathizing with both sides of the argument - a yes-but-no position.
Fortran made that distinction clear. The compiler handled the accidental complexity of converting instructions to code, but never really obscured the boundary.
Take VB as an example from wayback. For the purposes of presenting a simple data-entry dialog, it removed the accidental complexity of dealing with Windows' message loop and resource files etc., which was painful. The essential complexity was in what the system did with the data. I suppose that the AI steering that needs to happen is to direct the essential down the essential path, and the accidental down the accidental path, and let a dev handle the former and the agent handle the latter (after all, it's accidental).
But, that'll take judgement - deciding in which camp each artifact exists and how it's managed. It might be a whole field of study, but it won't be new.
It's under stress at that PIK level.
As an aside and generally, a problem that bothers me: the economics of AI replacing knowledge workers doesn't add up. If all knowledge workers become manual laborers the market for AI augmentation products shrinks. Manual laborers don't need a great deal of AI augmentation - almost by definition. If all the knowledge workers go away what's then the market for the AI suppliers?
Also, the feedback loop. If the next 10 generations of AI products are based on the output of the last 10 generations, with a diminishing proportion of human-generated content, is there a risk of a negative feedback loop with an ability to "judge" also diminishing in a similar way. (I'll be candid and say that I believe, but don't know, that humans, at the upper margin, are better at willing and judging than any AI. Let's not underestimate the willing piece. What's the best way to do something can only be judged in context of what you want to achieve. It's a bazillion factor optimization problem.)
DRY is a comforting illusion, based on a misapprehension of how mid-scale enterprise code is actually developed. DRY's assumption is that there's sufficient organizational capacity to coherently design the "thing"; and that only one thing should be done in only one place according to some overarching vision - observationally, a vision missing in most mid-scale companies. My experience is that there's almost never a coherent, managed design in any but the smallest and the largest organizations. The former because of social scale, and the latter because of a necessity to deliver at scale.
In the middle bracket, it just doesn't happen.
Mid-scale applications are mostly developed in a form of loosely managed anarchy. Different teams, different incentives, different approaches - all without a competent traffic cop i.e. an architect. Those 10x architects just do not exist in the mid-scale companies, in my experience. The good ones move to high-scale companies, and the peter principle kicks in below.
If your team is responsible for a feature: repeat yourself as much as you need in order to ship the product. If it's really important, you'll come back and correct it later - within you sphere of responsibility and according to your incentives. Absent a competent architect's direction and managerial instruction, just repeat yourself as often as you need in order to keep the context sufficiently local to deliver what you're paid to deliver.
It reflects well on both men.
Yes, I know they had one truly horrible year. But, they righted the ship.
I worked for a company that ran 10bn in revenue, with thousands of users, and Heroku just hummed along. It ran our business.
The benefit to us was the lack of problems that occurred at deploy time. Heroku's orchestration of removing old dynos, adding new dynos, and their network control was spectacular. DB's were updated, or patched, without downtime. It truly was impressive.
We moved to a combination of AWS and on-prem, and the overhead of providing what Heroku previously provided is quite large.
I'll remember it fondly, and miss it a bit too.
Excel used to be, and probably still is, the primary competitor to enterprise-developed apps - a lot of businesses run on it. But, that was a locally deployed phenomenon, with an added ability to deploy it somewhere else by simply emailing the workbook to someone else.
In your organization, how do your managers turn their code into working software?
If the bank wants to waste time and energy with this nonsense, that's their business. As long as nothing real bad can happen, let them at it.
I don't think I'd be inclined to do the "bank's job" when it affects me not a bit. As sure as eggs is eggs, I wouldn't spend hours on the phone or chatline explaining what their problem is. It seems like it's their problems and not the OP's.