“Treat your users as you would a class of pre-school children. If they’re all screaming for a snack you don’t necessarily give them one, perhaps a healthy lunch would be better for the underlying need.”
I don't think pre-school children are the only people who are poor at recognising or expressing what they really want, I think that's a fairly universal thing. It's very easy to get an idea about what the solution should be & make a request based on that rather than basing the request on the problem you're facing.
A good analogy I heard recently (more to do with planning your own projects than requesting stuff in other people's, but I think it still works): imagine you have a large patch of grass and it is taking too long to cut. There are a couple of ways to define that problem:
* I need a better lawnmower
* I need a better way to cut grass
The first locks you in to a particular solution (lawnmower), but there may be a better possible solution out there, and the second statement opens it up a bit. So bringing that back to the user request thing, if your user requests a better lawnmower, make sure there isn't some better way to have the grass cut instead.
I agree. I haven’t used notion but the complaints are identical to my lotus notes experience. I wished I could have entered expense reports in a real program fit for purpose.
All the occasions you mention are covered in the blog. The sarin attack is used to demonstrate that even in the best conditions for the attacker they would not be effective in a military sense against modern first tier armies. As a terror weapon yes but the question is why don’t modern militaries plan to use them. It doesn’t rest on perfect efficiency. At this point the US, for example, doesn’t have the quantity needed for battlefield and no procedures for deploying them.
The nuclear weapon question isn't really covered, which is an interesting case because they're also strategically useless to a Modern army -- and the U.S. government knows it [1]. Yet disarmament basically froze 10 years ago.
In the language and framework of this article, I understand why countries with Static armies might feel the need to develop them, but I don't understand why Modern armies which are happy to dispose of chemical weapons aren't equally happy to dispose of nuclear weapons.
Do American and Russian generals think that nuclear weapons will become useful at some point in the future? Do countries like France believe this? The French president hinted that they kept submarines with nuclear weapons configured for terrorist attacks, but the deadliest terror attack in history was carried out with box cutters, so it's hard to imagine how nuclear weapons would help. Nuclear weapons could be useful (if horrific) against a Static opponent, but not a Guerrilla one.
Nuclear weapons have long (since the late 50s at least) had a peculiar calculus that amounts to the prisoner's dilemma: whether or not your adversary has nuclear weapons, there is more value for you to have them, so you end up in a situation where everyone feels justified to have them, even if it's the worst situation overall.
This has created a few paradoxical situations. One of them is that their strategic value lies primarily not in their use (which will not achieve any result) but rather the threat of use, which may be sufficient to dissuade leaders from committing to a war (arguably, this happened during the Cuban Missile Crisis--both Kennedy and Khrushchev blanched at the prospect of starting a nuclear war). Another interesting side effect is that this means that the development of counter technologies produces staunch opposition: nuclear war has to be seen as unwinnable for its deterrent value to be effective.
Part of the motivation for nuclear weapons as a strategic (rather than deterrent) option comes from the lineage of people who see strategic bombing as an fast, cheap, easy way to win a war. For a century now, adherents have predicted that once you started bombing a few cities indiscriminately, you'd easily win a war. And people continue to argue this despite the rather thin evidence for this proposition, and mountains of evidence in opposition.
IMO because they make better strategic than tactical weapons.
I don't see much value in that article - it's basically just Colin Powell quoted as saying that he doesn't think nuclear weapons are useful and that they should be eliminated. But he's just one person, at one time, and he doesn't say anything about how. That's far, far away from a broad agreement among the entire US military and government. It's more like political propaganda than a reasoned analysis.
An actual modern military force in the field should be significantly less vulnerable. You'd have to be quite close to the detonation to damage armored vehicles and troops in good cover. Actually targeting it well is likely to be hard too. It would be nasty to soft vehicles and buildings and anybody outside of cover, but 5 minutes warning could cut that down pretty well.
But they would be quite effective indeed against more strategic targets, from military bases and logistic areas all the way back to factories and cities.
Nuclear weapons provide a deterrent. They can be useful if they are actually used (ex., Hiroshima) but since 1945 the primary benefit has been deterrence.
“but we value choice and freedom over rules and processes.” Who could argue with that? It can sound pretty defensive though, like we know we have a bunch of nearly random stuff that few people can really understand and manage but, hey, freedom. Lisp has always been interesting and there’s always one or two companies in any time interval that are successful, and wildly so, using it. It could also be as much skill, great execution and a market.
It's easy to argue against, and many companies' higher ups successfully do and thus can mandate a monolanguage policy. For Grammarly, I still see them posting occasionally in the monthly who's-hiring threads for Lisp roles, I think they're doing fine.
I wonder if they've since run into more implementation specific issues and have shelled out for one of the proprietary Lisps. SBCL is always improving, though.
My experience is that mono-language policies (or similar tight, top-down controlling of the language stack) are simply a matter of time. All companies enforce that as they mature.
I have been working for two companies that adopted Clojure and Scala early on. They all have, within a period of two to three years, enforced a Java only monoculture with no new projects being written in the aforementioned languages.
The reasons were key engineers leaving for greener pastures and experiencing difficulties with staffing: Not being able to find (cheap) experienced developers, or failing to do in house training due to the lack of interest.
This might be hard to believe, considering that the average HN user would jump of excitement at the chance to learn something new, but then again, those languages were introduced with the JVM as the main selling point, meaning working mostly with Java developers, who are notorious for their resistance to learn _anything_.
> mono-language policies (or similar tight, top-down controlling of the language stack) are simply a matter of time. All companies enforce that as they mature.
Picking the tool just because it gets you lots of cheap disposable developers simply means you end up with lots of cheap disposable code.
Good for the current quarter’s C-suite bonuses, no doubt; maybe not so much for long-term business continuity when that code is critical to continuing business operations.
Something something price of everything and value of nothing.
That has not been my experience. Companies can and should develop a set of technologies that they as an organization feel comfortable with, but this list should be dynamic and should have some diversity in it. Don’t allow every technology under the sun without any vetting, but also don’t force everyone to use the one true programming language, Java.
But that's what I meant by top-down controlling of the language stack: Which in the context of the blog post, would be the contrary of "valuing choice and freedom over rules and processes."
It doesn't have to be a single language, of course. The typical "use / ask / forbidden" matrix for new projects would suffice.
I don't have a problem with that, personally. It is only when programming languages are _exclusively_ being chosen out of non technical reasons that the fun ends and I'm out. Sadly, it happens too often.
I don't really agree that it's a matter of time. There's a pressure, sure, but a stronger counter-pressure is simply having wider product categories and to a lesser extent enough employees to allow for some specialization.
The moment you do web application development, chances are you're using at least two languages if not more. There are some all-JS web companies, there are also some all-Clojure/ClojureScript companies, but neither are very common. Add a database, you might have another language (or not). Add a mobile application, and you're looking at potentially 6 languages just for that product category depending on how you set it up. DevOps? Take your pick, probably at least two used at the typical company that has such specific roles. Survive long enough (many companies don't even last a decade) and maybe make some acquisitions, now you've got acquired product X in some other language -- do you do a rewrite? Another aspect of surviving long enough is the language you picked might have changed a lot. Modern Java, JS, Python, and C++ are all significantly different now than they were not too long ago. Companies with big code bases can't afford a rewrite or mass update, so they have a mix, and developers need to be aware of the conventions of the old versions that may as well be called old languages. Of course some companies will insist on banning the modern styles and idioms even if they begrudgingly update the tooling, for much the same reasons they ban different languages.
Some companies do end up being long-lived and monolanguage though. And where I would agree with you is that individual products will tend to single language policies even if technically they can intermingle (i.e. all the JVM mingling). (Edit: and seeing your other clarifying comment, yeah, top-down control over letting teams make most of their own decisions probably is inevitable with time, this expands far beyond just language choice though.) Sometimes that language is Common Lisp! There are things that can be done to influence what it's likely to be, if it is to be. The "simplest" is probably just having a big enough, complex enough, and important enough product that no one's going to authorize a rewrite for even if the will and expertise to do so appeared. Then the monolanguage will be that language -- whatever a company starts with has a good chance of becoming The Language, but if you're starting with a not so popular language you're in danger of having it changed at some point and will need to protect against that if you care. (This to me explains Reddit's rewrite off of Lisp early on, the code that was written wasn't that big or complex yet, and also explains Facebook's lack of move off PHP and herculean efforts with Hack to compensate. But as companies Reddit seems much closer to the monolanguage endpoint than Facebook -- Facebook simply has way more engineers and a lot more projects going on.)
Another driver is what you highlighted, lack of interest, or indifference, and is probably the main one until you reach a "too big to change" tipping point. You need to have someone who loves the particular stack, or (also?) who hates the alternative stacks, because if you don't someone else will eventually come along with enough ambition and motivation (either from hatred of current stack or love for a new/alternate/more familiar stack) and the stronger passions will win the day with the indifferent employees just going along with it.
I don't know what they are doing currently, but the article from a few years ago said, "We run them on stock Linux images deployed to AWS. We use SBCL for production deployment and CCL on most of the developers’ machines."
Once a large application works in some environment, you usually need a good reason (such as lower overall cost or inability to keep it working) to switch. They hit a few unlikely bugs and have already developed solutions for them. If they switched, the odds are excellent that they'd hit new unlikely bugs that they haven't found solutions for, and it's hard to have a smaller cost than SBCL or Linux. So while they may have changed, there's a reasonable chance they haven't.
Right, but you at least need to experiment with the other runtimes first before you can even determine whether there might be a good reason (like not having to mess with tuning a bunch of GC flags anymore, one of the sells for Azul's proprietary JVM) apart from a forcing situation (like Oracle shedding updates and support contracts on their Java8 VM, forcing people to OpenJDK / Azul's OpenJDK build + cheaper support contract). In many cases it doesn't take much effort to spin up a mirror environment and see if the alternative "just works" and what its characteristics are apart from that.
So my curiosity is really whether they found further issues with SBCL later, or if it's been a champ since, and if at any time they investigated developing with SBCL/CCL and deploying with (maybe developing sometimes with) Allegro or LispWorks (which at least if they hit new bugs with, they have a support contract to help). The thread from last year includes one report from another individual about swapping deploying with SBCL to deploy with CCL because of resource savings. I'm just curious in hearing about what trajectories people have taken.
While I agree with your sentiment that the changes were intrusive, from the article they weren't actually ads in the strict sense. No Ugg Boots or Rolex Replicas. They were helpful links to knowledge articles or documentation, from what I gather.
Could be wrong though.
That's gotta be a tough position to be in, having raised ~ a lot of money and having the pressure to do a suboptimal move to please the investors.
