I think the problem is scale. Back in the day (before I was born), very few people were programmers and the resources they could use were limited. This means they didn’t need insanely complex solutions because they already needed complex solutions just to make it work on the limited hardware. People were trying to solve problems with computers. Nowaday you take a problem that could be solved by an microcontroller with three buttons and make it a cloud app with web server, web interface and all kind of other things like containers.

We donlt really tend to ask the question what a good solution would look like. Often it is the case that you just use the technology the developer wants to learn

These crazy complex solutions also look a lot more difficult on the slides than the simple 3 layer architecture that’s often shown to me.

With something that simple, and requiring so few people, how am I ever going to convince my clients to pay me multiple millions of dollars for it.

If you've jumped straight into programming, you'll probably consider any of those problems as a nail to your C/JS/Java/Python Hammer.

I was lucky to be initiated to the GNU / UNIX toolset by operation folks when doing tech support in a SAAS biz. We were dealing with a lot of text files and it didn't feel right to offload whatever my problem was to them, so I started learning from them and the scripts they wrote.

Mostly trivial stuff, such as in a directory, only select the relevant files, iterate through them to sum up something or find exactly the bit of information you need.

This allowed me to decrease time spent looking for the answer to my current case or colleague's case.

Of course, I then built those functionalities into a .bashrc (or was it bash_profile?) script to help my fellow support folks finding the answer on their own..

Turns out, most people don't want to have anything to do with a command prompt, even if the hard part has been done for you. That's been a pretty good lesson BTW.

Fast forward a few years later to now and I'm realising a good amount of stuff I've been writing lately could potentially be GNU'd instead of writing a Python script.

So that's how it goes I guess.

Well, the joke is on them for choosing to only stick to the GUI.

That's... very bizarre. Amongst the engineers I work with it's always an "oh cool, you know how to use bash/terminal" rather than "weird, why are you using terminal".

Me too. I'm thinking of doing a presentation on the Dunning-Kruger effect to see if it sparks some introspection in my colleagues.

My experience has been that some folks are resistant to the command line (but I wouldn't say most). This is too bad because I feel like it's a crucial part of development. I even wrote a post about it: https://letterstoanewdeveloper.com/2019/02/04/learn-the-comm...

So obviously, whenever I started doing trainings on how to use the cli / the toolkit, I could see what is best described as mild panic. Which I get, CLI isn't inviting at all, it's pretty daunting, there's no real emphasis on safety (as in not breaking anything), it's far from being easy to reason with when you're used to the Windows / GUI world.

The lesson was not so much about the prompt and more about understanding your target audience and catering to them really.

    import pandas as pd
    data = pd.read_csv(filename)
    print(data.sum())

And don't get me wrong, I've written some gnarly pipelined bash before, although I'm by no means an expert, but that doesn't mean its always the right tool for the job.

To be fair, what the matrix libraries do is provide readability and clarity.

Show a programmer unfamiliar with awk your statement and they're going to be spending quite a while parsing it.

Show a programmer unfamiliar with numpy/pandas some matrix multiplication and they may understand it intuitively for the most part without even having to look up references.

edit: I'm actually an awk noob myself but after rereading your code for a second, it makes quite a bit of sense. "For all rows in the column, take all digits 0-9 and sum them". So perhaps not much is gained by the library

The company I recently started with is really big on Splunk.

The fact that they're proud enough of coming up with the tagline "Taking the sh out of IT" to print it on branded t-shirts featured in their training material was a hint that I wouldn't be a huge fan of the product, personally.

Abstracting things away is great, but something about IT pros being proud of avoiding the command line rubs me entirely the wrong way.

Also, I'd like to point out that in both this blog post and the Taco Bell one, the "UNIX way" is being compared against a straw man example, not a real example of over-engineering. Neither post actually provides any evidence of any real inefficiency. Both authors are just trying to explain and improve their own thinking about programming, not trying to cast judgement on a generation.

I think that by itself isn't a problem, but fading right along with it is the capacity to decompose and structure the problem domain.

Even if one ends up writing a solution in a different language for whatever reasons, starting out by mapping the problem with UNIX command line tools will result in a better understanding of the problem; an understanding that is language agnostic and can be transferred to any preferred method of implementation.

Maybe it’s Python instead of Perl but that is about the most-significant change.

I think git has a pretty significant amount to do with the persistence of command-line tool use among the younger set -- it's just so much more efficient / easier to use from the terminal.

People said the exact same thing in the 1990s, too. "Enterprise"-managed projects, using tech stacks like Win32 or Java, have generally tended to produce large, unwieldly monoliths.

Societies are large and full of random fluxes and waves.. right now it might be the time for Wirth 17 pages long solutions .. but McIlroy one liner will come back.

It's not so much about "tiny" but about no fuss, low complexity, no-nonsense, etc. For example, Forth may be tiny, but it's unusable for most applications. Assembler languages are tiny, too.

The problem with this type of thinking is that "composing tiny bits" is obviously good to anyone. BUT there are vast differences between composing unix commands and composing lisp functions (and composing tiny JS libraries in NPM etc.) and some of these are good, while some are not.

It's actually very difficult to properly create a system out of composable, re-usable components. I would actually say that Unix pipes are a particularly bad model of how to do that (as are NPM micro-libraries). No well-defined interfaces, arcane naming etc. - they are all reasons why most modern versions of these tools have grown and grown.

> right now it might be the time for Wirth 17 pages long solutions .. but McIlroy one liner will come back.

In case someone is interested in &ollowing up this reference, it’s Knuth’s 17 page long solution.

For what it's worth, I'm a first-year computer science major and the class I'm currently taking is very much focused on the "art of Unix." We've been doing shell scripting and regular expressions and the like. I quite enjoy it.

When all you've got is a computer and your own hands, you use the Unix way.

If you have a team (or the money to hire a team) of 20 developers, then you start looking for a problem that you can solve with that hammer.

So I wouldn't worry to much. All other small companies who have people who don't know better, don't have too much technology inside anyway. Or at least often enough.