Comment by kstenerud | Hacker News Reader

Comment by kstenerud | Hacker News Reader

And the downsides:

* Getting information and help was difficult. At best there was c.l.c and such if you had a modem, but there was so much gatekeeping going on that it was hard to get a straight answer on anything.

* Source code was hard to come by. Everyone was so damn bent on keeping their precious code secret that you could only learn best practices if you happened to be in a job with good leadership.

* Hobbyist embedded systems were all but impossible unless you rolled your own. Working on an embedded platform meant using crappy tools, expensive and clunky in-circuit-emulators, and proprietary toolchains. Otherwise it was time for a homebrew etching tank.

* Storage, backups, and code versioning were a problem. Sure, we had CVS and eventually SVN and sourcesafe, but man did they suck!

* Hardware was super expensive. Software was super expensive. Getting anything done on a tight budget required a lot of creative thinking.

* Spending all day squinting at a small monitor sucked.

* Software (especially development environments) was chock full of sharp edges and required arcane knowledge and incantations. They were called UNIX wizards for a reason.

* Data communications and interchange formats were TERRIBLE (and always proprietary)

* Multilingual support was an exercise in madness.

* Bash was one of the nastiest undead languages ever invented. Oh wait, it it still is...

* "If it was hard to write, it should be hard to read and understand" was the mantra of the day.

Regarding "getting information was difficult"

I've worked in game development for 25 years so YMMV: a few years ago I had an internet outage for a week or so and had to work on the engine just using my library of books. It was definitely slower and more cumbersome BUT it was a much more rewarding experience. I produced substantially better ideas with better documentation and with MUCH better execution. I don't think it was just because of the quality of my library. I think it was because I was afforded the space to think, something that had not happened for quite some time.

I now make a point to investigate my library before blogs, forums and the pitiful stack-overflow. Slower learning has lead to deeper thinking.

"Instant information is not for me. I prefer to search library stacks because when I work to learn something, I remember it." -Harper Lee

The sheer insanity that are shell scripts is something I don't see talked about often enough.

Bash is absolutely wonderful as CLI driver. It's truly an awful scripting language).

And yet, I see many, many projects with huge, enormous shell scripts. It beggars belief.

"I can use the shell" != "I can write shell scripts"

Bash is really difficult to write well (if at all) and too many people don't appreciate this. Of course this leads to instability in shell scripts. Offender number 1? Dockerfiles!

That's not a shell problem, that's due to docker not having start and end layer flags, so you end up with stupid long cmd && cmd && cmd sequences to ensure it's all in one layer

Bash truly shouldn't be used for a bunch of scripting tasks.

Quite simply I don't think you should ever start using shell scripts in your code base in any capacity

Eventually you're going to reach something you just don't want to do in Bash, and suddenly now you've got two scripting languages in your codebase?

Don't think you want that trouble. Start with a scripting language with decent control structures on day 1 and never have to worry about refactoring.

> and clunky in-circuit-emulators…

I wrote software for in-circuit emulators from Applied Microsystems back in the late 80s and early 90s. I was fortunate to be able to work with some really talented people.

Our high-end ICEs were expensive, maybe $40K at the time. I can think of at least one company that bought 120 of them from us, although most of our customers only bought a few.

A lot of NRE went into building such systems. And yes, I think they probably were clunky yet capable of some amazing things when it came to debugging embedded systems.

> Getting information and help was difficult

As time goes on, I don't see this as the benefit I used to. When Google supplanted Altavista as my go-to engine for technical docs, and then when StackOverflow come to the scene, I initially thought these were great developments. But I was wrong.

Yes, it took much longer to both obtain and read the Intel/Microsoft/VESA/Cisco/IETF/etc documentation, but at the end of that process I always had a very solid understanding of what I was doing, why I was doing it, and where to look if X or Y goes wrong. Engineering coworkers and managers understood the process, understood the time delays involved, and accepted what were typical turnaround times for both programming and debugging iterations.

Nowadays? I solve the problem much more quickly, but within a range of zero to very little understanding of why it works, what is above and below me in the abstraction hierarchy, what the hardware is actually doing, what the performance tradeoffs are, etc. And then to speak to engineering culture, if you ever step out to do it the old-fashioned way, impatience often sets in and you're told to just Google it, bro.

If something goes horribly wrong, would you prefer your engineering team to have developed a deep understanding of what's actually going on under the hood, or would you rather have a pile of stackoverflow answers patched together?

I think the old way was better. My brain is dumber and lazier than before, and I'm uncomfortable with this feeling. It's just sad.

Exactly, that is my personal feeling as well. I'd rather prefer to spend the extra time understanding the solution instead of just copy-pasting and adapting the first Stack Overflow answer.

In fact, one of the most striking things I encountered in Github issues, Stack Overflow, etc... is the amount of people who simply try something, works for them and they share it like some sacred solution, but when asked why that works, they shrug and cannot provide an answer. And there is a sea of validated answers just like that in those platforms.

My fear is that we are slowly rolling down a hill in which IT ultimately becomes less of an empirical industry and everything comes down to trying until it works (without the proper understanding), because it is magic.

Yes, sometimes (if not most of the time) developers are in a rush and have no extra time to spend on understanding a solution, so it is much better to slam a copy-pasted code and move on. Still, this should not be the way to go...

> Sure, we had CVS > […] > Data communications and interchange formats were TERRIBLE (and always proprietary)

Not always. We had Kermit (https://en.wikipedia.org/wiki/Kermit_(protocol)) and NCSA Telnet (https://en.wikipedia.org/wiki/NCSA_Telnet) years before we had CVS (https://en.wikipedia.org/wiki/Concurrent_Versions_System) (1981, 1986, 1990)

Yeah, documentation required effort. There was good documentation, but you had to know where to find it. You had to network for such, too.

Software-wise, everything was enabled by default. You had to disable services. Which meant your machine was remotely exploitable right after install.

>* Getting information and help was difficult. At best there was c.l.c and such if you had a modem, but there was so much gatekeeping going on that it was hard to get a straight answer on anything.

Just to clarify, by c.l.c, you mean comp.lang.c on Usenet, right?

Yes, usually accessed via fidonet if you weren't at a university.

> * Spending all day squinting at a small monitor sucked.

To be fair, the pixels were bigger back then.

Reply on news.ycombinator.com