Comment by thraxil | Hacker News Reader

Comment by thraxil | Hacker News Reader

- SSH. Maybe not in terms of performance or efficiency, but before SSH, we were using telnet everywhere and just sending passwords in plaintext all over the internet. Plus, you could give someone your public key and they could give you access to a server instead of the "here's a temporary password, change it as soon as you log in" approach.

- Perl. This was at the time when the other languages available to me as a student were Java or C (mid to late 90s). Those were fine, but Perl definitely felt 10x more productive for me for the things I actually wanted to write. Plus CPAN was the first directory of libraries/modules that I'd encountered of its ilk.

- VMWare/virtualization. We used it for an Operating Systems class so we could learn by actually writing Linux kernel code and running it on a VM. This was huge at the time. Friends at other schools taking Operating Systems had to work on dumbed down simulations and "teaching" OSes. Before VMWare, if you wanted to work on the kernel, you had to have spare hardware and a lot of patience for re-building your system when you did something stupid. With VMWare, you could just restore from a good snapshot and try again.

- apt-get. Coming to Debian from (old, pre-yum) Redhat, being able to type a command and reliably install pretty much anything was a huge improvement over untangling RPM dependencies. Even RPMs were a pretty big improvement over manual compiling or Windows-style installer wizards.

- Numpy (or "Numeric" as it was called at the time). Vector math in clean Python that was mind-blowingly efficient. The only other option that really balanced performance and high level accessibility was MATLAB, but that wasn't suitable for using in an application.

> apt-get.

I saw a joke the other day that went something like:

"What, is your grandma so senile that she can't type ./configure; make; make install" ?

Installing software on linux truly sucked before package managers.

That joke persists in the DeFi / yield farming space right now, except with sillier names because the main services have names like Sushi and Pancake

Sorry to have ask, but do you mind explaining this joke? I'm trying to fit in "grandma so senile she can't Pancake; sushi install" but it's not clicking.

something like “She cant mint aUSDC to farm CAKE”

there are better tweets and memes floating around about how convoluted yield farming really is

When I installed my first Linux (Red Hat 9) I was trying to install Gaim on it. I was trying different methods and I managed to install it by source compilation but not through rpm.

Yeah, I started out on Red Hat (maybe 3 or 4.x) and spent years fighting with RPM dependencies. At one point I installed one of those source only distros on a spare machine for fun ("Source Mage", before Gentoo took over that space). For all the misery involved in having to compile everything from scratch on slow hardware, I was absolutely blown away that mplayer with proprietary codecs just worked out of the box. It always took me hours to get the right combination of packages on Red Hat to make that work and would frequently break whenever I updated anything.

> Installing software on linux truly sucked before package managers.

Although UN-installing software was possibly even worse!

Not just packages managers, but repositories. When I started using Linux, I was still downloading or building RPM files, and manually working out dependencies. The idea that you could suddenly netboot a tiny image and `apt-get install xfce4-desktop` was amazing.

Who you calling grandma! :)

Ahh, reading the Makefile to find switches you need or don't; documentation, ain't nobody got time for README, yah I'll take the default switches; also moving where the binary will be installed, sometimes an obscure library will not be in the path, have to find it, oops, wrong version, upgrade lib, oops, breaks backward dependency of something else, revert, put new lib in different place, mod path, make clean ... First time I used yum, I thought, my God, my barbarian life!

Also, kernel patching roll-back! If you put in a kernel patch that broke stuff, go get the LiveCD and make some coffee and call your spouse, you gonna be there a while.

Network booting, that too. I mean, is network booting 10x local boot? I can't say, but you're not going to make a data center filled with tens of thousands of nodes if you can't network boot.

> - Perl

For me, Python. I knew Perl was the "leet" language and was determined to add its power to my toolkit. I made several (three, I think) weeks-long intensive efforts to master it. Every time, I read the book, read PerlMonks every day, did exercises, and got to the point of writing useful scripts using pretty powerful features. I'd think "I've finally got it!" and would be a Perl programmer for a while, but eventually a few weeks would go by without any need to use Perl, and it would turn to mush in my mind, and I'd have to start over again at the beginning.

One day in 2000 I was yet again failing to do things in Perl that had felt easy six weeks ago, and I thought, "Huh, I think I remember how to do this in that language Python I fiddled with for a few minutes once after reading some blog post." I started typing Python and was very quickly able to get it working.

I didn't really want to write such easy, bland, straightforward code. I wanted to be a wizard who could do amazing things with a few cryptic characters. Writing Python was like doing a magic trick while simultaneously explaining exactly how the trick was done. It reduced my style points to zero. But I liked how easy it was, and Perl kept brutally showing me that I wasn't cut out to be a wizard.

Twenty years later, and Python is still an important part of my toolkit.

Yeah, I switched to Python in 2002-2003ish when I started noticing that all the interesting new things I was seeing were using it (and I had to do some scientific/graphics stuff where Numpy and PyGame were much nicer than any of the Perl options). I probably haven't written any Perl in 15 years now, but I have to respect it for what it was at the time. When I learned Perl in 1996 or so, I didn't even own a computer; I just had access to a shell account on the university's unix server that I could telnet into from any computer lab. I basically got started by reading manpages. As hard as that was, it was far more accessible to me than figuring out how to get whatever weird C compiler there was on there working or getting a machine in the one computer lab that had a Java IDE installed on the desktops.

The "wizard" aspect was part of what eventually drove me away from Perl as well. I was never really into the whole JAPH/golf thing and I worked hard to write Perl that was well structured and readable, and there were plenty of other Perl programmers like me. But there was also always that part of the community that wanted things to be as obscure and obfuscated as possible and they were very visible. Python's complete rejection of that was really refreshing.

Good for you, but I personally don't want to read or edit any Perl code again if I can avoid it.

Joke's on you for trying to read code in a write-only language!

I haven't really written any Perl in probably 15 years now and I mostly avoid it if I can. But put yourself in my shoes back in 1996 or so as a student. Didn't own a computer of my own but had access to random computer labs on campus and an account on the university unix box that I could telnet to. My options for programming were to try to get a spot in the one computer lab that had Java and C++ compilers (and carry around a stack of floppy disks with code I was working on). Those were always booked solid and not open at odd hours (I was a Physics major, not necessarily taking a CS class that would grant me priority access). Or, I could find any any Mac or PC in any computer lab, including the 24/7 library ones, telnet in, and write real, useful programs in Perl. The Perl man pages were available right there (and extremely well written), everything was stored on the server, the Perl standard library was pretty comprehensive compared to what was included with most other environments at the time, and my editing environment (pico at first, then vi and emacs as I learned) was consistent no matter what computer I was on. As much as I wouldn't chose Perl for a project in 2021, it was really a game changer for me in 1996 and I'm not even sure if I would've transitioned from Physics to programming if it weren't for Perl.

Reply on news.ycombinator.com