To be realistic about it I stopped calling things I don't understand "bullshit" and "terrible". What I use instead is "I don't know why it is that way", "I don't understand" and finally realization "OK, I don't want to spend my time on understanding this because I have better things to do".

I would love to spread this approach in developer community. Be honest that you don't understand stuff and you don't have time to learn it because you have better things to do.

Though if someone is paying me to do something in a language I will put my time into learning it. If it is just a hobby who cares that it is not easily grasped, I don't have to spend time on it.

You're entitled to your opinion, but most of it is 100% bullshit in my eyes.

I'll use Haskell as example. The ecosystem is a mess. `stack` is admirable effort to make development palatable, but it's ultimately a technical solution papering over a cultural issue: The community [including the language designers!] have 0 respect for backwards compatibility.

The node ecosystem is seems to be the worst at this. Not only is there no real respect for backwards compatibility, but it seems that the real purpose for a lot of the stuff is created is to 1) bolster the creator's resume and status or 2) to get funding from a VC. Certainly all ecosystems have that to some degree, but node just feels like the worst, by far.

I've written all the major languages with this problem professionally [except node]. It's not that I don't understand. It's that I did spend my time on understanding this and it was such a complete waste of time in retrospect. The solution isn't to spend more time learning the tooling. It's to only work in ecosystems that don't waste your time.

edit: Any ecosystem that has some notion of a "langauge version manager" is a big clue to me that I'm about to spend a lot of time learning a bunch of non-portable information.

Which ecosystems don’t waste your time, according to you?

Just curious.

Java is pretty good. Go. C because of the nature of how libraries are shipped. Just as an example:

"0 - libcurl 7.1, August 2000

1 - libcurl 7.5 December 2000

2 - libcurl 7.7 March 2001

3 - libcurl 7.12.0 June 2004

4 - libcurl 7.16.0 October 2006"

"During the first seven years of libcurl releases, there have only been four ABI breakages.

We are determined to bump the SONAME as rarely as possible. Ideally, we never do it again."

This is the attitude of what I want out of my dependencies.

Have you had an experience with Cargo, the Rust package manager? It is an absolute joy to work with, clean repeatable builds, and fast for what you are getting (speed of C++ with the correctness of Haskell).

Not really. I've played with Rust but haven't used it in anger. One thing I've noticed about my programming style is that I LOVE to learn about new languages and language features. Using a language like Go or Java forces to me concentrate on the problem at hand [which almost always something where GC is fine for what I'm working on]. That said, the Rust ecosystem seems pretty solid [except the edition stuff, that makes me very leery...]

Editions exist to guarantee forward compatibility, it's actually a really good solution to a hard problem.

It started at major version 7?

First release was major version 4, same as curl (using that name) itself.

https://curl.haxx.se/docs/history.html

I’ve been happy with the Elixir/Erlang world. Especially as a scripting/dynamic language it’s been remarkably stable from a "don’t waste my time" perspective. Core system features from years back work, and generally work with updated libraries.

Well despite a few major changes to Phoenix, but that was mostly changes to the naming patterns. It also switched to web pack which I consider a pain point of following JS development. With LiveView I only have a dozen JS deps and ~50 lines of JS so now I can get off the JS ratrace too! Well github complains about outdated npm deps. I should make a GH action for that or something.

Ruby is quite practical.

It has a decent standard library (so you don't waste tons of time evaluating/choosing libraries for basic things) and has a simple package management story with bundler, which separates what libraries you want (Gemfile) from what specific versions you happen to be using (Gemfile.lock).

This, a hundred times over.

The more experienced I get, the primary transformation I see in myself is being less dismissive of existing work that I wasn't involved in.

Were they insanely time crunched? Was this a prototype by a lawyer who painstakingly taught himself Excel and then taught himself Python again to port the Excel sheet he had into a service? Were the abstractions they chose based on whatever was the best practice at the time?

I've stopped scoffing at a simple app that I think I can "hack together in a weekend". No I can't. There are complexities and corners I don't see at the moment.

> I've stopped scoffing at a simple app that I think I can "hack together in a weekend"

How do you get your PM to stop planning that way, though?

Find a better PM.

The competent ones I’ve worked with invariably convince engineers their “weekend project” will take at least 2 months. They start by getting the engineer to spend an afternoon enumerating all the tasks they need to complete to implement and ship it.

Then the engineer takes 3 months, when they would have taken 6 without help from the PM. This is because the PM follows up, and helps them be ruthless with the requirements list.

I agree we should be more positive, but I think it's a mistake to think that if we understand enough, we stop calling things bullshit. I think that there are two common meanings of the term that are analytically useful.

One is Frankfurt's, as explained in his book On Bullshit [1]. His definition is "speech intended to persuade without regard for the truth". There's a lot of this in tech. Ego-driven posturing. Blind ideology. And a bunch more that comes from American business culture, where we have a special legal category for bullshit so obvious that it legally doesn't even count as false. [2]

The other is what Lean process experts call Muda [3]. It can be translated as: "futility; uselessness; wastefulness". But bullshit is often a perfectly good translation. As the original article points out, there can be an enormous amount of wasted effort coming up to speed, like "the footguns that will cost me a day to debug". Just yesterday I spent a day on what turned out to be a bug from 2015 that hundreds of people have voted on, but the tool maintainers have refused to solve because it doesn't fit with their initially chosen architecture. I am comfortable calling that bullshit.

I also think your "I don't have to spend time on it" bit is, well, let's gently call it "erroneous". Languages aren't like books, where a reader's choices are infinite. There are a finite number of languages popular enough for practical use, and every one of them was built with the express intention of having a lot of people use it. Every one of them has people who make their living from maintaining it, and many are purely corporate profit-driven considerations. When people set out to insert themselves into other people's lives, there's an inherent level of responsibility there. It shouldn't be handwaved away.

[1] https://press.princeton.edu/books/hardcover/9780691122946/on...

[2] https://en.wikipedia.org/wiki/Puffery

[3] https://en.wikipedia.org/wiki/Muda_(Japanese_term)

The ecosystem around a language is not different because each language needs a wildly different ecosystem. It’s mostly an accident of history where different tools and techniques are adopted by different communities over time.

For me, part of the problem is the fixation towards a "language ecosystem" per se that people seemingly have come to expect. What has happened to the idea that you could link object files/libs compiled from any number of different programming languages, all adhering to the OS's platform ABI? Where you the developer, and you alone, decides which language to use for coding a particular aspect of your app based on the respective language's fit to the problem in a polyglot fashion? For example, if your app needs a parser for a config language, say, you're free to use Prolog with its built-in parsing DSLs. Similarly, if your app involves DBs or GUIs, etc. PLs today are huge, unportable monoliths with shiny web sites when the point of a standardized PL, for me at least, has always very much been that it fences you against overreaching vendors, language world domination aspirations, and churn disguised as march of progress.

Because once you get beyond the simplest runtimes maintaining compatibility between things becomes difficult fast and more complex runtimes have enabled a lot of things people want, like actual portability between systems, JIT compilation, garbage collection, etc. Most language runtimes have native interop these days but it’s always a worse experience all around than using language-native libraries.

... C++ with CMake, oh wait Ninja, oh wait nevermind, and also you have to catch up on a bunch of random bloggers and various conference recordings to have a clue as to what are the community recommendations for the libraries, or coding standards.

I 100% share your feelings.

When people compare C++ with Rust, quite often the only thing measured is performance where depending in your cxx compiler Rust (or rather, llvm) may lose sometimes.

What is often forgotten is the ecosystem.

To build a cxx project you'll probably need to learn CMake and ninja; maybe Buck or Bazel too. If your project has eternal dependencies you may have to figure out yourself how tl link everything together using whatever build tools the authors were using. For docs, you'll have to learn and use doxygen; for style formatting, something like a clang-format and its presets and options; for linting, something like clang-tidy or cpplint, etc. For testing, probably catch2 or one of similar frameworks. There's no universal concept of "package" or "version", you're completely on your own here; most open source cxx repos that have dependencies just add them as git submodules.

In Rust, cargo build to build, cargo doc to generate docs, cargo test to run tests, cargo publish to push your crate to the index; cargo fmt to format the code and cargo clippy to lint it - that's it, we're done.

A large part of that is simply due to age, though. If rust were older it would have more baggage too, but also a larger ecosystem.

In my experience, Rust certainly has one of the easiest language ecosystems to use.

I've been using Rust for ~3 years now, and have been trying to learn C++, but I've been so spoiled by the entire Rust ecosystem's user friendliness that it's a very daunting task.

Or Makefile, or Meson, or autotools... And beyond to infinite.

Man, that type of stuff don't motivates anyone to learn a new language. If all what we should do it is code a solution and deploy with one command, oh God, will be a dream.

But no, beyond all this clusterfuck, by doing cloud stuff will be need probably Docker too, Kubernetes. Maybe ansible too? Oh, no, your team use terraforms.

D:

It's the Cambrian explosion in SW Dev tools. What amazes me though is how undead everything is. It seems that even ancient stuff is still somewhere out there waiting to be maintained. And there's a gazillion more every year adding to the pile.

Except revision control.

Would that a git for build tools would come along.

That is, something so compelling and sufficiently licensed that it quells the discussion in a jiffy so that the focus can be on getting work done.

There's something of a paradox to build tools - people like to have one in "their" language, but most languages are ill suited for it. Half of the people need something really simple. The other half need something extremely complicated. There's a mountain of edge cases, most of which people don't even notice, but which make other people's lives a misery.

For git, I felt kind of sad that "linus branding" helped it to beat out mercurial. git's UI is kind of monstrous (even linus admitted that). It's one of those rare technologies where a bad UI is branded as "you're just not smart enough to understand it".

To that point, the bun fight moved from the back end to the UI when git came along.

Personally, if you're not using magit[1], you should have a look.

Ridiculously powerful; check. Open source; check. Works like a champ in a terminal over SSH; check, check, check.

[1] https://magit.vc/

Magit is great! I use everyday. The more useful feature for me is partial staging by simple text selection. Help so much to create better atomic commits

probably so many things are undead because we don’t need to /can’t litteraly eat slow/bad designed SW to survive as the analogy in the nature out there

Off topic, but anyway. I hate cmake, its overly complex and I can never remember how to do things with it. The thoughts of having to set up even a small cmake project has put me off starting new personal c++ projects. Its a headache I simply don’t want to have to deal with. I eventually gave up and started using tup for personal porjects. It doesn’t have the same support for prepackaged libraries, but I’m much happier and no lobger dread setting up new projects.

So, for me, its much worse than just “omg which tool, so many!” because the most used tool is also, in my personal opinion, terrible.

I suggest learning make. It is a wonderful language. Start with the GNU make manual.

When you find yourself manually listing the .h files that a c/c++ file includes, learn how to generate .d files (it is in the manual, but stack overflow has some better patterns).

Then, figure out how to use make to automatically generate the list of source files required to build each binary. At this point, your makefile will have surpassed the usability of cmake in my opinion.

Soon after that, you’ll think you need recursive make to deal with vendored dependencies. Instead, read “recursive make considered harmful”.

At that point, you’ll start to hit rough edges, but you’ll be well beyond a “small project”.

Next on my make reading list is the BSD ports system.

I’ve heard bazel is a decent make replacement, but I haven’t used it.

Ninja doesn’t aspire to be one, and cmake/autotools are the reason I decided to go with raw make in the first place.

I provide a simple Makefile for almost every project, mostly as a reference to myself and others. Add a "build", "clean", "deps", and maybe "install" targets and then regardless of the specific tooling/language it’s easy to figure out what to do or where to start. Even if that project/language has a good build system or scripts. Simple makefiles aren’t too much worse than yaml.

> (it is in the manual, but stack overflow has some better patterns).

I love how that's one of the things the author listed in their post :)

make is useful, when you stay within its confines.

However, it quickly turns into a morass the moment you want to do something outside of it.

I tried, and I gave up. I ended up coding something similar to make, in python. I just funneled some of my commands to the shell module.

I think this is a point where Go is very good at and JavaScript sucks pretty hard. Mostly because Go brings many things by default and JavaScript has such a high rate at which new tools become mainstream/obsolete and so many options to choose from and combine with.

I found the opposite to be true. With javascript I never saw the package.json not work for the other developers on the team; with go, half of my team can't successfully update vendoring for no apparent reason.

Commands frequently error with messages that are completely worthless.

Go seems to have made up it's own path syntax with things like "...", and commands like "go test foo/bar" will fail with an error message that gives no clue as to the problem, but work fine with "go test ./foo/bar". Why?

What's the command to see if any of my dependencies have a CVE against them? Oh, there isn't one. What's the command to prompt me to pull in a new version of my dependencies? Oh, there isn't one.

This is a language that has made some promise about backwards comparability, but every release seems to break how things are built, and you have to fiddle with bizarre environment variables like GO111MODULE to find the incantation to make things happy again.

Give Go another 15 years to catch up with JavaScript's current maturity and see where we are then with its ecosystem.

I mean, Node and Go were released within 6 months of each other. When jquery was the dominant tool in the ecosystem, there wasn't nearly the level of breakage that there is now.

If it still exists by then...

Don't bother using SBT. Just build Scala with Maven. It's wonderful, everything works how you'd expect, all the documentation from the Java world is still valid.

Maven is another sort of hell :-) Also, do you have good integration for building Scala.js as well?

I've never got the hate for Maven - all the design decisions people dislike seem to be the same things that people praise Cargo et al for. If anything it suffers for being ahead of its time.

Use the Scalor plugin, https://github.com/random-maven/scalor-maven-plugin, and then Scala.js just works. I actually hooked it up to Netlify by treating Maven as a static site generator: http://m50d.github.io/2018/11/29/deploying-scalajs-with-netl...

> SBT

Me: “How do I xxx in SBT?”

Them: “Read the docs, n00b”

Me: “what docs?”

Them: ...

Visual Studio for C# development got this right: powerful language with super good IDE support and a rock solid standard library. Good documentation online too. It hides complexity that can bite later, and it can be complex to chose a framework to target, but otherwise it’s super easy to get started.

That is, until you get to the point where you want to automate your build and oh now you need to learn the clusterf*ck that's msbuild.

> ecosystem

A lot of this stems from the fact that most languages start out thinking they won’t need an ecosystem and what emerges evolves rather than is designed.

Some platforms allow you to learn a new language wile staying on the same ecosystem: E.g Java -> Kotlin js -> ts Erlang -> Elixir