verisimilitudes

I suggest that the first job you take be the one with the highest learning potential, not the highest earning potential.

The only reason anyone works under another in this modern system is for money. Anyone who claims otherwise is stupid or lying. I'm forced to consider the motivation for giving this advice to new blood looking for employment and it's obvious.

I work alone and I've learned a great deal with only books; note I mean work and not employment, here. Building empathy in the context of employment is only useful for promotions or continuing employment and I disagree with this notion that every programmer must, for some reason, become more empathetic, usually meaning capitulating to certain others, as if all programmers are lacking empathy.

As for your advice to join an online community, it's not bad on its face, but the particulars could be improved, I think. An IRC channel is a good choice; Reddit or Hacker News aren't; those two, in particular, are only useful for self-promotion, as they mostly discuss things happening elsewhere and only even that briefly; conversations don't last months or years in these places; they're unsuited to discussions not based around self-promotion, for the most part; the goal is to have one's link on the front index or collect Internet points, generally. The only reason I have an account here is to promote my work, and I've had some success.

As for an Internet community and making mistakes, you'll feel no shame if you simply use an anonymous form of communication. Imageboards are good examples. You can ask a silly question or make a mistaken claim and you don't suffer social stigma, because there's no identity to start with.

For a batch compiler, that is a language that doesn't need the compiler to run, write an AGPLv3 compiler without a linking exception and then demand sufficient funds be raised to release a version with the linking exception. This is then a way to write a Free Software compiler and still demand money for it, for many to actually want to use it. I wouldn't license something such as a Lisp compiler with the exception, however, as the implementation generally exists with the program and that removes some advantages of it being AGPLv3. Fortunately, it seems the author has used the AGPLv3 and any desired exception uses vague language not in the license, so it's legally irrelevant. I'd find it best if there were no exception for this program, but it's not my decision.

In closing, this has made me want again to write my own Scheme implementation, so perhaps I'll do that at some point soon.

In any case, I can still find examples of these platforms. Emacs is such a platform. For that matter, StumpWM is a platform of sorts. A nice quality of Lisp is making any program extensible with it trivially. As for Ada, governments use it for critical systems and I can't tell you the particulars of those. They use Ada because people will die if the software fails, so they're seeking quality, not quantity. You're advocating for quantity, not quality.

As for APL, you don't build platforms or such things in APL. If you don't see the beauty in APL, then that's your loss.

They don't build platforms for others to build on, they build pillars to prove a point.

First you claimed people don't build great programs in these languages, which I've shown is false, and now you're arguing that they build things, but not things someone can build on. You're conflating extensible software with quality software here.

What actually happens with these languages is that a certain breed of highly opinionated but highly unproductive programmer gets lost in them, on their quest for a level of aesthetics or elegance or correctness that nobody but themselves actually values.

That happens, less so with Ada, but why would that even be a bad thing? Is it wrong for someone to spend time working on what they view as an ideal and finished program, rather than just writing something that's already been done and requires little thought or effort on their part? It's infinitely harder, I think, to write novel programs than it is to simply implement some specification or write a copy or something else. That's what I do with my work. I don't see why you'd look down on that.

I'll let you've the last word, if you want it. I'm not interested in replying in this chain any further.

As an aside, I find it interesting how many negative Internet points I'm receiving relative to the amount of responses there are. My figuring is many of these people can't argue with what I'm writing.

They at least had the advantage of not being forced to design a language for a failed startup, to be easy to learn where that's defined as resembling C, and other asinine considerations people continue to take into account nowadays.

These were clearly people that were figuring it out as they went along, which they would be the firt to admit

I'm not claiming otherwise, but the birth of Lisp was a paper written by an AI researcher that had good thought poured into it, not something meant to look like C and be good enough for whatever its purpose was on a strict time schedule.

...and it's virtually dead.

Why would that matter? Why does every language need to appeal to many people? Why is that a desirable quality? There's still plenty of APL being written. I even have an article concerning this: http://verisimilitudes.net/2019-08-08

Who could have predicted that?

Ada was designed to be implemented efficiently and understood easily. It's harder to write a good C or C++ compiler than it would be to write a good Ada compiler; there's simply fewer people doing this and GNAT is popular. The only compiler I'm aware of for C that anyone actually uses, sans the behemoths of GCC and Clang/LLVM, is tcc, and almost no one uses that. There's more Common Lisp implementations that are actually used than there are for C and the only reason you'd see more C compilers for Ada is because it's a smaller language with a standard that lets the implementor get away with doing so little at the cost of every program written in the language and because the standard for a C compiler is so low that it's expected to have bugs.

The economic cost of implementing the language is a salient part of its fitness.

When you start judging something in computing by its fitness, it reminds me of a virus, and that reminds me of The UNIX-HATERS Handbook and its description of C and UNIX.

C++ is only bad to the degree that you can completely wish away path dependence.

I don't know what you mean by this. Common Lisp doesn't care how code is loaded and Ada has a nice with and use system.

I do know C++ is a gargantuan language where the very grammar is ambiguous and is parsed differently by different compilers and I'm also aware it has little in static analysis due to this. Debugging Common lisp is simple due to its interactivity and Ada was designed to be statically-analyzed.

Part of why I mentioned APL, Lisp, and Ada is because I use all three of these languages. I could care less what the masses use. Do racecar drivers care about the people driving vans? Vans are more popular than racecars. Why should computing be different?

Take a look at a Lisp, APL or a derivative, or Ada for examples of languages designed by people who knew what they were doing. Lisp grew in universities under the direction of hackers and there are several standard dialects now. APL was designed by a mathematician originally as a teaching aid. Ada was designed in a contest by the US DoD after spending a long while collecting requirements and it was then fully specified before any implementation work was done.

If the people who purchased this received the source code as Free Software, that would've also solved this issue, don't you think?

I rent a server and I rent several DNS names. Unfortunately, neither of these things are protected in a way that would prevent them from being taken from me, but it's not happened yet. Through this, I'm able to host a website, a Gopher hole, a Finger service, my own email, and I'll host FTP, IRC, and other things as I want to. There's not much of a limit. This is nice and freeing. I decide how everything's presented and done; I use my own server software in some instances.

I can agree that having one's own website is an introduction to this manner of freedom, though.

I use the AGPLv3 for most of my software and it's a feature that large corporations horrified of contributing back fear it. I'm not exploited, because I use a license that doesn't allow me to be exploited.

No one using a permissive license, which are pushed primarily by corporations that slander the GPL I think, has any right to complain about being exploited, in my opinion. Copyleft is good and copyleft software still gets paid support and other things; as many companies have found, it's also a good means to release Free Software that people will still pay for, in the form of license exceptions, even.

There's a flaw in the article:

Ada doesn't define standard types like int or float...

It does, technically, Integer and Float. The rest of the article is fine.

Lastly, it's amusing to see the Rust advocates cry out due to this. As I like to write, Ada is used in critical systems such as ballistic missiles and trains, whereas Rust is used in Firefox.

One issue I ran into was no pre-built packages for newer releases, so when I updated to 6.5 I had to downgrade to 6.3 to get any packages. Sans that, it's also unfortunate that Common Lisp implementations don't tend to support a MIPS that isn't under GNU/Linux; the GNAT compiler for Ada also isn't available. I can get GNU APL though, so that's nice.

Since some are wondering, I bought mine about eight years back for a few hundred dollars and even back then the website that supplied mine soon ran out of stock.

This article has reminded me that I'd intended to make pictures and descriptions of my Lemote Yeeloong available on my website months back, which is a great option for my 2019-09-09 article, so I'll do so.

Owning this machine has been a nice way to not use x86(_64) for everything and it's made me intent on my software working properly on less common machines and operating systems. My choices of language have likely already betrayed that, but I eventually intend to write implementations of my own and I'll ensure my Lemote Yeeloong is well supported. I also must remember that OpenBSD may not support it forever, although I could perhaps take over if it's ever necessary.

I could write more concerning this, but this seems sufficient.

Anyway, sure, I could've made the message a tad nicer, and I really shouldn't have bothered commenting in the overcrowded discussion anyway, but some of the points in the discussion, from this author I've read before, compelled me to write it as I did. There was value, I think, in countering this faux-niceness presented in the submitted writing with a more genuine and plainly-phrased critique of the ideas.

This and many others comprise examples of precisely how downvotes aren't useful for much of anything.

“How do I do X?”. Often, X is quite a simple thing, like “append to a list”, or “merge two dictionaries”. I find that the longer I program with all sorts of different languages, the more I struggle remembering all that sort of stuff.

You don't know a programming language if you need Stack Overflow to recall trivial things. I'd go as far to state that you're barely a programmer if you must have an Internet connection to program.

I'm of the opinion that Stack Overflow is primarily good for those who don't know and don't want to learn. That is, I've never used it for an APL question or an Ada question and not so for Common Lisp, either; note that these are all real languages, that are standardized, have books written about them, and have real documentation. So, if you want to play with JavaScript, then Stack Overflow seems like a good place, as that's a disgusting and poorly documented language, but real languages don't need this manner of thing.

The author fails to recognize that having a stupid little voting system and stupid Internet points is precisely the cause of the issue. I'm accustomed to anonymous communications and people get along just fine, in part because the only thing you can do to voice disagreement is to write an actual reply instead of clicking a stupid little button and, since you're not vying for stupid Internet points, you only write a response if you actually want to help someone, with no expectation of receiving anything except perhaps a Thank You. out of it.

The Vi & Vim Stack Exchange is much better in my opinion (I am a moderator there, so I may be biased). We actually had one user being a condescending prick for a while, so we kicked him off. The site has been much better ever since.

That's another issue with this garbage. You get cases of Oh, you're not violating any rules, but you're being mean by my own idea and since we have accounts and lasting reputations and I've been observing you, I've decided you're banned just because.; I'm accustomed to the old-fashioned notion of having real rules that are enforced consistently; you can't moderate anonymous messages by any other means.

So, in closing, you're likely only asking a question on Stack Overflow if you don't know what you're doing. Read a book or check the standards, instead. If your language doesn't have a standard or good books, learn a real language. If your standard is a pile of garbage, as the WWW is, then this would actually be a decent use of this tribal knowledge sharing, but the better solution is to avoid the garbage standard to start with.

I could refine this message, but I'm not particularly concerned. Surely I'm not the only one here who thinks similarly.

I use the AGPLv3 for most of my software, because I don't work for free, for the most part, and want to use the strongest copyleft license available to ensure this. That parasitic corporations fear copyleft and the AGPLv3 in particular is just icing on the cake.

If you don't want your software used in this way, then don't use a permissive license. I sometimes use the most permissive licensing, the CC0, when I write something truly trivial and don't believe I could get away with making it copyleft. Perhaps you understand this general approach, but also that people would simply use a different implementation of your libraries if you did this is the issue here. You don't mention Free Software once this entire article though, so I find that unlikely.

But telling maintainers to bury their appeals where no one bothers to look is not the answer, either.

I vehemently oppose giving Github even more influence in the form of financial payments to its users. That's asinine and I refuse to use Github.

No one knows the value of a sponsor message in the terminal since this has never been tried before. That’s why this was an experiment.

The value is nil. I don't need to take a flame to a rabbit to know it will burn.

Fellow open source maintainers and open source contributors have, by and large, been supportive of the experiment. Open source “consumers”, not so much.

I'm not an open source maintainer, but I write Free Software libraries and I've voiced my opinion in the other thread here. This paragraph creates the impression only those who don't contribute disliked what you did. For the record, I found it and continue to find it suitably amusing.

Many supporters expressed their dislike of advertising – even advertising where the sponsors are carefully selected and the implementation does not track users or collect data.

Advertising is inherently awful and nothing will change that.

Approximately 100% of the Fortune 500 use open source code. Maintainers are just starting to wake up to our own power. Expect to be surprised. This certainly won’t be the last open source funding experiment.

I suggest investing in Free Software and not open source; is it any surprise that the rebranding of software freedom specifically tailored to corporate interests encourages this?

Even for simple single-purpose packages, there’s a non-trivial ongoing maintenance burden. Especially when you’re maintaining hundreds of packages, as many in the Node.js community do.

I've taken a look and I could probably claim hundreds of packages as well, if I wrote many, trivial packages, which is most of what I saw under your name. I currently have five libraries, two or three of which are somewhat trivial, not counting complete programs and other such things. It seems unfair to claim hundreds of packages when many of them seem so trivial and this is also never mentioned.

People will mention every catastrophic flaw Ada programs have ever had, but how many people will remember this as an example of how C++ fails at being a real language for real projects?

I like how advertisements, which are inherently unethical, are now being billed as ethical because they lack the awful things piled on top of an already awful thing. I anticipate this going about as bad as it possibly can, and I'm going to find it amusing if and when it does.

It's always these JavaScript projects I see doing this stupid shit. It's amusing to see these people, many of whom participate in shoving advertisements on others, not care for the same treatment.

I write Free Software libraries and the only thing I'm currently asking for is that people share the work they base on my own, which is why it's under the GNU Affero General Public License version three.

These JavaScript projects use a great deal of Free Software, but they act as if they're important or significant enough to warrant such things. I use GNU Emacs, GCC, various other compilers, various servers, and many other things, but these code artisans put advertisements in their drivel because they don't think they're making enough money from it, and this is an attitude many of these JavaScript people share. I intend to try to make money off my future projects by either selling documentation or being paid for writing the project to start with.

I could go on a much longer rant, but why bother?

As for Steve Losh's article, I don't recommend that one either; it recommends using a Discord server; it recommends using C libraries; it discusses performance and representation characteristics that are allowed, but not required, in interfacing with things such as graphics cards; and it has other characteristics that I don't believe someone new to Common Lisp would recognize it, so I don't recommend that article to novice Common Lispers.

That's interesting. If you're interested in discussing that more at some point, email me. Now, I've designed a numerical format for metadata involving machine code programs and, while I've not written this piece yet, an important aspect of this will be a repairing tool. The only reason a textual format would be easier to repair by hand is because you can use a text editor and it's more redundant. Now, good design is another quality; ideally, a numerical format would lack holes that are invalid states and wouldn't be riddled with pointers or other things if feasible; it varies based on what you're doing, though.

I ended up merging the corrupted file and an older backup in Audacity (an audio editor) by sliding the two files back and forth relative to each other, because hex editors are awful at visualizing and aligning binary files (whereas diff tools are good at visualizing and aligning text files).

That's again a simple matter of tooling that could be corrected.

Additionally, the on-disk layout changes between versions, and the reader code is a mess of branching between different on-disk layouts based on the version number.

A runaway format revision like that isn't ideal, I can agree. You can get the same mess with textual formats, however.

Additionally, it's impossible to check in your music project (binary blob) into Git, then get a meaningful diff between different versions, let alone being able to merge changes made in 2 branches. (Yes, I use Git for music. It's actually useful.)

I don't use git at all, so this is another difference between us. I'm largely of the opinion that the focus on textual formats for UNIX-likes was due to sloth more than anything, as there's generally a lack of coherency between /etc/fstab to /etc/passwd and so on; I believe the focus was largely due to the advantage of ostensibly generic tooling, but reading or writing a configuration in a text editor, with the manual handy, and getting errors and other things upon loading it is worse than having a tool write it for you and show it to you at a high-level.

Needless to say, I'm using a text format if I ever write a replacement. A text format may have trouble encoding binary blobs, but I don't like the idea of "transcoding .wav into binary files, and throwing away the parameters used". I'm more inclined to just use pointers to on-disk .wav, and store all metadata needed to reproduce the binary blobs, and possibly cache the binary blobs in base64 for speed and convenience.

I don't know the details of what you're dealing with, but again, if you're interested, email me and I can perhaps work on a repair tool or help design a replacement numerical format that will be easier to manipulate.

It's a wasteful, textual format derived from a programming language vomited forth in under a week. It has asinine integer characteristics for no good reason; it's not a random-access format; validating it is even more work; hash table keys that appear multiple times, instead of being in error, instead overwrite each other, defeating most any kind of optimization; it is thus wildly inefficient to manipulate, as manipulating it correctly in all cases requires full and comprehensive parsing with checking. It is an asinine ''format''.

>It's a text format that can be inspected by humans, unlike binary formats.

Even then, there are much better textual formats that could be used, but I'm of the opinion that numerical (binary) formats are strictly superior, especially as they're used increasingly often. It's better to have good tools that will provide a human-readable representation, rather than pretend a single, inefficient representation for both man and machine is somehow the best option.

>(Maybe IMAP is a text format too, so this isn't an advantage inherently) And JMAP may have better semantics than IMAP, and there's nothing inherently wrong with JSON (other than edge cases).

Computer programs written by anyone competent are built around edge cases; that's much of what any reliable program is, accounting for edge cases. To disregarded edge cases, of which there are many in JSON, speaks to me that you have little concern for writing software correctly, but I imagine you'd deny this, as who doesn't want to write correct software? Simply understand that using a format with so many edge cases and other defects as JSON is foolhardy for much of anything.

To process JSON, you must inspect every character, which is reason enough it's an awful ''format'' that only an ignorant could hold dear. Douglas Crockford brags about how smart he is for disallowing comments, but there's whitespace allowed everywhere. Let's not forget this asinine integer nonsense, because JavaScript lacks real integers.

I'm sure most people think HTTP clients and JSON parsers are standard-library affairs, nowadays, though; let's just entirely ignore matters of licensing and whatnot.

It's disgusting to see this as an IETF standard, but people have been complaining about how that moves along for decades; take a look at Google's robots.txt ''standard'' that doesn't do anything useful and effectively makes every existing file standard, rather than do much of anything worthwhile. The WWW and JavaScript are nothing more than a continuation of this worse-is-better filth that UNIX and C previously championed; decades ago, the IETF revised the RFC for the Finger protocol and warned about security, solely because some idiot wrote a shitty Finger server in C; now, we have useless and unnecessary standards such as this that only serve to further this next generation of idiocy.

I wonder when all of this will finally collapse under its own weight.

That Cloudflare is a giant MitM hostile to Tor and previous cooperation with the government in a past business leads me to believe Cloudflare is nothing more than a US government operation in the guise of a business.

That interference is specious, I think. In any case, the US interferes in every election it can, so is it unreasonable to believe every other country that can interfere would?

>You probably know enough to avoid following small, suspicious accounts on Twitter or browsing links to sites of which you’ve never heard.

I suppose ''surfing the web'' is truly dead, then. This seems to me like an article written for sheep.

>The second vulnerability is a legal system with numerous blind spots that lawmakers should close. Reddit is the third-most-popular social media site on the Internet, surpassing Facebook among American Internet users. It is also shockingly vulnerable, requiring only an e-mail address to register an account. Consequently, anyone could theoretically register an unlimited number of accounts and, being careful not to stand out to system administrators, effectively control conversations on whatever topics they want.

So, here's the meat of this garbage, then, in which it reveals its ulterior motive. Yes, Reddit is the Wild West, only requiring an email instead of the socially acceptable email, phone, government ID, etc.

>The third vulnerability is online anonymity. While we absolutely do not advocate for de-anonymizing the Internet, it is now so influential over American society that legislators should not leave regulation to social media platforms alone. Congress should put more pressure on social media companies to ensure their users are, at a minimum, who they say they are.

Well, what I was going to write about this issue, after reading just the first few paragraphs, should then be a response to this nonsense. As an aside, there is no ''Who they say they are'' in a truly anonymous system.

I was going to suggest anonymity, true anonymity, as a solution to this issue. I prefer those venues where there are no names attached and one can't tell even if multiple messages are sent by the same person. When you have a discussion in this way, you only judge each message on its own merit. There is no ''Gee, this can't be a bot or government agent, since this guy has a history.'' or any such thing. So, if it seems a great many messages have been made in support of something that isn't usually in the venue, such as a political candidate, say, it seems fair to regard it as astroturfing. When no one or few have a face, it's harder to astroturf, if only because everyone will constantly be on edge and are less likely to be swayed by a few messages. Not only that, but since none or few of the real users have identities, you can't target them with specialized messages or track them or other such things.

Anyway, what a terrible article, ironically submitted by someone with an account less than a day old. I almost wish I could make a living writing such cheap garbage, but I figure it would eventually get to me.

Alan Kay recommends some books. The Hacker News spend most of the thread recommending books they like, instead.

Anyway, this is a nice list filled with works I've not read, so I'll make certain to give them some attention next time I'm at a book store and ask them to order some things, since they only carry magazines and other drivel in-store.

The obvious solution to this is to use the AGPLv3 license for all or most software one writes, which is what I prefer to do, as it's the strongest copyleft license available currently.

We see in many circles that it's not the hip thing to do, to write copyleft software. No, the hip thing to do is write permissively-licensed software and either not care about companies using it as free labor or complaining about a ''social contract'' that wants to be implied, but never explicitly stated as copyleft does.

I believe the trend towards permissive licensing has been pushed mostly by corporate interests and now we see the result. I believe things would be better if every company had to either share its code as copyleft, write everything itself, or actually pay for other proprietary software it could incorporate into its own. That is, I'd rather Grammarly, as an example, have no real option but to purchase an Allegro or Lispworks license, rather than being able to use SBCL and contribute little or nothing.

>In base, OpenBSD only supports C/C++, however a Perl interface is also included.

I'm soon going to drop by the OpenBSD mailing list and see if they're interested in including this in their prepackaged GNAT. It won't harm to ask.

Related to this, I intend to write a binding for Common Lisp, at some point, although that will be far more arduous, all things considered.

The only reason I tip at all is because some restaraunts will remember me and you tip or get to wonder if they spit in your food. What a wonderful system.

I tip nowhere else and, since I'm not remembered, I face no negative consequences of this.

>At about this time next year, we’ll have a pretty good idea of what the next generation of video games will look like.

The current Sony and Microsoft consoles seemed to have few games worth owning and then released incompatible versions recently, yet a new version is warranted?

>as studios shuttered, developers burned out, and toxic work culture fostered environments hostile to marginalized people.

The only one of these that's valid is the developer overworking. A studio closing and ''sexism'' don't even come close, but anything to conflate the real issues, I suppose.

>When you adjust for inflation, the retail cost of video games has never been cheaper, and it’s been this way for some time. The $60 price point for a standard big-budget release has held steady for nearly 15 years, unadjusted for inflation even as the cost to make big-budget video games has risen astronomically with player expectations.

Sixty dollars is already high enough for a game and yet the next few paragraphs discuss ways companies increase the price by selling an incomplete product. Well, if the price ever rises, these companies would have no reason to stop, so you'd have higher prices and the same garbage. Anyone who tells you the price of a product such as this really isn't enough is likely a mindless drone.

>In short, the single-player game was not sustainable. So why should we think the current model is?

Why should I care if a type of video game is deemed ''sustainable''; what makes this claim valid, anyway? If there are games that don't appeal to me, I won't purchase them. Why would I ever think ''Gee, there aren't any new games that appeal to me; I guess I'll buy one that doesn't.'' when there is such a breadth of video games over several decades? That would be like buying a fashion magazine because the book store didn't have any programming books you wanted. If only ''Indie'' groups are releasing games I want, why would that be an issue?

>In short, the single-player game was not sustainable. So why should we think the current model is?

If you're a capitalist, you can only figure the market will eventually correct itself, on its own, so why care? The article then spends several paragraphs discussing climate issues, which are irrelevant.

>Video games cannot do this forever. If any of these things were to collapse—the people who make them, the economy they’re sold in, the ecosystem we’re all a part of—it would be catastrophic. All of them at once? That’s a disaster we need to talk about, openly. Because there are solutions to these problems.

Again, why should anyone care, considering the breadth of current games available? Should I give a damn if a publisher is struggling, considering there are more books, and about topics I like at that, than I could ever read in my lifetime?

The article then suggests all of the children and men with nothing better to do who regularly read Kotaku call their politicians about climate issues. The last few paragraphs of this article are a mess.

>It’s unlikely that video games will ever truly go extinct. We’ll probably always have something called “video games,” but what those games will look like is still very much in flux. There’s no guarantee that the way games are currently made will remain viable for another 10 years—games aren’t even made today the same way they were 10 years ago.

This is such a stupid paragraph. This is clearly written for a lowbrow audience they expect to easily manipulate.

>They will look different. They will change because they can, and because they must. Hopefully, all the ways games change will be on our terms—otherwise disaster will change them for us.

This is an entertainment medium, one that has a lot of garbage in it, at that. This is about video games and some idiot was paid to write this.

In closing, this isn't a great critique, but the article was garbage. I dislike there were enough cretins to put this on the front page, while interesting material written by interesting people goes entirely ignored. Those are my thoughts.

In any case, the obvious solution is to add your new element as the new third entry, if you care about this.

Now, moving on to this article, I agree with the parts of it that are directly influenced by the language, as that's clearly how one should write it; this isn't unique to this document nor to Common Lisp. I've had people criticize my Common Lisp just because I use parts of the language they weren't aware of or don't care for, which I find silly; people also enjoy trying to enforce usage rules where none exist and don't like seeing those broken, such as using #1= and #1# to indicate duplicated code where it's not otherwise easy to express.

I disagree with using libraries merely because they exist. What, a lack of libraries is bad, but don't write more? In any case, I make certain all of my libraries are rather comprehensive and well-documented; that's not much in the way of advice, though, since it's obvious. Common Lisp libraries aren't likely to change significantly, especially after several years, which is nice.

As for indentation, I generally use whatever Emacs gives me, except for LOOP, where I indent how I prefer it look; generally, two spaces is the indentation level, but here's an example where that isn't the case:

    (list 1
          2)

I use OR and AND for flow control more than WHEN or UNLESS, but this is my preference. There's nothing wrong with an IF that doesn't use both paths and claiming otherwise is silly arbitrary ruling. I further disagree with keeping conditions short; defining an entire function for a single condition is stupid.

Having a single package to a file is treating Common Lisp like other languages; it's completely unnecessary. Avoiding :USE is another asinine quality of this style guide; again, libraries are unlikely to change significantly and you can always avoid using the most recent version. Using hierarchical names is a bad idea, since they're not actually hiararchical, but this could trick others into believing they are and, again, pretends Common Lisp is some other language.

Lastly, I try to have my programs and libraries in a single file. What's nicer, looking through a single file or skulking around a large directory with many small files; I'll always prefer the former. If a file isn't even one thousand lines, why would you even consider breaking it into many files as other, poor languages are prone to do?

This recommendation of ''Continuous Integration'' has nothing whatsoever to do with Common Lisp style and Common Lisp isn't a language that needs this.

In brief, I don't care for this style guide, but it paints itself as authorative. My advice is to use Emacs and mimic the standard language where you can and, otherwise, do as you please until you derive your own rules; don't listen to others if you don't care to, although I believe my advice is good, you may disagree.

Only the Most Perfect Disk Pack Need Apply

One common problem with Unix is perfection: while offering none of its own, the operating system demands perfection from the hardware upon which it runs. That's because Unix programs usually don't check for hardware errors--they just blindly stumble along when things begin to fail, until they trip and panic. (Few people see this behavior nowadays, though, because most SCSI hard disks do know how to detect and map out blocks as the blocks begin to fail.)

...

In recent years, the Unix file system has appeared slightly more tolerant of disk woes simply because modern disk drives contain controllers that present the illusion of a perfect hard disk. (Indeed, when a modern SCSI hard disk controller detects a block going bad, it copies the data to another block elsewhere on the disk and then rewrites a mapping table. Unix never knows what happened.) But, as Seymour Cray used to say, ''You can't fake what you don't have.'' Sooner or later, the disk goes bad, and then the beauty of UFS shows through.

I actually have a (I think) rather novel approach and there's some potential for little optimizations here and there, but it disgusts me that I'm doing this at all. The optimizations popular, shitty formats like JSON receives are purely wasteful.

It's suitable, though. The WWW wasn't made right from the start and there's always an idiot somewhere looking to add more shit to the pile. Not only does JavaScript exist, but it morphed into this ugly, inefficient, very poor ''format''. We don't have Lisp machines, but new processors are getting instructions to cope with JavaScript idiocy.

A numerical (binary) format is clearly best. It's small, random-access when properly designed, and efficient, but hey, everything's being pushed into port 80 so why not push all data into JSON?

Now, the rest of this message is in response to @chrismorgan from an organization pushing this filth.

>Personally, I prefer binary formats where feasible, because I like pursuing efficiency to extremes, and write all my own code in Rust.

We agree on that, then, but I prefer to write that Rust is just the effeminate man's Ada.

>If you’re comparing JSON to s-expressions, it’s a wash in efficiency. They’re both “inefficient”, both representing generic data structures in regular text. They use slightly different punctuation, but that’s about it. The differences are negligible.

This is wrong. Firstly, we should clarify what is meant by S-expressions. Let's assume the S-expressions have lists, strings, symbols, and numbers. That's already simpler than JSON. You're not hampered by JavaScript's floating point nonsense, either. There's fewer edge cases and less escaping. JSON is, at best, a worse-is-better form of S-expressions.

>But when it comes to support, JSON is well-supported in all mainstream languages, while s-expressions have no central specification on precise syntax, and you’ll need to do your own thing. One of the deliberate design advantages of JMAP over IMAP is doing away with custom parsers, and using the standard tools people are familiar with, HTTPS and JSON.

So, this ties into what I wrote before I even read your post, exactly. Cretins continue to push everything into the WWW protocols and act like their garbage is standard, simple, acceptable, or wanted; it's only technically standard, but it's a bad standard. I'd bet my foot you also like ''DNS over HTTPS''. A numerical (binary) format should be used, because it's the best option and people can be expected to bother writing an acceptor for such important data. There are plenty of languages that can easily accept a numerical format, but not JSON; think of, say, Forth. Oh, but everyone writes in Rust and JavaScript nowadays, right.

>When talking efficiency, you might then ask why not to use Cap’n Proto, protobufs or one of those sorts of things. Due to the need for extensibility (e.g. in Fastmail we add a few custom fields to JMAP core and mail data structures), rigid structures are unsuitable; you do need arbitrary key-value arrangement, despite it being larger over the wire.

All of this is unnecessary. Email doesn't need this drivel.

>All in all, JSON is a robust choice for just about any API.

Of course; forty years ago, UNIX was the solution for every problem. The WWW and JavaScript are nothing more than a continuation of this worse-is-better filth.

>Fun fact: at Fastmail we compress both request and response, even using a custom dictionary primed on real JMAP stuff, to improve the compression ratio. I understand standard DEFLATE was about equivalent in size to CBOR (a binary representation of JSON), and the 2KB dictionary brought it down even further, can’t remember how much it was off the top of my head.

I hate how everyone's response to inefficiency is ''Compress it!'' and ''Cache it!''. There's no reason it should be so inefficient to start with.