The author is critical primarily of Elm's governance and processes, and claims that these are what killed the project. I don't think that's entirely true. There was a recent interview with the creator of Elm here.
I'd encourage everyone to watch that as a grain of salt to TFA. It seems like the project leader felt he was being taken advantage of, and was just not getting out as much as he was putting in. That's his decision to make and he doesn't owe anyone anything. If you want continued support, pay up.
Elm's governance and process are what made it such a delight to use. Instead of allowing the full spectrum of bad ideas in frontend development to slowly make their way into the language, the authors carefully curated a coherent set of good ideas. They said no to a lot of things, and cut out as often as put in. This is going to piss off a lot of people because it means saying no to a lot of people. Saying yes to those people would make the language worse; you can't have it both ways.
> I'd encourage everyone to watch that as a grain of salt to TFA. It seems like the project leader felt he was being taken advantage of, and was just not getting out as much as he was putting in.
That's two different topics. The work situation Evan had with NRI is completely unrelated to what he and the core team decided to shape the community into, which is the subject of TFA's criticism.
> That's his decision to make and he doesn't owe anyone anything.
In the world of emergent programming languages, the language author isn't the only one taking risks. Early adopters do have skin in the game, and their work spent growing the ecosystem is valuable. Sure, I get that Evan doesn't owe work to anyone. However, he also made sure that everyone in the community had to rely on him, and that's the issue.
In retrospect, Luke Plant correctly identified the risks Elm's community management style created, and eventually these risks came to materialize.
For these reasons, I can't advise people to touch anything Evan does in the future.
> Elm's governance and process are what made it such a delight to use.
I guess you haven't been personally contacted by a member of the core team trying to steer you into changing course on a technical topic. That interaction was not delightful.
> For these reasons, I can't advise people to touch anything Evan does in the future.
> I guess you haven't been personally contacted by a member of the core team trying to steer you into changing course on a technical topic. That interaction was not delightful.
I agree, the community itself has a sort of toxic positivity to it, where criticisms are verboten and one must act like everything is good.
>>>> That's his decision to make and he doesn't owe anyone anything. If you want continued support, pay up.
Completely correct, and the users of Elm also don't owe him anything. They are free to hold their opinions and free to move away from Elm ...and they did.
In the end Elm will be remembered for being an extremely interesting technology but mainly failed in industry due to poor project/community relationship.
Sometimes interesting tech just isn't the right fit for business. C'est la vie.
If the features were actually cut, then that would be a separate discussion point. However, that was not the case, the author directly says that the features are still there but restricted to blessed set of users. So, author considers elm to be crippleware
They threw people out of the community if they even created forks of the language, and they literally hard coded in their buddies' projects to use compiler features that everyone else couldn't. "Rules for thee but not for me" does not inspire much confidence in using a new niche language, much less using it in production.
Your defense of the Elm leadership team is far more vague than the article criticizing it. He is very specific about limitations of the platform and the behavior of the leaders. You, on the other hand, are very hand-wavey in their defense "sometimes you just have to say no and piss people off". Do you believe these decisions were good ones? Do you believe they were done the right way?
Whether or not someone has written up or is willing to write up their opinion is a good way to determine how seriously to take that opinion.
Using that as a first pass has led to more time engaging with thoughtful people about well considered ideas, and less time listening to the noise that shows up when you solicit opinions.
Code review should really only exist to guide contributors to the owner of the code they are changing. A new contributor shouldn't need to know the team structure and history of the organization to get changes in. That should be solved by the tooling. Do whatever you want, and the tools will force you to bump into the right people before you can merge.
It's very strange that most companies (maybe GitHub is to blame for this) have something like a free-for-all where anyone can approve anything, as long as they themselves aren't the author. As other comments have mentioned, this reliably creates reviewer cliques as engineers seek out the path of least resistance to get changes in. Those who haven't figured out the game often lose hours of their time to nitpickers and pedants without anything better to do.
This also results in a slow decay since most of the code ends up being written by people who are good at getting code merged, and not people who are good at building the software.
We only infer value through market transactions, and we are actually inferring a bound on the surplus rather than the precise value being exchanged. It does make sense to draw distinctions between different kinds of value, and often "intrinsic" and "extrinsic" are used, even if they may not be great terms. I can give a few examples.
- In options pricing. The intrinsic value is determined by what the contract says happens at expiration. The contract is enforced by the authorities like any other legal contract. The extrinsic value is the name we give to the value that must exist to make up the difference between the intrinsic value and the current market price. It's sort of like the "dark energy" of the option.
- Gold is said to have intrinsic value because it can be used as a material in ways that other material's can't. It can be used as an input to whatever industrial process regardless of what humans have to say about it. There is additional value implied by the price of Gold, just as there is with the price of an Option.
Intrinsic value means something like "if the other market participants disappeared, the value the last person holding the thing could still get from it". Maybe as a matter of semantics, you would exclude this from the "economic perspective". In the case of Bitcoin, intrinsic value may just not exist (as you seem to imply).
> "if the other market participants disappeared, the value the last person holding the thing could still get from it"
and money has no use/value if there is no one to transact with (i.e. no other market participants)
So if we were to agree that intrinsic value is the usefulness of something but with the exception of any purely economic/market use, then to use "it has no intrinsic value" as an argument for why something would not be a good money (as the author does) makes no sense, as it ignores the exact usefulness that would make it a good money.
A contacts list is a superset of the publicly available connections that would make up a web of trust. Out of all my contacts, there are a few people that I would be willing to vouch for. As in: declare publicly that I know who they are, and reveal the name that I refer to them as.
That pet name may be different from person to person, but that's fine. Alice might call a public key "Bobby's Public Key", and Charlie might call it "Robert's Public Key". I can make sense of those attestations when I'm trying to verify that I have Bob's key, and assign it my own pet name. If Alice or Charlie weren't willing to publicly attest to the Bob-ness of the same public key then I wouldn't be looking at their attestations.
You could replace "employee performance" with "value to the company" and the same argument would hold. Performance is difficult to measure, but we get a good estimate of value to the company any time someone receives a competing offer and drags their manager to the negotiating table.
The amount of money the manager is willing to match is the perceived value to the company. This is how the company actually behaves (we know for sure whether they match the offer or not) and that behavior implies a value to the company, regardless of what anyone says in performance review season.
> The amount of money the manager is willing to match is the perceived value to the company.
This assumes the manager is irrelevant here. But we all know that different managers (or non-managers) can communicate value differently for the same employee. So this metric can't be solely measuring the value of the employee.
You are talking about value as some intrinsic quality. I'm talking about value as a belief that is subjectively assigned, and that we can infer from actions. We can all agree on the actions, and we can agree on the possible beliefs that an action can imply.
The action to not match an offer implies that the company believes the employee adds less value than their new offer. If the company believed the employee was adding more value than their new offer, they would match the offer to keep the employee.
A company isn't a single rational agent. It's made up of people performing different functions. But behaving irrationally is a categorically bad thing for the company to do, and the leadership has a fiduciary duty to prevent the company from acting irrationally or otherwise not in its own self interest.
The manager may matter here, but the leadership is supposed to be creating a management structure such that the company acts rationally to make progress towards set goals.
It would be a toxic mix of stoicism, “survival of the fittest” mentality, affirmations of harmful stereotypes (ironically; mostly harmful to the people who feel validated by hearing it) and vague notions of being a leader and working hard-
Most people, especially supporters, don’t realise that Tates rhetoric is harmful to men more than women: you’re not a success unless $materialThing and $respectOfRandoms. Completely betraying the very real success of being genuinely respected and well regarded by your community and having a family that you support and love. If you took his advice seriously, you’d be very lonely.
Stocisim is actually the only part of the toxic blend that has real merit. Although it encourages disregarding one's emotions and feelings and people who practice classic stoicism were found to be detached from reality more often, uncertain about their relationships and likely to develop mental health issues.
The mix is toxic, but it had to be at least a little paletable.
Stoicism has critiques but that wasn't what I wanted to say, just that his way of thinking would lead to most men being deeply dissatisfied with their lived.
A lot of what he says goes directly against the protections of your mental comfort afforded by a stoicism mindset.
This is strangely popular, but wrong impression. If you read the origin sources (Markus Meditations or Seneca's Letters to Lucilius) it's easily deducted from there.
It's not about disregarding, it's about understanding that what you feel and what you are and do are two distinct entities.
Stoics view emotions as a two-stage process: the involuntary experience (natural emotional reactions) and conscious rationalization (examining and responding to emotions thoughtfully).
The initial mental impression (phantasia) is an inevitable component of human responses. The point of Stoic training is not to achieve disregarding emotions, but to focus on how one reacts to them, specifically whether one reacts automatically to them. It's the opposite of disregard, because they merit a very close inspection and when possible a reasoned reaction.
The Cognitive Behaviour Therapy is build on these principles and many studies (and meta studies) prove these principles work to improve many disorders:
Most of the things Andrew Tate pushes are not harmful. Stoicism isn't bad, it's massively undervalued in today's society. I'd say that most of today's modern sensibilities are the toxic influences that end up seriously harming the mental health of millennials and zoomers.
It's super easy to tell: the more in touch they're with them, the less reasonable they're, the more they get hung up on irrelevant things and have outbursts about completely asinine topics. They always have to be treated with silk gloves and if someone doesn't they'll try to get them cancelled.
Tate just adds silly amounts of narcissism as well, what people call "being alpha" and "sigma" right now. And that obviously ends up harming other people.
> the more in touch they're with them, the less reasonable they're, the more they get hung up on irrelevant things and have outbursts about completely asinine topics.
I dont disagree. It's also true for the people he teaches.
But they didn't become like that through Tate. They were already brought to that point by our society massively overvaluing things that are effectively harmful to us as productive members of society.
Tate just uses this issue in this messaging, and profits from simps that believe he can solve it for them. Even though the fact they're going to a "daddy figure" as grown men to have it solved is part of the issue in the first place.
Why would they believe he can solve it for them, if he can't even solve it in himself—or that he can, but has chosen to retain them? It seems more likely that these are fairly off-putting traits, and he attracts people who naturally have those traits themselves, because they see him as successful because of them.
A lot of people are falling for the narrative that taxation has a coherent structure, and all taxes have good reasons, or go towards good causes. It doesn't work that way.
Taxes are just a wealth transfer item that can be used as bartering chip in the collective negotiations we call politics.
One group wants something (doesn't matter what it is) but let's say cannabis legalization. Another group might have no reason to care about that, but since the status quo is illegal, might as well extract some value from the first group. Never give up something for nothing. As such, cannabis taxes are included in all of the legalization bills.
This is the important part: the reasoning comes afterwards. Cannabis will make people unproductive, it will increase car accidents, the whole place will smell like pot, etc. Those are all reasons. There's data in some form to support all of them, but none of them are the real reason, which is that it's just good business to ask for something in return, and take as much as you can get away with.
The classic micro/multi repo mistake is reaching for more repos when you really need better tooling and permissions on single repo. People have probably wasted millions of engineer-hours across the industry with multiple repos, all because GitHub doesn't have expressive path-level permissions.
If someone says "just", it means they believe the presented solution is less complicated than some existing proposal.
That conversation should be a significant part of software development, and usually the answer is "no we can't just do that, because it wouldn't do what we are trying to do", or "yes, but it's not actually as simple as you seem to believe". Sometimes the answer is "yes, we can just do that" and everyone should be glad when that is the case.
If you can't handle normal engineering criticism, then you are an imposter. Real engineers generate alternatives, and evaluate alternatives proposed to them.
I really think you should consider what is implied by the word "just". When you say "no we can't just do that" it implies that you think someone will have missed the obvious. This may fall under "normal engineering criticism" to you, but I can assure you that some people will not see it as such and they won't like it. Which makes it a poor fit for good team communication. It will probably also make you disliked. It's obviously not always an negative word on its own. In your "yes, we can just do that" example it's fine. It's, however, also unnecessary as you could say: "yes, we can do that" and retain the full meaning.
> If you can't handle normal engineering criticism, then you are an imposter.
It's not normal engineering criticism though. "Just" is (in)famously known as a term that you use when you're overconfident while missing the whole picture. In many universities around here they will teach you about the dangers of it. Because it's really not good engineering to not do your analytics before suggesting solutions. I think most of us are guilty of using it. In my current team we laugh about it. We have a sort of swear jaw mentality when someone uses the term unironically, usually called out by the person who did it themselves. It's now a term we mostly use it as an internal joke, however, and people are never going to miss an opportunity to call the most complex challenges "just" in the most hilarious way they can.
https://www.youtube.com/watch?v=0SUM4869ODc
I'd encourage everyone to watch that as a grain of salt to TFA. It seems like the project leader felt he was being taken advantage of, and was just not getting out as much as he was putting in. That's his decision to make and he doesn't owe anyone anything. If you want continued support, pay up.
Elm's governance and process are what made it such a delight to use. Instead of allowing the full spectrum of bad ideas in frontend development to slowly make their way into the language, the authors carefully curated a coherent set of good ideas. They said no to a lot of things, and cut out as often as put in. This is going to piss off a lot of people because it means saying no to a lot of people. Saying yes to those people would make the language worse; you can't have it both ways.
reply