I know. And frankly, I'm not even the worst coder when it comes to graphic design. I know enough to see that _something_ is off with the cover, but not enough to figure out what ;-).
Yeah, it's one of the things that I wanted to do and then I was undecided which chapter to pick. But your criticism is valid, I'll pick a chapter and cut it out from the PDF and put it up hopefully later tonight (EST). Watch this space and don't hesitate to prod me :)
No, I didn't. I probably should have, but the sheer magnitude of the project ran off with all my good ideas :). There's already a bunch of things I want to add in a second edition, if that ever happens, there are just so many stories to tell and only so much time.
.
You can achieve roughly the same by writing down the SHA256 hash the first time you download and then comparing when you download the next time.
But, yeah, while I do not like submodules, for vendoring stuff it seems a reasonable approach. There's also https://github.com/fosskers/vend if you lean that way.
I considered that (author here), but how I test is way too odd to share lol.
I think that that's one of the strengths and one of the weaknesses of CL and its ecosystem. Rolling your own variation is just too easy and it almost seems to be encouraged. Which artificially steepens the learning curve. Anyway, I decided to focus on just "packaging", but I agree that testing needs attention, just like all the other topics people here touched on: secure distribution, versioning and pinning, and all these other modern comforts we're used to when doing our daytime non-Common-Lisp jobs :)
YMMV, of course. I switched to it half a year or so ago, when doing a close read of the ASDF docs, and for my purposes it works well. But I may be odd: I have a monorepo of Lisp code which I don't intend to distribute in the sense of turning them into Open Source packages. There's an `l` subdirectory for libraries, a `p` subdirectory for "projects", and if I need something I can just import `ca.berksoft.l/math/fft` and be done. I think that having a file-per-package is not a limitation, it makes packages probably a bit more like modules in my daytime language (Elixir/Erlang), and it does save a lot of typing telling ASDF what to find where.
We're talking early '90s here. Security was a thing of course, it meant you set a five-character root password on your FTP server ;-). MD5 wasn't even around so you had to trust that your source tarballs were not tampered with whatever the origins.
So whether I brought them from home or that company (if it had internet at all...) pulled them from gnu.org probably wouldn't have made a material difference. It was one of the reasons there was a big antipathy towards free software, at least with the vendor tapes you had someone to sue if they got tampered with.
Thanks for confirming that my option of asking a local admin with internet access was the right way.
Still... had to load the tape on our office AIX machine (the only Unix box I had access to), then wire up a null modem cable to a PC, install Kermit on both ends, transfer all the floppy images, find an MS-DOS image writer, and finally copy the works on that stack of floppies.
Timing-wise, that could be correct. However, the biggest issue to me was the inability to nicely interact with VMS system and library calls. Even with the best that DEC could do in their header files, setting up a complex $QIO was a headache, certainly compared to more “native” languages.
I was a bit of a fan back then. Much more powerful and stable than pretty much anything I encountered in Unix-land. And once you tossed out the C compact libraries, very fast, too :)
Original author here. C worked on VMS but it was not a good match. VMS used complex data structures and async for kernel comms ($QIO) and the C standard library was built with other expectations. Setting up and handling syscalls was cumbersome and the POSIX style library was slow.
I still remember picking up VAX Pascal for an other gig and getting a decent taste for the delight that VMS systems level coding was. Yes, Pascal was better suited for that than C on VMS. Fun times :)
It helps. It's not a silver bullet. AZs tend to go down more often than whole regions, is the belief (I don't think there's sufficient data, but a priori it does make sense).
That, indeed. When I compare Elixir/Erlang to some other systems I worked on, "shallow" is the word that pops up. You hit a limitation, you dig into some source code, and you find out that it's pretty simple to understand and to fix it. It feels manageable, I've yet have to run into frustrating roadblocks, and that all gives me the confidence that when I do need to scale up, I have a system I will understand and will be able to adapt. It looks like Discord's story confirms that.
I think "software developer" describes quite well what I do on a daily basis. Better than the "principal software engineer" that adorns my business card...
(which is still better than the "principal consultant" I had on my card in the early '90s when I was a mere kid - it made a grey haired banker in the city smirk a bit and remark "well, maybe when you have some grey hairs". At least I now have plenty of that!)
I moved from Europe, so I probably have a mildly more communist view ;-), but I'm appalled by Toronto's city government inability to do what I'd call table stakes beyond picking up the garbage - public transport and public housing. Neither seems to be going anywhere, and I have no clue whether it's finance ("we will not raise property taxes" is often heard), unions that frustrate everything, incompetent leadership or just outright lack of experience in running a metropolis. I love Toronto, but it sure has its share of big city problems.
Housing market wise: expect to be in the CA$750k-1m range for something that doesn't suck bad. Given the weak dollar, that's not a huge amount of money for a major city but it's rapidly rising. Myself, I'm moving to a chalet with some acres of forest shortly, 2hrs from the city, but then I can work from home almost 100%.
Toronto is a great place to live, but yeah - check your housing budget before moving here.
That is, of course, by design. To me (I have been a professional Smalltalk for a while), GNU Smalltalk drops the essence of a traditional Smalltalk environment and while I was "hmm, interesting, maybe if I ever have a use for it I'll look at it", I never needed it. A Smalltalk IDE is an extremely powerful fool, and IMHO the most powerful tool we've invented so far. Having said that - I do think that Pharo and friends maybe should be more friendly to what I as a developer expect today from my tools: mostly keyboard-driven, no overlapping windows, etcetera.
It'd be the first build system for any JVM language that would be nice. I don't know what it is, but they all seem to come with various amounts of suckage (started with Java when GNU Make was the most advanced option, via ant, maven, gradle, buildr, sbt, ...). It must be the JVM. I worked with Scala for close to a decade now, and my conclusion is that its advantages (type stuff) are mostly theoretical, and its drawbacks (sbt, type stuff, the JVM, slow compiler, the mess of features) are mostly practical. I'm happy to have mostly moved on.
That indeed was a complete turn-off. I had it in five minutes. Also, I'm sort of done with the JVM - it seems to breed large, complex things that are hard to manage. If I want a Lisp, I'll install Emacs and SBCL - there's not much the JVM has to offer that makes it a must-have.
That. My previous employer was a subsidiary of a large US company. The subsidiary was all hip and open plan and I hated our office, even after I got some mild adaptations done (moved team assignments to "positive space" islands and install a 20" sound partition between teams' desks so at least teams had some privacy). The mothership had these neat Herman Miller layouts with team pods. It looked (to my European design sensitivities) butt-ugly, but I loved sitting there. So quiet, and the only bit of interruption you had was probably relevant because it came out of your team. Not a random sales guy strolling by (sorry, sales peeps - love you, but you're a noisy bunch ;-))