Fans might also look at Steven Brust's fantasy Dumas pastiches, especially The Phoenix Guards, set in the same world as his Vlad Taltos novels. Truly a hoot.
Yeah, I guess that's what I meant with "impractical". Sure, if you had your enemy on the other side of a battlefield, or outside the walls of your castle, muskets were great. If you met them on the streets of Paris, not so much...
If you planned the meeting with the enemy in Paris you might bring a musket, but you wouldn't carry one normally. I know lots of gun advocates and none of them carry a long gun with them except when they are planning on using it - they carry a small pistol for emergencies, but not the long gun. (they might keep the long gun in the truck, but not on their person). If I was planning on shooting someone in Paris I'd want the more accurate long gun (assuming I could get it to where I need it), but I'm not going to carry it when I'm "our for coffee" and happen to see my enemy.
The novel is more about politics. There are very few scenes where I'd expect a modern solider of any nation to have their gun with them either. (though a few scenes where I would expect one they often don't seem to have them)
And in fact, professionally, I still live in the good old days. I code in Java 21, I minimize dependencies, and I use an IDE that can do the heavy lifting when I want to refactor something…which is often. I produce a .jar that gets installed with a loader script rather than in the cloud. And it all works, and it’s *stable*.
This is something I have known (but not by this name) since the early 90’s. A proposed feature a customer brings to you is almost never what they need. You must iterate with them to discover their real problem and move on from there.
I left a project once because the sponsor wasn’t letting us interact with the real customer to find the real need. That path only leads to doom and despair.
This is why I love building things for internal users. I can just ping them on slack, and not have to go through layers of communication, or worry that I'll be over-promising something to a paying customer.
I watched this happen from the outside. I bought a Laserjet IV when it was first released; by the time it started to fail, many years later, USB had killed the older printer interfaces. It was a workhorse. I wouldn’t even look at an HP printer today.
I can't speak for the lasers but I will stand up for HP inkjets even though I own an Epson today.
Many criticisms are true (impossible to fix when complex plastic parts break, expensive ink, cheap paper feed mechanisms on budget models, undocumented fading performance, ...) but even the cheapest printers make astonishingly good prints if you use quality ink and quality paper and the cost to fill up a room with decorative art is pretty low.
I know they put you through hell about the ink but it's also true that there are no standards for third party ink and on photography forums you see people who try to make borderless prints and get inksplosions instead and the lowest common denominator is third party ink.
I've had many Hewlett-Packard printers over the years, and I'd never buy another one.
The most common complaint about HP is its lock-in policy and its associated gutter business practices, not with the inks per se. If you reckon HP inks are the best for high quality art then I'm not going to argue, it's your decision and your money.
On the other hand, I've now an Epson WF-4830 which I only run in draft mode because of the outrageous cost of the inks. When I've finished with this current batch of inks I will do with this printer as I've done with its predecessors which is to chuck it out the window onto concrete two stories below and buy another (that's the cheapest and most effective option for upgrading printers nowadays—I'm onto my fourth printer in about 20 months).
Incidentally, my Hewlett-Packard LaserJet IV which I bought in the 1990s is still working perfectly (these days its Centronics interface goes through a converter to the PC).
They're a bit iffy on mine but I'm surprised they've held out so long. Fortunately, the printer's on an ancient XP box dedicated to a single task that doesn't require much printing. There's one spare cartridge, after that I'll likely call it quits.
BTW, I've heard there was a problem with fusers in LaserJets but never experienced it myself in any I've used.
I likewise have a circa 1997 LaserJet that I refuse to give up. Both the printer and scanner still function flawlessly, every time I need them to - something that few printers today seem capable of.
I switched to 64-bit Windows in 2006. The printer supports PCL drivers, but there are no 64-bit drivers for the scanner. Luckily, I was able to keep it going by running 32-bit Windows in a VM, and passing the parallel port through.
I switched to a laptop without a parallel port in 2019 (thank you, Lenovo, for keeping the parallel port on docks as long as you did). At that point, I bought a JetDirect that supports both printing and scanning over the network. CUPS and SANE both support it out of the box.
Those 90s LaserJets were genuinely incredible, and aside from (understandably) dog-slow PostScript processing, I think they were a pinnacle of office printer engineering.
We had one keep on trucking for... geez, as far as I'm aware it's still out there.
I first experimented with Lisp back in the mid-80’s, and have returned to it time and again—not as a language for serious projects, but just as a way of learning new techniques and new ways to think about writing software. I’ve tried using Racket on a number of occasions going back to way before it was called that, and something about the software just puts me off. Perhaps I could get past that if I stuck with it, but I just can’t see myself writing a large project using Racket.
I liked it many years ago but when I noticed how slow and heavy my code was I left it. It manages to be slower than Python. Perhaps the Chez Scheme rewrite helped with that but now if I need a Lisp I have Common Lisp which is super fast and lightweight enough.
These are small benchmarks, so don’t over-generalize from this data point alone, but Racket absolutely crushes Python in terms of speed and goes speedily enough against other popular performance-focused languages:
Matthew Flatt, the Racket lead, says that Racket’s performance should be fairly comparable to Java, much faster than Python, slower than Julia/Rust/etc. That’s been a helpful model for me: if Java is fast enough, Racket will do fine.
Nice examples! With a few tricks, I made the Racket program x5 faster. I think you tried to use the simplest program, so I tried to add as few cheats as possible. I added a happy path for fixnums and keep the slow path in case the iterations gets too big:
(define (count-collatz n [cnt 1])
(if (fixnum? n)
(cond
[(= n 1) cnt]
#;[(zero? (unsafe-fxremainder n 2)) (count-collatz (unsafe-fxquotient n 2) (+ 1 cnt))]
[(zero? (fxand n 1)) (count-collatz (unsafe-fxquotient n 2) (+ 1 cnt))]
[else (count-collatz (+ (* 3 n) 1) (+ 1 cnt))])
(cond
[(= n 1) cnt]
[(even? n) (count-collatz (/ n 2) (+ 1 cnt))]
[else (count-collatz (+ (* 3 n) 1) (+ 1 cnt))])))
My program has two versions, the version with `fxand` is slightly faster than the versions with `fxremainder`. I have to used two `unsafe-` functions, but a smart enough optimizer should have fixed them. So I'm adding this example to my wishlist.
I think it would be very hard for the optimizer would be to replace `/` with `quotient`, but the rest look possible.
But if you run the code inside the default IDE call DrRacket, you must go to the menu Language>Choose_Language... then click "Show_Details" and disable "Debugging".
With debugging enabled, you get nicer error messages, but it blocks a lot of optimizations and the program get slow.
I wonder how, given that anything that brings Python and performance together, usually means it is actually C code, or similar, as PyPy is seldom reached for.
Raket is compiled, thus maybe not the right build parameters?
What killed Perl for me was readability, long before Perl 6/Raku. I was an Awk programmer from way back, so took to Perl quickly once it was available. Then in the late 90's I wrote a utility program in Perl that generated some nice HTML documentation for me from some kind of input format I no longer recall.
A year later I tried to use that script on another project, but had to make some changes; and couldn't make heads or tails of it. Shortly thereafter I had occasion to look at some Tcl/Tk I'd written at about the same time...and it made perfect sense to me.
Had I used Perl on a daily basis, rather than occasionally, I might have stuck with it. Instead I switched to Tcl/Tk, and never regretted it.
Reminds me of the pre-GitHub days, when I had to use CM tools designed to appeal to project and CM managers, not to the poor developers who had to use them every day. Anybody else remember Harvest?
I've been doing development using JavaFX, Swing's successor, for many years. It's got its quirks, and places where the dev team stopped iterating on the API a little too soon; but it works and does some really nice stuff.
reply