People accidentally a scheme all the time. I first accidentalled a scheme in high school. I learned about S-types, which were to Lisp what JSON is to JavaScript. I made a language around then. Oops.
Some would argue Brendan Eich of Netscape accidentalled a scheme in JavaScript, but others would argue that he didn't. Most accidental schemes are pretty bad, and the original JavaScript fits the bill, or it doesn't, depending on what you think to be a scheme.
I bet this is a better accidental scheme, by virtue of the author, but a big part of the point of a scheme is that it's easy to implement, yet powerful. MIT freshman used to build a scheme interpreter and a scheme compiler in their first computer science course (6.001).
Yep, AFAIR he intentionallyed a scheme twice, but both times, the suits had a different idea (first time around, to ride on Java marketing; second time around, to compete with Microsoft and JScript).
* There is no such thing. The problem, as Clinton: "It depends on what the meaning of the word 'is' is."
S-types WERE a thing, but never a major one.
I ran across them as a high school student on a random research project at a university as a summer internship of some kind. They were used by a handful of research groups for some data interchange format. Literally the only person who would find the interesting is myself, and not for what they were, but because they were my first exposure to Lisp / Scheme concepts, which I had not heard of before, and which triggered a series of (high school grade) epiphanies for me (which would probably be obvious to 50+% of the people here).
As far as I know, S-types no longer exist. A quick web search brought up zero references. There is absolutely no reason to know about them in 2023. However, if you want to know about them:
- They were quite literally S-expressions. All S-types were S-expressions
- However, they were well-specified, so useful as an import/export format
- In particular, they had research-grade libraries to do the above from at least two languages (I would guess Java and LISP, but I no longer recall; perhaps it was C++ and Scheme).
- There was some attempt to simplify, but I no longer recall what it was. I recall that I was told it had something to do with lists versus function calls, but looking back on it, the explanation I recall being told makes zero sense. That's more likely a function of my memory than the explanation.
I believe on that internship, my direct use of them was probably limited to looking at some data in that format. This was really at the outskirts of the project I was doing. They did inspire a lot of work during the school year, when I schemed for the first time, not really knowing what I was doing but figuring out a lot of stuff in the process.
Looking back at it, though, having a standardized Python / JavaScript / etc. import/export library for some standardized version of S-expressions might be helpful. Or it might not be. Who knows.
Sounds a bit like the S-expression syntax that was developed for SPKI/SDSI in the 1990s. I am surprised to find that the old spec has been revived after over 25 years https://datatracker.ietf.org/doc/draft-rivest-sexp/
What is a Scheme and what is not a Scheme is actually pretty well defined in terms of language concepts and features. The JavaScript of back then is not that. Some Scheme may have served as something that Eich took hints from, but he did not create a new Scheme.
FYI: At the time, the creator of Scheme, Jerry Sussman, believed the JavaScript was a Scheme.
I don't say this to claim he was right (I didn't agree with him, at the time), but merely to point out that "what is not a Scheme is actually" NOT "pretty well defined in terms of language concepts and features."
A proper Scheme is as defined in Revised Report on the Algorithmic Language Scheme, but there are many improper half-baked Schemes too.
Reasonable people can and do disagree about which things do and don't qualify.
I think there is nothing more vacuous than taxonomy arguments (though they can be fun). Kent Pitman (KMP), for example, is on record as saying that Scheme is not a Lisp[1]
The story goes Eich was hired to embed Scheme in a browser, and hung on to lambdas and functional concepts but lost homoiconicity by management fiat; they didn’t like the weird way it looked. He tried to intentionally a Scheme and ended up accidentally a Scheme step-cousin. It’s fair to say some argue it is a Scheme dialect, because some people do, and they’re not wrong, JS does share aspects. It’s also fair to say JS is not a Scheme, also true.
I googled and found someone’s blog post with a fun description: “JS is stupid Lisp in Java’s ill-fitting clothing. It’s Alonzo Church going to a Halloween party as Alan Turing. It’s the lambda calculus in Turing-machine drag. It’s a quirky nerd with a cynical marketing department. (The syntax and the name of the language — JavaScript—were determined by Netscape’s desire to ride the coattails of Java’s popularity in the early 1990s.) It’s multiparadigm salad.” https://medium.com/thinking-with-computers/javascript-is-not...
For the story from Allen Wirfs-Brock and Brendan Eich.
Section 2.1, starting on page 7, talks about the portion of JS history where Eich was hired to build a Scheme in a browser and continues with why it changed and how.
There doesn't seem to be a lot of fun valid English writing today. Certainly it seems the opposite is the norm, even at the highest levels of government.
But I found joy very early in this essay. "Tonight's missive is an apology: not quite in the sense of expiation, though not quite not that, either; rather, apology in the sense of explanation, of exegesis: apologia."
When an introduction provides such a concise but entertaining junglegym for the reader, surely the rest will be enlightening. And if not, we have short attention spans, so we click elsewhere :).
Could someone please explain the missing verb in the title? It's clearly a deliberate omission in the linked post (which also has a section heading "one does not simply a scheme"), but I don't get it. Something to do w/ garbage collection, or a scheme inside joke?
If you're serious about learning a Lisp but motivated more by, as you say, "having more fun" rather than, say, landing a six-figure job writing it professionally... then may I recommend Janet[0] for your consideration. Janet is an embeddably-small, yet surprisingly batteries-included Lisp implemented in pure C. In terms of syntax and core library it borrows more directly from Clojure than from Scheme, but all the modern Lisps have their bits of influence. I've found both the language and the tiny little community that exists around it delightful.
As an example of the latter, somebody smart wrote a real actual book[1] about Janet recently that was on the HN front page for a day or so when he first released it. It's a gentle introduction not just to Janet but to Lisp in general, and assumes only general proficiency with JavaScript to get you up to speed. I recommend it.
Ooh that's actually really interesting. I've always been a bit into lisp... even did a bit of amatuer CL back in the day..but always thought the distribution model of basically a memory dump was just the worst of all possible worlds.
I agree with this sentiment -- from a reproducability standpoint, CL images aren't great. My workflow has always been to maintain a source file and then use emacs to shove s-expressions into the repl -- that way, rather then save the image, i can just re-evaluate my source file and get a reasonable facsimile
While I like Janet, and find it to be a lovely little language; I think it's important to note that it lacks lists and cons cells, and so as a result some people don't label it a lisp, and programming in it is unlike other lisp languages. It's similar, because the syntax is similar and the macros and various forms are lifted straight from lisps; but the feel of programming in it is very much like programming in C, and I find it's less like Scheme or Common Lisp.
Because it's not built around linked lists, the core type most encountered for lists of data is arrays and tuples. Neither is conducive to efficiently removing elements mid-set, or composing two sets, or interleaving two sets, or other operations that require reordering, replacing, adding or removing elements in the set. When I'm writing code in lisp I don't think about that overhead much, because for linked lists it's not an issue.
> Neither is conducive to efficiently removing elements mid-set, or composing two sets, or interleaving two sets, or other operations that require reordering, replacing, adding or removing elements in the set
That's based around a contrived problem that was posed to him:
> Insert a sequence of random integers into a sorted sequence, then remove those elements one by one as determined by a random sequece of positions: Do you use a vector (a contiguously allocated sequence of elements) or a linked list?
The key is that the sequence is sorted; and is kept sorted throughout the insertion process.
because it avoids all the pathological worse case performance unless you get insanely unlucky with the order the data is inserted... and even then you can do a rebalance if you're that concerned about it.
It depends on how you approach solving problems, and what the problem is.
In the contrived example, a linked list is clearly a terrible option for manipulating a sorted set of integers. Modern computers can slice and dice contiguous integers with vectorized routines, and those benefits are lost with linked lists that are storing their data haphazardly across the heap.
If your problem space is best defined with contiguously-stored numbers, then for sure, don't use linked lists. Most lisps will happily provide you with vectors and arrays for these use cases.
Yes, 100% to both the REPL and image-based development!
Janet's REPL has a debug mode, but I'm sadly not qualified to evaluate whether/how it measures up to CL's due to my own inexperience with either. :)
As for restarts (I had to Google around to get an idea of what that means)—it seems to me that Janet does not have first-class support for restarts in the way that some other Lisps, for e.g. CL, do. Presumably (as it would be in most other languages I would suppose) one could recreate that experience in Janet by tapping into the first-party error handling and REPL primitives. But you'd definitely be rolling your own rather than having it already in Janet out of the box.
Maybe Clojure. In 2022 it took the top spot for "Top paying technologies" in the annual StackOverflow survey [0], and in 2023 it tied with other lispy languages [1].
That said, I don't think it matters much. A developer familiar with some lispy language (and perhaps functional programming) should be able to quickly pickup any other lispy language. And the developers that make the most money have probably used a lot of programming languages, with different paradigms.
I had a lot of fun learning Clojure. While I don't use it in daily practice, I learned a lot about elegancy, the advantages of data immutability and using code as building blocks. For learning I used the 4clojure website where you can solve interactive coding puzzles and learn from solutions of others. See: https://4clojure.oxal.org
I got my first job furiously doing that for nights on end. It felt like cheating but it’s ultimately way faster than waiting potentially years to figure out those tricks on your own.
Yeah, good to hear. I also did this for nights on end. My strategy was to try to solve the puzzle myself first (in a reasonable amount of time) and then check the solutions of others. Always fun to see if I could make my solution faster/shorter/more elegant/etc. with the inspiration of the other solutions.
What are the odds that someone gets accused of plagiarism for doing exactly that? Like, say there's a perfect solution in existence with the fewest lines/tokens of code all the elegant shortcuts and maybe a little bit of "sorcery", how likely is it for two people to work their way down the perfect solution and it basically looks exactly the same, maybe they followed the same logical workflow to arrive there, who knows...
I don't know what the odds are of getting accused, but let's say this was in the context of an interview question, and every answer submitted looks almost 100% the same, or even more telling, has the same logic mistakes, then the odds could be high that plagiarism is afoot.
Say there's no mistakes. Its literally perfectly logical and conventionally written code. Its the epitome of that thing with Michaelangelo where he assumes his vision for the sculpture is correct and all he needs to do is surgically remove the excess marble to get to the essential form that is perfect and ideal and intutitive.
I recommend Common Lisp, it's fast, it's mature, and it has some wicked cool tools. You can find some resources here: <https://stevelosh.com/blog/2018/08/a-road-to-common-lisp>. You can also look at CLiki (the Common Lisp wiki), the Common Lisp Cookbook, and the Common Lisp Community Spec for information any basically anything you may be interested in.
On the risk of drawing the ire of our lisping friends, I find that I have more fun writing lisps than using them, at least unless I equip them with a syntax.
> The goal of the Make-A-Lisp project is to make it easy to write your own Lisp interpreter without sacrificing those many "Aha!" moments that come from ascending the McCarthy mountain. When you reach the peak of this particular mountain, you will have an interpreter for the mal Lisp language that is powerful enough to be self-hosting, meaning it will be able to run a mal interpreter written in mal itself.
If you don't know Lisp, and start writing your own, you're only learning your own concoction, and not any other Lisp. And that concoction has its limits. It doesn't compare to the breadth and scope of the Lisp culture.
Interacting only with something you have made is the worst possible way to learn anything about existing, mainstream Lisp.
Not knowing anything about the prior art will practically ensure that your own thing is a collection of quirks specific to it, and that then ensures that your Lisp knowledge is entirely rooted in and limited to that thing.
You're just not going to single-handedly reinvent things that took numerous hackers over several generations to figure out. You may be "good", but so were they, and there is only one of you.
You will not even be able to converse with actual Lisp people, due to not having the right concepts and terms.
I'm not sure which, if any, of my remarks apply to MAL specifically.
I don't have the impression that the author of the MAL project used it as a way of learning Lisp.
To my best understanding, MAL provides a step by step recipe and test cases for implementing a language dialect, plus example implementations for which that has been done.
Someone going through the MAL exercise will mainly interact with the chosen implementation language. Writing a new MAL implementation could be used as an exercise to learn some unfamiliar language.
I'm not convinced that programmers implementing MAL are actually learning how to use MAL, since it doesn't look as if the exercise requires them to write MAL code to solve problems. To learn MAL, you would take the project as-is with its integrated implementations and use that to get other work done.
Suppose someone actually learns MAL by working with it. Are they learning Lisp?
I'm not sure how much of their acquired skill will transfer to working with a mainstream Lisp. MAL looks rather like a kind of Mock Lisp (see: https://en.wikipedia.org/wiki/Mocklisp). It's implemented even in Bash and Awk using string processing.
The good thing about MAL is that at least the participants in the exercise are following a specification instead of just making something up as they go along and calling it Lisp. Making something that is compatible with a spec and other implementations is a good exercise for software engineering students, regardless of what it is. MAL would still be valuable that way if it was, say, MAVE: make a vi editor, or MAM: make a Mario game.
I have no idea how effective MAL is educationally in teaching the concepts themselves that underpin MAL, which revolves around this question: is it possible to mechanically follow the recipe and get a new implementation working, without understanding the concepts? Separately from the question of whether MAL concepts are Lisp concepts, is the MAL implementor who follows the structured workflow learning the MAL concepts, or are they just massaging code to get some tests to pass. (But, of course, even if they are, so what; nothing stands in their way of learning any concepts they want in any other manner.)
Proper verbing would be "accidented", I believe (and I love English for how you can just verb or noun anything - it's like Lisp of natural languages!), but I guess "accidentally" can be chalked up to artistic license.
English has zero-derivation of verbs [that is, the form of the derived verb is identical to the form of the word from which the verb was derived], and this construction is highly productive; many people have remarked on it. But there's nothing similar for nouns in English, so I don't see why you're listing nouns as parallel to verbs.
The meme expression "I accidentally [missing verb] [something]" does not obey the rules of English, as you can easily tell by the responses saying "you accidentally did what?"
If you really meant that parenthetical, you might be interested in Chinese, where academics sometimes get into arguments over what part of speech a given example of a word should be considered to belong to. There is very little inflection, which makes the confusion possible.
I'm speaking more about language culture, as it's used. My native language, Polish, allows for convenient derivation, but it's not a natural thing to do, and if you try, people will look at you funny. In English, it feels very natural and people will understand you when you do it.
> My native language, Polish, allows for convenient derivation, but it's not a natural thing to do, and if you try, people will look at you funny.
Cultural differences do crop up. The Romans mostly believed that if you wanted to talk about philosophy, you had to do it in Greek; there is a speech preserved from Cicero in which he complains about this belief and gives several examples of how it's possible to say the same things in Latin by using parallel derivational mechanisms. Construction of new words from roots was common in Greek and unusual in Latin.
That's verbing a noun, but I don't think that's what is going on here. I think the title is trying to verb an adverb.
If the "correct" sentence is "I accidentally created a scheme", then I think it would be "accidentallied". In excising the verb, shouldn't one carry its tense over to the adverb?
If the "correct" sentence is "I created an accidental scheme", then it would be "acidentalled".
But verbing the adjective doesn't have the same rhythm as verbing the adverb, in this case. And rhythm is the most important rule of English. The indefinite article needs to fall on a low note, and the adverb form is flexible enough to end on a high note to give a lilting affirmation, whereas the adjective form is not.
If I were diagramming it, I think I’d still label “accidentally” as an adverb, but would note that the corresponding verb has been omitted. It’s the written equivalent of hearing “Oh my, there’s a gigantic <RADIO STATIC> blocking the road.” The unknown word blocked by the radio static is still the noun, we just don’t know what it is.
It was originally a meta-joke way of pointing out you'd left something out by intentionally leaving out the verb in the sentence where you pointed out you'd left something out.
It's since become a meme of sort as a more general way to flag as a joke that you've done something "accidentally" where a fully formed sentence would be more ambiguous.
E.g. "I accidentally created a scheme" might still not be entirely serious about it being an accident, but it's open to interpretation and sets a slightly more serious tone. "I accidentally a scheme" clearly signposts the title is at least in part a joke.
I now really want a comprehensive history of its use. It feels recent, but it's also the type of thing it'd be unsurprising to find isolated examples of independent "invention" of from long before it came into common use...
Lol would have become widely used with text messages which is when I came across it, it could have been used back in the BBS days.
"I accidentally a" is basically just teenage humour.
I accidentally <implied sexual thing> a $X. (Obviously becoming more funny the more unlikely it is for any sexual thing to work on whatever $X is).
On top of that you've got the weird language construction, just like speaking like Yoda is hilarious, and you have the perfect thing to spread throughout the playground.
Although internet usage doesn't imply the sexual act.
I accidentally a house
Means i accidentally built? A house.
It's exactly because it's such easy humour I'm curious if there are any older expected uses... It seems pretty clear it gained prominence with the YouTube video someone has referenced, and it may indeed be the first, but we may never really know.
Well this was in real life, so you aren't going to get records.
Wikipedia suggests lol is more like 40 years old, but you actually have a written record to back that up.
All I have is my own experience, I wasn't really on the internet until the 2000s so I wouldn't have come across lol until mobile phones and texting became widespread (around 1999/2000).
"I accidentally a" would have been in the 1995 - 2000 time frame. But again that's just my experience of it.
I’ll stand as witness to the fact that ordinary people playfully tortured the language towards humorously cute long, long before one TRS-80 could call another over the phone. The tech just helped these people find and feed off of each other.
Nah, "I accidentally" came way after "lol". I remember using "lol" as a kid on MSN/ICQ/IRC and "I accidentally" wasn't around until I was a teen at the earliest.
That's true for most language changes, but this is not particularly new at this point, though still new enough that it's understandable that it'll be misunderstood.
I would say yes. A compiler takes code and produces different code. Maybe in another language. I wouldnt call a simple anaphoric if a compiler, but I wrote this: https://git.sr.ht/~bjoli/goof-loop and it specifies a new loop construct for scheme. It takes code conforming to a grammar and produces standard scheme code while also generating loop code, temporary variables, identifiers and all that jazz. It even transforms the code using CPS. That is what you get for writing complex macros in syntax-rules I guess.
I am french I read your comment then read again the title to see what was wrong and I noticed my brain automatically added the word "entered" after accidentally. So yes I understand your feeling
I have english as my first language but I moved to a country where most people learn it as a second language and people are horrified to see how I communicate with my sister. Of course, I wouldn't do it with them when i'm actually trying to communicate effectively. I think its one of those "when you understand the rules well you can break them" type thing, here it indicates a carefree and playful tone, for a similar reason to how the lack of capitalisation in the title etc indicates a casual tone. It's trying to avoid being Official and Boastful and Buisnesslike.
In particular, the first sentence is similarly playful with its choice of words; suffice to say this is intentionally poetry
Would it help to still consider "accidentally" as an adverb, but modifying an omitted verb? As a native English-speaker, that's how I tend to parse it.
Up until the end of the sentence, the reader doesn't know whether a verb is going to occur. English usually arranges a sentence with subject-verb-object ordering ("I ate my meal."), and not subject-object-verb ordering ("I my meal ate."), so this is unlikely. However, variations occur, such as "Neither a borrower nor a lender be." in Macbeth, or "Frankincense to offer have I" from We Three Kings. These tend to be somewhat archaic usage, and so an author may deliberately use this tone for a sense of formality.
This is similar to a garden-path sentence [0], where the sentence cannot be easily parsed in order. Up until the title ends, we don't know if the title will so formal that it changes up the word ordering (e.g. "I accidentally a scheme brought forth.") or so informal that it omitted a word without realizing it. This contrast between extreme formality and extreme informality becomes a source of humor when resolved.
(And by dissecting a joke, I have made it that much funnier. I'm great at parties.)
Until I read all the way down here to the bottom of the comment thread, I was thinking about the older people who didn't get this reference since I've been hearing it for decades. But now I see, thanks to your comment, that it is I that is the old one, and it's the youngsters that don't know it.
The odd lack of verbs (in the title and the text) made me immediately suspect this was an unfortunate AI submission. Is omitting verbs part of the inside joke of Lisp communities?
It’s a pretty common thing all over the internet to deliberately butcher the language for humorous effect. The LOLcat (“I can has cheeseburger “) translation of the Bible is hilarious.
He has a marvelous drawing approach. I've not yet found any other similar drawings that really quite capture the same style. I was honored that he agreed to make some drawings for a project of mine years ago; I still have the originals in a frame.
I accidentally a Common Lisp that interoperates with C++ (https://github.com/clasp-developers/clasp.git). We would also like to move beyond BDWGC and the Whiffle GC looks interesting. I will reach out to you, and maybe we can chat about it.
FWIW we also test the Oils GC with a X-to-Y to generator, where X is Python and not Scheme, and Y is C++ and not C :)
For example here's a self-contained Python program to make various types of linked lists and traverse them, making sure the GC can follow the resulting pointers in C++, with field inheritance, vtable pointers, etc.
142 comments
[ 3.3 ms ] story [ 210 ms ] threadSome would argue Brendan Eich of Netscape accidentalled a scheme in JavaScript, but others would argue that he didn't. Most accidental schemes are pretty bad, and the original JavaScript fits the bill, or it doesn't, depending on what you think to be a scheme.
There's a law about that: https://en.wikipedia.org/wiki/Greenspun's_tenth_rule
It comes up in most DSLs.
I bet this is a better accidental scheme, by virtue of the author, but a big part of the point of a scheme is that it's easy to implement, yet powerful. MIT freshman used to build a scheme interpreter and a scheme compiler in their first computer science course (6.001).
It's very easy to accidentally a scheme.
A scheme is for life, not just for Christmas.
Do you mean s-expressions here (sexps), or is there also a thing called s-types that I've been missing?
* I meant s-types.
* There is no such thing. The problem, as Clinton: "It depends on what the meaning of the word 'is' is."
S-types WERE a thing, but never a major one.
I ran across them as a high school student on a random research project at a university as a summer internship of some kind. They were used by a handful of research groups for some data interchange format. Literally the only person who would find the interesting is myself, and not for what they were, but because they were my first exposure to Lisp / Scheme concepts, which I had not heard of before, and which triggered a series of (high school grade) epiphanies for me (which would probably be obvious to 50+% of the people here).
As far as I know, S-types no longer exist. A quick web search brought up zero references. There is absolutely no reason to know about them in 2023. However, if you want to know about them:
- They were quite literally S-expressions. All S-types were S-expressions
- However, they were well-specified, so useful as an import/export format
- In particular, they had research-grade libraries to do the above from at least two languages (I would guess Java and LISP, but I no longer recall; perhaps it was C++ and Scheme).
- There was some attempt to simplify, but I no longer recall what it was. I recall that I was told it had something to do with lists versus function calls, but looking back on it, the explanation I recall being told makes zero sense. That's more likely a function of my memory than the explanation.
I believe on that internship, my direct use of them was probably limited to looking at some data in that format. This was really at the outskirts of the project I was doing. They did inspire a lot of work during the school year, when I schemed for the first time, not really knowing what I was doing but figuring out a lot of stuff in the process.
Looking back at it, though, having a standardized Python / JavaScript / etc. import/export library for some standardized version of S-expressions might be helpful. Or it might not be. Who knows.
The thread at <https://www.spinics.net/lists/ietf/thrd4.html#115999> seems to be relevant. Especially <https://www.spinics.net/lists/ietf/msg116441.html>.
I don't say this to claim he was right (I didn't agree with him, at the time), but merely to point out that "what is not a Scheme is actually" NOT "pretty well defined in terms of language concepts and features."
A proper Scheme is as defined in Revised Report on the Algorithmic Language Scheme, but there are many improper half-baked Schemes too.
Reasonable people can and do disagree about which things do and don't qualify.
1: https://groups.google.com/g/comp.lang.lisp/c/Bj8Hx6mZEYI/m/6... (besides the inevitable flamewar started by @lisper's question, there's actually some good discussion between the "adults in the room" well downthread of what I linked).
I googled and found someone’s blog post with a fun description: “JS is stupid Lisp in Java’s ill-fitting clothing. It’s Alonzo Church going to a Halloween party as Alan Turing. It’s the lambda calculus in Turing-machine drag. It’s a quirky nerd with a cynical marketing department. (The syntax and the name of the language — JavaScript—were determined by Netscape’s desire to ride the coattails of Java’s popularity in the early 1990s.) It’s multiparadigm salad.” https://medium.com/thinking-with-computers/javascript-is-not...
For the story from Allen Wirfs-Brock and Brendan Eich.
Section 2.1, starting on page 7, talks about the portion of JS history where Eich was hired to build a Scheme in a browser and continues with why it changed and how.
That was my first thought too. As the length of your codebase increases, the likelihood of (probably badly) accidentally a scheme'ing tends towards 1.
But I found joy very early in this essay. "Tonight's missive is an apology: not quite in the sense of expiation, though not quite not that, either; rather, apology in the sense of explanation, of exegesis: apologia."
When an introduction provides such a concise but entertaining junglegym for the reader, surely the rest will be enlightening. And if not, we have short attention spans, so we click elsewhere :).
If you're serious about learning a Lisp but motivated more by, as you say, "having more fun" rather than, say, landing a six-figure job writing it professionally... then may I recommend Janet[0] for your consideration. Janet is an embeddably-small, yet surprisingly batteries-included Lisp implemented in pure C. In terms of syntax and core library it borrows more directly from Clojure than from Scheme, but all the modern Lisps have their bits of influence. I've found both the language and the tiny little community that exists around it delightful.
As an example of the latter, somebody smart wrote a real actual book[1] about Janet recently that was on the HN front page for a day or so when he first released it. It's a gentle introduction not just to Janet but to Lisp in general, and assumes only general proficiency with JavaScript to get you up to speed. I recommend it.
[0] https://www.janet-lang.org
[1] https://janet.guide
Because it's not built around linked lists, the core type most encountered for lists of data is arrays and tuples. Neither is conducive to efficiently removing elements mid-set, or composing two sets, or interleaving two sets, or other operations that require reordering, replacing, adding or removing elements in the set. When I'm writing code in lisp I don't think about that overhead much, because for linked lists it's not an issue.
Read this: https://isocpp.org/blog/2014/06/stroustrup-lists
> Insert a sequence of random integers into a sorted sequence, then remove those elements one by one as determined by a random sequece of positions: Do you use a vector (a contiguously allocated sequence of elements) or a linked list?
The key is that the sequence is sorted; and is kept sorted throughout the insertion process.
And yet a subset of the linked list called a tree is usually the right answer to problems.
In the contrived example, a linked list is clearly a terrible option for manipulating a sorted set of integers. Modern computers can slice and dice contiguous integers with vectorized routines, and those benefits are lost with linked lists that are storing their data haphazardly across the heap.
If your problem space is best defined with contiguously-stored numbers, then for sure, don't use linked lists. Most lisps will happily provide you with vectors and arrays for these use cases.
Janet's REPL has a debug mode, but I'm sadly not qualified to evaluate whether/how it measures up to CL's due to my own inexperience with either. :)
As for restarts (I had to Google around to get an idea of what that means)—it seems to me that Janet does not have first-class support for restarts in the way that some other Lisps, for e.g. CL, do. Presumably (as it would be in most other languages I would suppose) one could recreate that experience in Janet by tapping into the first-party error handling and REPL primitives. But you'd definitely be rolling your own rather than having it already in Janet out of the box.
What Lisp should we learn if we want to make money from it?
That said, I don't think it matters much. A developer familiar with some lispy language (and perhaps functional programming) should be able to quickly pickup any other lispy language. And the developers that make the most money have probably used a lot of programming languages, with different paradigms.
[0]: https://survey.stackoverflow.co/2022/#top-paying-technologie...
[1]: https://survey.stackoverflow.co/2023/#section-top-paying-tec...
I got my first job furiously doing that for nights on end. It felt like cheating but it’s ultimately way faster than waiting potentially years to figure out those tricks on your own.
Edit: like a hash-collision for geeks
> The goal of the Make-A-Lisp project is to make it easy to write your own Lisp interpreter without sacrificing those many "Aha!" moments that come from ascending the McCarthy mountain. When you reach the peak of this particular mountain, you will have an interpreter for the mal Lisp language that is powerful enough to be self-hosting, meaning it will be able to run a mal interpreter written in mal itself.
~ https://github.com/kanaka/mal/blob/master/process/guide.md
https://github.com/kanaka/mal
Interacting only with something you have made is the worst possible way to learn anything about existing, mainstream Lisp.
Not knowing anything about the prior art will practically ensure that your own thing is a collection of quirks specific to it, and that then ensures that your Lisp knowledge is entirely rooted in and limited to that thing.
You're just not going to single-handedly reinvent things that took numerous hackers over several generations to figure out. You may be "good", but so were they, and there is only one of you.
You will not even be able to converse with actual Lisp people, due to not having the right concepts and terms.
I feel MAL does a decent job illustrating the core concepts of Lisp, but then I'm not a Lisp expert by any means.
I don't have the impression that the author of the MAL project used it as a way of learning Lisp.
To my best understanding, MAL provides a step by step recipe and test cases for implementing a language dialect, plus example implementations for which that has been done.
Someone going through the MAL exercise will mainly interact with the chosen implementation language. Writing a new MAL implementation could be used as an exercise to learn some unfamiliar language.
I'm not convinced that programmers implementing MAL are actually learning how to use MAL, since it doesn't look as if the exercise requires them to write MAL code to solve problems. To learn MAL, you would take the project as-is with its integrated implementations and use that to get other work done.
Suppose someone actually learns MAL by working with it. Are they learning Lisp?
I'm not sure how much of their acquired skill will transfer to working with a mainstream Lisp. MAL looks rather like a kind of Mock Lisp (see: https://en.wikipedia.org/wiki/Mocklisp). It's implemented even in Bash and Awk using string processing.
The good thing about MAL is that at least the participants in the exercise are following a specification instead of just making something up as they go along and calling it Lisp. Making something that is compatible with a spec and other implementations is a good exercise for software engineering students, regardless of what it is. MAL would still be valuable that way if it was, say, MAVE: make a vi editor, or MAM: make a Mario game.
I have no idea how effective MAL is educationally in teaching the concepts themselves that underpin MAL, which revolves around this question: is it possible to mechanically follow the recipe and get a new implementation working, without understanding the concepts? Separately from the question of whether MAL concepts are Lisp concepts, is the MAL implementor who follows the structured workflow learning the MAL concepts, or are they just massaging code to get some tests to pass. (But, of course, even if they are, so what; nothing stands in their way of learning any concepts they want in any other manner.)
Does he regularly a scheme? Or did he do it in the past? Both!
This is an odd observation. All languages have derivation. ( https://en.wikipedia.org/wiki/Morphological_derivation )
English has zero-derivation of verbs [that is, the form of the derived verb is identical to the form of the word from which the verb was derived], and this construction is highly productive; many people have remarked on it. But there's nothing similar for nouns in English, so I don't see why you're listing nouns as parallel to verbs.
The meme expression "I accidentally [missing verb] [something]" does not obey the rules of English, as you can easily tell by the responses saying "you accidentally did what?"
If you really meant that parenthetical, you might be interested in Chinese, where academics sometimes get into arguments over what part of speech a given example of a word should be considered to belong to. There is very little inflection, which makes the confusion possible.
Cultural differences do crop up. The Romans mostly believed that if you wanted to talk about philosophy, you had to do it in Greek; there is a speech preserved from Cicero in which he complains about this belief and gives several examples of how it's possible to say the same things in Latin by using parallel derivational mechanisms. Construction of new words from roots was common in Greek and unusual in Latin.
If the "correct" sentence is "I accidentally created a scheme", then I think it would be "accidentallied". In excising the verb, shouldn't one carry its tense over to the adverb?
If the "correct" sentence is "I created an accidental scheme", then it would be "acidentalled".
But verbing the adjective doesn't have the same rhythm as verbing the adverb, in this case. And rhythm is the most important rule of English. The indefinite article needs to fall on a low note, and the adverb form is flexible enough to end on a high note to give a lilting affirmation, whereas the adjective form is not.
It's since become a meme of sort as a more general way to flag as a joke that you've done something "accidentally" where a fully formed sentence would be more ambiguous.
E.g. "I accidentally created a scheme" might still not be entirely serious about it being an accident, but it's open to interpretation and sets a slightly more serious tone. "I accidentally a scheme" clearly signposts the title is at least in part a joke.
I seem to recall it from high school, and that was before mobiles were widespread.
Lol would have become widely used with text messages which is when I came across it, it could have been used back in the BBS days.
"I accidentally a" is basically just teenage humour.
I accidentally <implied sexual thing> a $X. (Obviously becoming more funny the more unlikely it is for any sexual thing to work on whatever $X is).
On top of that you've got the weird language construction, just like speaking like Yoda is hilarious, and you have the perfect thing to spread throughout the playground.
Although internet usage doesn't imply the sexual act.
I accidentally a house Means i accidentally built? A house.
Not I accidentally had sex with a house.
Wikipedia suggests lol is more like 40 years old, but you actually have a written record to back that up.
All I have is my own experience, I wasn't really on the internet until the 2000s so I wouldn't have come across lol until mobile phones and texting became widespread (around 1999/2000).
"I accidentally a" would have been in the 1995 - 2000 time frame. But again that's just my experience of it.
"I accidentally" started in 2008, and they have a link to the youtube video it came from: https://knowyourmeme.com/memes/i-accidentally
https://knowyourmeme.com/memes/i-accidentally
"LOL" goes back to IRC so at least 1980s or so.
https://en.wiktionary.org/wiki/LOL#cite_note-mcculloch-1
Not if you're unfamiliar with the joke. And with the lack of capitalization, the bad grammar had me figuring this was an ESL author.
I want to frame this sentence and hang it on my wall.
In particular, the first sentence is similarly playful with its choice of words; suffice to say this is intentionally poetry
Up until the end of the sentence, the reader doesn't know whether a verb is going to occur. English usually arranges a sentence with subject-verb-object ordering ("I ate my meal."), and not subject-object-verb ordering ("I my meal ate."), so this is unlikely. However, variations occur, such as "Neither a borrower nor a lender be." in Macbeth, or "Frankincense to offer have I" from We Three Kings. These tend to be somewhat archaic usage, and so an author may deliberately use this tone for a sense of formality.
This is similar to a garden-path sentence [0], where the sentence cannot be easily parsed in order. Up until the title ends, we don't know if the title will so formal that it changes up the word ordering (e.g. "I accidentally a scheme brought forth.") or so informal that it omitted a word without realizing it. This contrast between extreme formality and extreme informality becomes a source of humor when resolved.
(And by dissecting a joke, I have made it that much funnier. I'm great at parties.)
[0] https://en.wikipedia.org/wiki/Garden-path_sentence
The title is from a meme. Like before the memes of today, when a meme was an image around a black frame with white text.
It usually goes "I accidentally a <thing>".
Rosanna, Rosanna, to Parton the Lamb!
https://web.archive.org/web/20190327161227/http://www.lolcat...
https://knowyourmeme.com/memes/i-accidentally
Happy retirement to him!
I knew I was not in favor of GCs. For any reason. A pox upon the landscape of software.
For example here's a self-contained Python program to make various types of linked lists and traverse them, making sure the GC can follow the resulting pointers in C++, with field inheritance, vtable pointers, etc.
https://github.com/oilshell/oil/blob/master/mycpp/examples/c...
Stealing that expression.