4 ms·

I used to have a government job for a while, a desk job, nothing related to IT. But of course we had computers. It was all Windows machines with really old vers

by kleiba 1y ago

I used to have a government job for a while, a desk job, nothing related to IT. But of course we had computers. It was all Windows machines with really old versions of Windows and very restricted in what software they allowed. Also, when I asked the IT folks if I could have Emacs on my machine, they just asked: "what is Emacs?", and I knew I was probably in the wrong place. As government jobs go, there was a period of multiple weeks with veeery little to do for me. I would have really liked to kill the time with some programming, but of course, the computers had no compilers or anything like that installed, like I said, it was not an IT position. I'm not much of a Windows person myself, but a google search informed me that MS had its own version of JavaScript called jscript. So after some playing around with it, I convinced myself that it should be possible to build an Emacs clone in jscript, and set out to do so. I wanted it to be fully compatible to Emacs Lisp with the goal that I could eventually install genuine Emacs modes. Suddenly, my job was fun! As a testament to government jobs, I was working on this almost fulltime for a couple of weeks, and no-one noticed. And I got pretty far, but eventually, I did actually get more tasks to work on from my boss and development stalled. But I think that were probably the best few weeks during my whole time in that job (I quit not too soon after).

unixhero 1y ago
Sounds like you would have had the passion for coding and engineering in a private sector job!
- kleiba 1y ago
  Yeah, I'm looking right now. But unfortunately, I live in a rather rural area now and there isn't much in terms of SWE jobs around here.
uludag 1y ago
Emacs is a great outlet for a bored developer. Any time at work when things aren't moving along fast I try to build some useful tool or try to port some internal tool to Emacs Lisp. I always learn a lot and have a blast doing it. Plus I feel it's a much healthier outlet then trying to bring in each and every tech fad to the companies stack.
saltcured 1y ago
Hah, on a much smaller scale I had a phase early in my career where I had to wrangle an autoconf build system to work on many unix variants used in HPC. I got pretty fluent in the minimal, portable subset of Bourne shell that actually worked everywhere. Also, some of the HPC platforms had terrible performance with autoconf and similar because they were terrible at fork/exec latency. Rather than doing copy-on-write virtual memory and fine grained time-slicing, like a typical workstation, they seemed to be doing stop-and-swap of whole processes or something. Something that took minutes on a typical workstation could take hours on the HPC service node. Anyway, home sick with a fever, I got the weird impulse to figure ways to avoid forking subprocesses from the shell. A common one was invoking `expr` for arithmetic, so I started writing my own arithmetic library in pure Bourne shell. It was decades ago, so I can't recite the actual code. But I remember that I tried a couple versions. My fever broke before I got around to multiplication and division, but I assumed I would just use naive iteration on top of addition/subtraction. The first version was direct ASCII-encoded decimal operators that exploded the input strings into sequences of digits and iterated them using a case statement encoding the 10x10 sum and carry results. It used function call arg list to iterate the digits and reverse them, so it could then process sum digits from least to most significant. Since I was processing operand strings from least to most significant digit, it was actually an arbitrary precision operator. I mapped the empty string operands as implicitly zero padded. After that, I think I experimented with larger bases instead of decimal. E.g. split the string into groups of 2 or 3 decimal digits and encode 100x100 or 1000x1000 lookup tables. If I remember correctly, t wasn't very practical, as the larger case statements didn't really perform well.

by kleiba 1y ago

unixhero 1y ago

Sounds like you would have had the passion for coding and engineering in a private sector job!

kleiba 1y ago
Yeah, I'm looking right now. But unfortunately, I live in a rather rural area now and there isn't much in terms of SWE jobs around here.

uludag 1y ago

Emacs is a great outlet for a bored developer. Any time at work when things aren't moving along fast I try to build some useful tool or try to port some internal tool to Emacs Lisp. I always learn a lot and have a blast doing it. Plus I feel it's a much healthier outlet then trying to bring in each and every tech fad to the companies stack.

saltcured 1y ago

Hah, on a much smaller scale I had a phase early in my career where I had to wrangle an autoconf build system to work on many unix variants used in HPC. I got pretty fluent in the minimal, portable subset of Bourne shell that actually worked everywhere. Also, some of the HPC platforms had terrible performance with autoconf and similar because they were terrible at fork/exec latency. Rather than doing copy-on-write virtual memory and fine grained time-slicing, like a typical workstation, they seemed to be doing stop-and-swap of whole processes or something. Something that took minutes on a typical workstation could take hours on the HPC service node. Anyway, home sick with a fever, I got the weird impulse to figure ways to avoid forking subprocesses from the shell. A common one was invoking `expr` for arithmetic, so I started writing my own arithmetic library in pure Bourne shell. It was decades ago, so I can't recite the actual code. But I remember that I tried a couple versions. My fever broke before I got around to multiplication and division, but I assumed I would just use naive iteration on top of addition/subtraction. The first version was direct ASCII-encoded decimal operators that exploded the input strings into sequences of digits and iterated them using a case statement encoding the 10x10 sum and carry results. It used function call arg list to iterate the digits and reverse them, so it could then process sum digits from least to most significant. Since I was processing operand strings from least to most significant digit, it was actually an arbitrary precision operator. I mapped the empty string operands as implicitly zero padded. After that, I think I experimented with larger bases instead of decimal. E.g. split the string into groups of 2 or 3 decimal digits and encode 100x100 or 1000x1000 lookup tables. If I remember correctly, t wasn't very practical, as the larger case statements didn't really perform well.