I’ve Consed Every Pair
medium.com
medium.com
I like his poem in the article!
A little off topic, but I retired (that is a bit of a joke) and at the age of 69, this year I decided that for maximum programming enjoyment I would only use Lisp languages (linking in Python and TensorFlow on occasion). I am approaching 40 years using Common Lisp and using the language is so much fun. I bought a license for LispWorks and using it for developing a semantic web app.
Also have you heard of Janet* ? what are your thoughts on such an approach ?
I had not heard of Janet, thanks for the link.
For resources, I would recommend Practical Common Lisp[0] and PAIP[1].
For some modern development practices, the Common Lisp Cookbook[2] is great.
[0]: http://www.gigamonkeys.com/book/
I guess I have even more to learn then :). Thank you for the links.
There are lots of different Lisp's though. Clojure is the most popular one that runs on the JVM and idiomatic Clojure is generally pretty functional although it calls out to lots of Java which is OO.
The idea that "functional language" means "purity" is something that was retconned onto functional programming in the 90s decades after Lisp had defined functional programming to mean programming in terms of expressions that produce values.
I like the ML/Miranda/Haskell lineage of languages a lot, but it really bugs me when people in that camp lay claim to some notion of being a "better" functional language than the older Lisp family. (Lispers, while smug about many other things, are generally less smug about how "pure" their languages' approach to functional programming is.)
This is like arguing that Lagavulin isn't "really" whiskey because real whiskeys are made in the US from corn mash.
But it took JavaScript to invent the concept of "Truthy".
In the beginning, "functional" meant functions were first-class objects and there was little--if any--global state. Lisp passes this test. Lisp invented this test (especially Scheme which introduced lexical scoping and closures).
If you want to write code with immutable data, you can certainly do so with Lisp; it just doesn't force you to. For the most part Lisp creates a brand new data structure when you "modify" an old one. You have to work a bit harder to actually mutate things.
Where e.g. Haskell is "more" functional than Lisp is more about automatic currying than immutability. Plus the static type system that allows monadic programming, which is much more difficult in Lisp because of Lisp's dynamic typing.
On Lisp is out of print, but can be downloaded.
They also have IDE like tools that are probably ready to go outside the box. Emacs with Slime isn't for everyone (I find it to be a big initial hurdle). Although I'm sure this guy is an Uber emacs expert.
Perhaps we can summon u/lispm for an answer here. I think he possibly works for LispWorks and is usually one of the lisp users on HN & Reddit that can answer questions pretty quick.
I'm not sure I understand what you meant there, but you can use LispWorks with Emacs/Slime.
LispWorks is a relatively expensive commercial implementation of Common Lisp. There might be several reasons to buy it: cross platform GUI support (Windows, Linux/Unix, Mac), integrated IDE, various delivery options for applications, support for various hardware / operating systems, ... I personally also find the runtime system quite robust.
LispWorks has a very nice portable UI library. That was the selling point for me.
How do you like their IDE compared to emacs/slime?
Personally I prefer the CCL IDE but it only works on the Mac.
https://nextjournal.com/kommen/gigasquids-libpython-clj-exam...
Would bet to be HolyC or "I might be wrong"
Ironically, Clojure doesn't use cons cells, although it does have a cons function.
Don't confuse CONS ARTISTS:
https://en.wikipedia.org/wiki/Category:Lisp_people
With CON ARTISTS:
cons n.v. 1. n. a compound data object having two components called the car and the cdr. 2. v. to create such an object. 3. v. Idiom. to create any object, or to allocate storage.
His book AI programming(Lisp version) is a gem that I enjoy reading. I've finish a book a few times already - but every time I read I find something new that I missed previous time.
https://news.ycombinator.com/item?id=9844026
That same Open Firmware Forth system [1], which was developed by Mitch Bradley [2], was not only in the PowerPC Mac bios, but it was originally used for the SparcStation boot roms, and eventually in the OLPC, and it was even an IEEE Standard 1275-1994!
[1] https://en.wikipedia.org/wiki/Open_Firmware
[2] https://en.wikipedia.org/wiki/Mitch_Bradley
In fact: the Open Firmware boot loader and plug-in card firmware interface technology, commonly used by both Sun and Apple, is the only firmware standard in existence to have its own theme song [3] !!!
[3] https://web.archive.org/web/20070204145613/http://playground...
: OpenFirmwareSong ( - )
\ By Mitch Bradley.
\ Sung to the tune of "The Flintstones".
𝄞
." Firmware" cr
." Open Firmware" cr
." It's the appropriate technology," cr
." Features" cr
." FCode booting" cr
." Hierarchical DevInfo tree." cr
." Hack Forth" cr
." Using Emacs on the keys," cr
." Save in" cr
." NVRAM if you please." cr
𝄒 cr
." With your" cr
." Open Firmware" cr
." You can fix the bugs in no time" cr
." Bring the kernel up in no time" cr
." We'll have an FCode time!" cr
𝄒 cr
\ Thank you and good night!
reboot
;Speaking of consing every pair, here's a previous discussion about "The Origin of CAR and CDR in Lisp (2005) (iwriteiam.nl)":
https://news.ycombinator.com/item?id=22910702
https://www.youtube.com/watch?v=mZyvIHYn2zk
https://s3-us-west-2.amazonaws.com/vulk-blog/ThePervertsGuid...
The main issue that arc solves is that it gives you a full pipeline for managing "objects with properties" via the web. It's so flexible. I wrote a thread on how we're using it in production to manage our TPUs: https://twitter.com/theshawwn/status/1247570883306119170
It's an interesting approach, as attempts to force statefulness on a stateless-by-design protocol go, but I don't know that I like how it scales.
You're right, it has some downfalls. But a lot of the time it simply doesn't matter. All the links at https://www.tensorfork.com/tpus are dynamic, and the speed you gain by being able to whip up a feature in 10 minutes is worth the pain of an occasional dead link.
On the other hand, I did some work for "deduplicating fnids": http://arclanguage.com/item?id=20996 which the site is using, so the links possibly last much longer than the early-HN links.
(Basically, we calculate the fnid key based on the lexical environment, rather than using a random ID each time the page is loaded. So each link gets a unique ID based on the code structure rather than a random ID. Meaning, instead of millions of random links to store, you end up with a few tens of thousands.)
https://en.wikipedia.org/wiki/Fnord
Or are they more like Vermicious Knids?
Basically, if you have a closure that does a certain action – e.g. editing a comment – Arc generates new a closure every page refresh. That was the root reason for the "dead link problem" during the early days of HN. I reworked it to make the closure IDs deterministic.
If you walk the source code from the point of the closure up to the root, and then you stick all the local variables in a list and use that as a key, then hash that, along with the actual source code, you end up with something that (a) has a very low probability of collision, and (b) is deterministic each time the page refreshes, unless the variables' values change. (E.g. if you store the current time in a local variable, the value changes, so the fnid will change as well, since that value is captured by the closure and therefore the closure has to do something different by definition.)
(I know there's no way to answer that last question, but that doesn't mean its answer is equal to zero.)
(I made a few other improvements, like having accurate line numbers in error messages, and a clojure-style REPL for emacs: https://www.youtube.com/watch?v=3v1KpEmuPeM)
This is everything that is wrong with the software industry, summarized in one sentence. Speed gain enjoyed by developers is paid for by the users in pain.
It used to be that developers would go through tremendous amounts of pain just to squeeze out a few instructions from a UI drawing routine in order to make it just a little bit smoother for the users. Now those developers are derided as "greybeards."
I'm sorry, I probably could have found a less harsh and cynical way of writing all that, but I feel like the Internet is getting worse everyday and there's not enough urgency among tech people.
Closures on a server are a powerful way of representing data flows. But they come at a cost: the links expire after some time. How do you strike a balance?
The simplest way is to put in the extra time to make everything into a persistent link. But, that's equivalent to removing all the benefits of lexical scoping. If you've ever created an inner function before, you know how powerful that technique can be. You can encode the entire state of the program into closures -- no need to store things in databases. Want a password reset link? Spin up a closure, email the link, done. Literally identical to storing a reset token in a database, except there's no database.
Another solution is to fix the root problem. Does the closure really need a random ID every time the page refreshes? The closure links die because they have to be GC'd periodically, to keep memory usage down. Even if you cache the page for 90 seconds, that's still 960 refreshes per day for logged-out users. Then if you have a few hundred regular users, that's at least another factor of two. And certain pages might create hundreds of closure links each refresh, so it quickly gets out of hand.
Ironically, the solution was emacs -- in emacs, they store closures in a printable way. A closure is literally a list of variable values plus the function's source code. That got me thinking -- why not use that as the key, instead of making a random key each time the page refreshes? After all, if the function's lexical variables are identical, then it should produce identical results each time it's run. No need to create another one.
That's what I did. It took a week or so, which is a week I'll never get back for building new features. But at least users won't have to deal with dead links anymore.
Clever readers will note a theoretical security flaw: an attacker might be able to guess your function IDs if they knew the entire state of the closure + the closure's source code (which is the default case for an open source project). That might give them access to e.g. your admin links. But that's not an indictment of the technique; it's easily solved by concatenating the key with a random ID generated at startup, and hashing that. I'm just making a note of it here in case some reader wants to try implementing this idea in their own framework.
The closure technique has nontrivial productivity speedups (that I think someone will rediscover some years from now). I hope the idea becomes more popular over time.
How about a keepalive from the client side: little bit of JavaScript that somehow tells the server that the session is still alive, so don't blow away the closure or continuation.
1. inside of your express endpoint, create a closure that captures some state. For example, the user's IP address.
(This is a dumb example, but the point is that you can capture whatever state you want. Some cases are mentioned here: http://paulgraham.com/road.html and here: http://ep.yimg.com/ty/cdn/paulgraham/bbnexcerpts.txt)
EDIT: I updated this to capture the date + time the original page was loaded, which is slightly more compelling than a mere IP address.
app.get('/', function (req, res) {
let ip = req.headers['x-forwarded-for'] || req.connection.remoteAddress;
let now = new Date();
let date = now.getFullYear()+'-'+(now.getMonth()+1)+'-'+now.getDate();
let time = now.getHours() + ":" + now.getMinutes() + ":" + now.getSeconds();
let fn = (req, res) => {
res.send(`hello ${req.query.name}. On ${date} at {time}, your IP address was ${ip}`)
}
... see below ...
})
g_fnids = {};
app.get('/', function (req, res) {
let fn = ...
let id = <generate random ID>
g_fnids[id] = fn;
res.send(`<a href="/x?fnid=${id}&name=bob">Say hello</a>`);
})
app.get('/x', function (req, res) {
let id = req.query.fnid;
let fn = g_fnids[id];
fn(req, res)
}
Congratulations, your closure is now an express endpoint. Except you didn't have to name it. You can link users to it like `<a href="/x?fnid=<function id>&name=bob">Say hello</a>`.
The reason this is a powerful technique is that you can use it with forms. The form target can be /x, and the query params are whatever the user types into the form fields.
I bet you already see a few interesting use cases. And you might notice that this makes scaling the server a little more difficult, since incoming requests have to be routed to the server containing the actual closure. But in the meantime, you now have "inner functions" in your web framework. It makes implementing password reset functionality completely trivial, and no database required.
If it seems slightly annoying to use – "I thought you said this was a productivity boost. But it's annoying to type all of that!" – lisp macros hide all of this boilerplate code, so there's zero extra typing. You can get lisp macros for Javascript using Lumen lisp: https://github.com/sctb/lumen
Even without macros, though, I bet this technique is shorter. Suppose you had to store the date + time + IP address somewhere. Where would you put it? I assume some sort of nosql database like firebase. But wouldn’t that code be much longer and more annoying to write? So this technique has tremendous value, and I’m amazed no one is using it circa 2020.
I think I may be missing something someone who's actually worked with lisp can see, to me closure, recursion and functional programming is cool but I can do everything its showing off using the standard fare of loops and databases.
What 'sillysaurusx describes is much more similar to what, in Scheme and elsewhere but these days mainly there, is called "continuation-passing style". It's a way of pausing a partially completed computation indefinitely by wrapping it up in a function that closes over the state of the computation when you create it, and calling that function later to pick up from where you left off when you're ready to proceed again.
I suppose you could maybe do that with an AWS Lambda, but because the technique relies strongly on the runtime instance staying around until the computation finishes, it would probably get expensive. Lambdas aren't priced to stay running, after all.
As a side note, it's worth mentioning that the "AWS Lambda" product, which whatever its virtues isn't actually a lambda, derives its name from the lambda calculus, where I believe the concept of anonymous first-class functions originates. I don't recommend reading about the lambda calculus itself unless you're up for a lot of very heavy theory, but it's worth knowing that, especially in the Lisp world and realms adjacent, you'll often see the term 'lambda' used in a sense which has nothing to do with the AWS product, but rather refers to a form of abstraction that relies on defining functions which retain access to the variable ("lexical") scopes in which they were created, even when called from outside those scopes. Javascript functions have this property, which is why they're capable of expressing the technique 'sillysaurusx describes, and it gives them a lot of other useful capabilities as well.
Another similarity to this use of hashing the scope of a function would be in memoization of a function, to cache the output based on the input, such that you hash a function's inputs and assign to that hash a copy of the output of the function when run with those inputs. Then you can hash the inputs and skip re-running the function. You have to be sure the function has no side-effects nor any changes in behaviour or inputs not specified in the memoization hash, though. "Pure" functions are best for this use case.
On the one hand, as you note, this can't scale horizontally without the load balancer knowing where to route a request based on the fnid, which means my load balancer now has to know things it shouldn't - and that knowledge has to be persisted somewhere, or every session dies with the load balancer.
On the other hand, even if I teach nginx to do that and hang a database or something off it so that it can, with all the headaches that entails - this still can't scale horizontally, because when one of my containers dies for any reason - evicted, reaped, crashed, oomkilled because somebody who doesn't like me figured out how to construct a request that allocates pathologically before I figured out how to prevent it, any number of other causes - every session it had dies with it, because all that state is internal to the runtime instance and can't be offloaded anywhere else.
So now my cattle are pets again, which I don't want, because from a reliability standpoint shooting a sick cow and replacing it with a fresh one turns out to be very much preferable to having to do surgery on a sick or dying pet. Which I will have to do, because, again, all the persisted state is wrapped up tight inside a given pod's JS runtime, so I can't find out anything I didn't know ahead of time to log without figuring out how to attach a debugger and inspect the guts of state. Which, yes, is doable - but it's far from trivial, the way Lisps make it, and if the pod dies before I can find out what's wrong or before I'm done in the debugger, I've got a lot less to autopsy than a conventional approach would give me. And that's no less a problem than the rest of it.
Yes, granted, the sort of software you describe is incredibly elegant, a beautifully faceted gem. It's the sort of thing to which as a child I aspired. But as it turns out, here thirty years on, I'm not a jeweler, and the sort of machine my team and I build has precious little need for that sort of beauty - and less still for the brittleness that comes with it. Durability counts for much more, because if our machines break and stay broken long enough, the cost is measured in thousands or millions of dollars.
That's not hyperbole, either! Early one morning last November, I ran two SQL queries, off the top of my head, in the space of two thirds of a minute. When all was eventually said and done, the real value of each of those forty seconds, in terms of revenue saved, worked out to about $35,000 - about $1.4 million, all told, or seven hundred thousand dollars per line of SQL. And not one of the people who gave us all that money ever even knew anything had been wrong.
Granted that a couple of unprecedented SQL queries like the ones I describe, written on nothing but raw reflex and years of being elbow deep in the grease and guts of that machine and others like it, constitute a large and blunt hammer indeed. But - because we built that machine, as well as we knew how, to be durable and maintainable above all else - in a moment which demanded a hammer and where to swing it, both were instantly to hand. In a system built as you describe, all gleaming impenetrable surfaces between me and the problem that needed solving right then, how could I have hoped to do so well?
Only through genius, I think. And don't get me wrong! Genius is a wonderful thing. I wish I had any of it, but I don't. All I know how to be is an engineer. It's taken me a long time to see the beauty in that, but I think I'm finally getting a handle on it, these days. It's a rougher sort of beauty than that to which I once aspired, that I freely concede, and the art that's in it is very much akin to something my grandfathers, both machinists and one a damned fine engineer in his own right, would have recognized and I hope might have respected, had they lived to see it.
Do you know, one of those grandfathers developed a part that went on to be used in every Space Shuttle orbiter that ever flew? It wasn't a large part or a terribly critical one. You wouldn't think much of it, to look at it. But he was the man who designed it, drew it out, and drew it forth from a sheet metal brake and a Bridgeport mill. He was the man who taught other men how to make more of them. And he was a man who knew how to pick up a hammer and swing it, when the moment called for one. He was possessed of no more genius than am I, and his work had no more place in it for the beauty of perfectly cut gemstones than does mine. But he was a smart man, and a knowledgeable man, and not least he was a dogged man. And because he was all those things, my legacy includes a very small, but very real, part in one of the most tangible expressions of aspiration to greater, grander things that our species has ever yet produced. Sure, the Space Shuttle was in every sense a dog, a hangar queen's hangar queen. But, by God, it flew anyway. It 'slipped the surly bonds of Earth, and touched the face of God' - and next time, we'll do better, however long it takes us. And, thanks to my grandfather's skill and effort, that's part of who and what I am - and there's a part of me in that, as well.
No gemstone that, for sure! It has its own kind of beauty, nonetheless - the kind that leaves me feeling no lack in my paucity of genius, so long as I have an engineer's skill to know when and how to swing a hammer, and an engineer's good sense to leave myself a place to land it. If that was ever in doubt, I think it can only have been so until that morning last November, when I saved ten years' worth of my own pay in the space of forty seconds and two perfect swings of exactly the right hammer.
There's a place for the beauty of gemstones, no doubt - for one thing, in seeing to it this very long comment of mine isn't lost to the vagaries of a closure cache. And I appreciate that, for sure! It'd be a shame to have wasted the effort, to say nothing of any small value that may cling to these words.
But there's a place for the beauty of hammers, too.
It's true that JS systems like Node aren't really designed for this kind of thing, although they could have been. Arc is.
Your exposition took me a trip down memory lane to middle/high school. Thank you for this :)
- References: https://www.thehelper.net/threads/jass-timers-and-how-to-pas...
I completely forgot how terrible of a language JASS actually was. Have mostly fond memories. But oh my is it verbose
I always play to win, so try to understand why & how I failed.
My current theory:
I had good successes doing product development. Shipping software that had to be pretty close to correct.
Today's "product development" is really IT, data processing. Way more forgiving of stuff that's not quite right. Often not even close to right. (Guessing that about 1/3rd of the stuff I supported didn't actually do what the original author thought it did, and no one was the wiser, until something didn't seem quite right.)
One insightful coworker said it best: "I learned to do everything to 80% completion."
My observation is that most team mates created more bugs than they closed. Maybe incentivized by the "agile" methods notions of "velocity". And they were praised for their poor results.
Whereas my tortoise strategies nominally took longer. So I had fewer, larger commits. Way fewer "points" on the kanban board. Created much fewer lines of code.
(When fixing [rewriting] other people's code, mine was often 50% to 80% smaller. Mostly by removing dead code and deduplication.)
I was able to bang out new stuff and beat deadlines when I was working solo.
I think the difference between solo and team play is mostly due to style mismatches. It's very hard for me to collaborate with teammates who are committing smaller, more frequent, often broken, code changes.
Any way. That's my current best guess at what's happening to this graybeard.
More optimistically...
I'm very interested in the "Test Into Prod" strategies advocated by the CTO from Gilt (?). It's the first QA/Test strategy (for an "agile" world") that makes any kind of sense to me. So I think I could adapt to that work style.
(I served as SQA Manager for a while. It's hard to let go of those expectations. It's been maybe 20 years since I've seen anyone doing actual QA/Test. I feel bad for today's business analysts (BAs) who get stuck doing requirements and monkey style button pushing. Like how most orgs functioned in the 80s.)
(I mind me of a time a few years back when I was surprised to learn that the right method of exception handling, for a specific case in some work I was doing on a distributed system, was none - just letting it crash and try again when the orchestrator stood up a fresh container. It felt wrong at first; ever before I'd have instead gone to a lot of painstaking effort to reset the relevant state by hand, and my first instinct was to do the same here. But crashing turned out to be the right thing to do, because it worked just as well and took no time at all to implement.)
I'm totally on board with 80% feature complete, MVP, biz case, etc.
What I'm trying to articulate, here and elsewhere:
implementations that apparently work, but not really
coders who don't check their own work
doing the bare minimum to get awarded the agile velocity victory points
futility of arguing definitions of "done"
lack of feedback loops
that cliche about managing to metrics leads to undesired outcomes
the personal cost, burden of craftsmanship in a "break things and move fast" world
As long as you don't use it for things that you need a lot of, it's a great approach that holds up well. The primary downside is that they all get discarded when we restart the server process. Another downside is that they don't work well with the back button.
Edit: I just remembered another issue with them. Sometimes browsers pre-visit these links, which 'uses' them so that by the time the user goes to click on it, it has already expired. (Yes, this is an issue with using GET for these.)
For solving this, http://arclanguage.com/item?id=20996 has some theoretical ideas.
It's way easier in elisp than in racket, but, the idea is to write out the function + the closure variables to disk.
The hard part is that you'd have to fix up object references. (If two closures both capture x, and x is a hash table, then the values of x for both closures should be the same hash table after a reboot.) But it's doable.
And of course, if it's possible to write the closures to disk, that means you can write them out to a database shared by multiple Arc webservers. As long as the state is also shared (perhaps the values of the variables can also be stored in the database?) then this means the technique can horizontally scale, just like any other.
I spent like a year trying to brainstorm ways of showing that Arc can go toe-to-toe with any of the popular frameworks, with no downsides. "Reboots wipe the closures" implies "Arc can't scale horizontally," which would be a serious limitation in a corporate setting. But in principle I think you could write closures to disk.
That would also result in a funny situation: if closures persist forever, it means that a closure could potentially be activated years after it was first stored. So it'll run with years-old code, rather than the latest version. :) But if people are using global names for functions, then it'll just call the latest versions of those functions, which will probably work fine in most cases.
It's a shame arc didn't have persistent data structures (besides alists :-) and a native hashmap type though.
For those confused, we're talking about this: http://www.paulgraham.com/arc.html
You are in a CONS cell. The there is a CAR to the left, leading off to another CONS, and a CDR to the right, containing NIL. The garbage collector briefly enters the CONS, marks it, quickly glances at the NIL in the CDR, smiles quietly to itself, and looking relieved, hurriedly sweeps away through the CAR.
>GIVE CONS TO CDR
You give the CONS cell to its CDR, creating a circular list.
it handles all your sql and auth cookies? too bad now there's an easy way every script kiddie can now login as admin or guess cookies without the security header du jour.
It's all nice and all when it's being actively updated. But arc, rails, phoenix-ecto, node/react, drupal, spring, etc it all get old pretty soon when the core maintainers loose focus, and then instead of just keeping an eye on the latest best practices and implementing it yourself, you have to dive deep down into years of feature creep and bad coding practices to do the little thing you need to keep things going.
Apache Cocoon?
https://cocoon.apache.org/2.2/core-modules/core/2.2/1373_1_1...
Truth be told, the criticism is a bit unfair (you can solve the problems)
racket's built-in web server does it too.
Including pg’s ViaWeb written in continuation-passing style: https://sep.yimg.com/ty/cdn/paulgraham/bbnexcerpts.txt
Skip here comments regarding AI online courses, questions related to AIMA and PAIP books. It's not quite a good opportunity to inquire about finer points of JScheme or even ask clarifications along last September interview with Lex Fridman. The art of maintaining approachability for beginners and reference level of usefulness for advanced is not easy, but it's demonstrated - and here is flipped on another human side. Peter, thank you for your works for all of us.
> Think in hex, think in hex
> Look around you, who needs dec?
> You can do anything in base sixteen or I'll go to my rest!
https://www.senate.gov/artandhistory/history/minute/Have_you...
"Write in C": http://www.poppyfields.net/filks/00259.html
Someone apparently made a YouTube video too: https://www.youtube.com/watch?v=wJ81MZUlrDo
A wise man.
I mean I suppose some of the stuff I learned from his textbook was pretty useful too.
Shameless plugs in my post history. But to be clear, even a sheet of paper can be tremendously helpful.
As an aside, obesity is a disease that hormonally and mentally encourages self deception. The point of writing everything down and (most importantly) translating this list into objective calorie counts (usually looked up from a third party reference) is to remove this self deception. It is one of the most effective ways to leverage logic and willpower over habits and hormones. There are other ways of course.
Of course I’m welcome to ignore everything that makes me feel bad for gaining weight but it’s shitty to be gaining weight and told it’s my fault for eating too much when I barely eat.
Regarding Obesity, I am not assigning blame or trying to make you feel bad. I’m calling the situation (that I too suffer from) a disease. There are various practices, with varying effectiveness for individuals, to approach the management of this disease. There is no fault in disease, there are only victims of it.
Portion control is one practice, as is writing down consumption. They might not be effective for you. I have been most successful with protein sparing modified fasts such as Lyle McDonald’s rapid fat loss and/or flexible dieting. He takes a very scientific approach to body composition and realistic food intake without shame.
> it doesn’t matter how little they eat they gain weight
A few thoughts in no particular order:
* Weight gain (of the adipose sort) is quite literally your body storing energy.
* Energy can neither be created nor destroyed. [citation needed]
* Unless your gut is performing nuclear physics, your energy intake is directly equivalent to the food you consume.
* Obesity is primarily a hunger problem - you're feeling hungry when you don't require additional calories.
* Some foods (ex broccoli, leafy greens) are nearly physically impossible to consume too many calories from.
* Some foods (ex macadamia nuts) are _incredibly easy_ to consume too many calories from.
Result? Not what any of the “calories in calories out” calculators claimed. About a pound down. Should have been more like seven to ten.
What works for me: weight lifting, swimming. Both wildly more effective than they “should” be. Dieting and aerobic exercise do about dick-all to take fat off my frame. Try various things in various combinations.
The thread was about Lisp, Johnny Cash, and Peter Norvig, the last of whom I was quoting. It seemed perfectly relevant.
His cover of NIИ's Hurt is so powerful. June Carter (his wife) died a few months after filming the video, and that just broke his heart. Johnny followed her less than six months later.
https://www.youtube.com/watch?v=8AHCfZTRGiI
Trent Reznor admitted that the song was no longer his after watching it.
That to be said, recently discovered Ho99o9 and love them.
https://columbophile.com/2018/03/11/episode-review-columbo-s...
https://www.youtube.com/watch?v=vtLYJ4STuXY
He was humping the pretty young girl singer, and murdered the mean old lady bible thumper in an airplane crash, then when Columbo finally (but barely) caught him, he was so remorseful he said he wanted to get caught all along.
this Johnny Cash song
If a pair is consed in a forest, and no one observes it, did it really happen?
https://ambrevar.xyz/emacs-everywhere/
https://ambrevar.xyz/emacs-eshell/IIRC, our fearless leader PG made his zillions using Lisp.
Hard disagree. The Clojure ecosystem is great.
> it's so easy to write a lisp system
Have you tried it, and how far did you get?
Making a Lisp system useful for production is pretty brutal.
13 years into it you will be debugging some eleven-year-old GC or compiler bug.
People think it's easy because they visualize the job as being done when some executable file converts (+ 1 1) into 2.
The Xerox Dandelion and friends was a thing to behold. If you ever got to touch one, you never forgot it.
In my school, implementing a basic Lisp interpreter was part of a required class in the CS curriculum. (If it's not still, everywhere, well, then for shame.)
Yeah, production is something else entirely. By "easy", I mean that dozens if not hundreds of people were tempted to write their own slightly better Lisp. Many of those did reach a production-ish level. But then what? There was no flag to rally around--just lots and lots of niche systems.
I'm not sure. I think if the community had rallied around Common Lisp or Scheme, or maybe just those two, it might have ruled the world. It just didn't happen.
And I'm miserably sad about that. What do we have now? Elisp is great, but I can't build production on emacs. I'll look at Clojure, but I'm dubious. Python is kind of lispy, but has had its own destructive schism. And C++ marches on--somewhere buried in there is a mildly functional lisp, using the worst of all possible syntaxes.
The problems of CL wouldn't be unsurmountable if the community was larger, though. All the important stuff that wasn't standardized gets added by each implementation anyway, and then portability libraries get created that ensure consistent interface. But the state of most libraries is... rough at the edges. I contrast that with Clojure, with which I spent some months over the last two years. The library ecosystem (not Java-side, but Clojure-specific) is great, and a lot of care goes into it. I particularly remember being in awe of just how thorough Liberator is[0].
--
[0] - http://clojure-liberator.github.io/liberator/tutorial/decisi...
Scripting languages on Unix.
I use it for my startup. It's great for web dev. There are some really cool databases written with Clojure also.[2][3]
Some Common Lisp success stories: https://lisp-lang.org/success/
pgloader was rewritten from Python to CL: https://tapoueh.org/blog/2014/05/why-is-pgloader-so-much-fas...
Some companies still pick and use CL: Rigetti Computing (quantum computing), 3E (realtime aggregation and alerting engine of sustainable energy systems), OpusModus, an award-winning music composition software, ScoreCloud, an impressive speach-to-text music notation software, RavenPack (big data analytics provider for financial services), SISCOG (underground systems of many european capitals), Genworks (knowledge-based engineering),…
a community curated list: https://github.com/azzamsa/awesome-lisp-companies
I have also just deployed a website to a client last week: it reads an existing DB and shows products to the user. Simple, effective. I can hot-reload it if I want, it's built-in (I just use the REPL, I can even install new dependencies without a restart).
CL allows cool things like live-extending your browser: https://github.com/atlas-engineer/next
Anyway, caches are only part of the problem with linked lists. The root problem is that they inhibit out of order execution. Work out the data dependencies and scheduling of a simple summation loop for an array compared to a linked list. Assume everything fits in L1. The out-of-order core goes to town with the array code and overlaps the fetches for subsequent iterations of the loop. But the linked list code is serialized with almost no instruction-level parallelism; you can overlap the summation of an element into the accumulator with the start of the deref of the next pointer, but that only saves you one cycle per iteration compared to what an in-order core would do with the same code. Now suppose the data is in L2. In that case the out-of-order core can overlap the loads of the subsequent array elements and the throughput is only diminished by a little if at all compared to the L1 case. The linked list code, on the other hand, works the same as before but because it cannot overlap the fetches for sequential elements due to the dependent loads, you go from say 5 cycles per iteration to 15 cycles per iteration. If you have to go out to L3 or DRAM the chasm dramatically widens even further.
More obviously, linked structures also increase pressure on cache capacity since they have to store their links explicitly. Yet another factor is that modern caches will expend bandwidth on speculative prefetches to reduce latency. This can help for both flat and linked data structures. For example, if you have an AST you should linearly allocate the nodes in the anticipated traversal order to get help from the prefetcher. (And please slim down those fat AST nodes.) If you did that for our linked-list summation example, you'd pay the 15 cycles for the first iteration but then you'd pay 5 cycles for the remaining entries in the same cacheline and also 5 cycles for all remaining entries in other cachelines since the prefetcher will have kicked in. So aside from the startup latency, you're back to running at the same speed as when the list started out in L1. But you're still losing out on the out-of-order execution for the L1 fetches: 4 cycles on a modern core is an opportunity cost of 16 instructions. You're reducing your core to a souped up 486.
By the way, for this particular toy example you should go beast mode with SIMD instructions for the array case which will net you another factor of 4x to 32x depending on the element size and the width of your vector unit and then you parallelize across your cores to get another factor of 4x. While those particulars might not generalize to less simple problems, it illustrates that the major issue with linked structures is that they force serial processing.
Cons lists were slow on the IBM 704 too. Good thing that didn't stop anyone, right?
> Are there any ideas how to adapt Lisp (or LISP) so that it plays well with current CPU architectures?
An ARRAY feature was described in the 1960 Lisp manual. That's probably because it was recognized that linked lists weren't the be-all data structure even on the IBM 704; sometimes it's nice to have compact storage and fast random access.
Can we move past this in 2020?
Let's leave this to the people who have a single aggregate structure in their programming language that is ambiguous between list and array.
The IBM 704 didn't have a cache hierarchy. The problem that the person you're replying to is talking about didn't exist on that architecture.
Accessing any memory location on an IBM 704 took the same time, so it doesn't matter if your values are consecutive in memory as in an array, or somewhere far away as possibly in a linked list.
But on a modern architecture reading a value far away can cause a cache miss.
What do you think the time penalty is for a full cache miss? Something small? Maybe a couple of times slower? No, the difference between a level 1 hit as often in an array, and a cache miss, as often in a linked list, is around two orders of magnitude.
It's literally multiple orders of magnitude worse relatively than it was on the 704.
Ideally modern Lisp implementations would use some kind of variant of the storage strategies pattern, as used for languages like JavaScript, to give the same semantics as a cons cell but actually using a cache-friendly implementation, but I think this is an unsolved research problem.
This is why I've long believed voting systems should restrict the voting age to 16-28. After all, whom would you rather have voting: people wracked with doubt and who fear their own ignorance, or people who know everything?
But in truth, one of my favorite deposition answers goes something like this:
> I'm not prepared to offer an opinion on that question.
But actually, "prepared" is often literally the case.
Before critical depositions, experts spend a day or two, with attorneys and consultants, practicing replies. And experts are very cautious about answering unexpected questions.
Great teachers recognise this and will give you a task that invites you to make the same errors as they did.
This is the basis of guild apprenticeships, PhD supervision, and 20% time for junior developers.
... and I’m happy to have listened and acted on that advice.
Not everyone will listen, but sometimes there’ll be someone that does, or having heard the same advice numerous times from different people it’ll start to sink in at least a little.
Why is that ironic?
Go back to school?
1) he knew he did LISP like languages and wanted to share 2) he didn't know he did LISP like languages and wanted to share 3) he was showing off. 4) the other choices.
I went to 3) based on my 40 years experience in computer science.
or his shirts?
https://commons.wikimedia.org/wiki/File:Peter_Norvig_speakin...
Sounds like someone mentioned how awesome a Lisp is. Ironically he said to someone who has done a bit of Lisp before. There ain't much to the OP story, or at least he hasn't divulged that much, but the song he wrote is pretty cool.
Imagine telling Dave Thomas about a cool language you found called Ruby, not realizing Dave has written a lot of Ruby.
Imagine telling Douglas Crockford about a cool language you found called JavaScript, not realizing Douglas has written a lot of JavaScript (much of it full of bad ideas, but that's irrelevant in this case).
Imagine telling Harold Abelson about a cool language you found called Scheme, not realizing Harold has written a lot of Scheme.
Imagine telling Randal Schwartz about a cool language you found called Perl, not realizing Randal has written a lot of Perl.
Like all of the above, for the respective language (LISP in Peter's case, C in Brian's, and so on), Peter Norvig is a well known master who has written a seminal work about the language.
q.v. Paradigms of AI Programming: Case Studies in Common Lisp
He also wrote Teach Yourself Programming In Ten Years, which many people who know basically nothing about LISPs have encountered and consider important.
If I would have any objection to the brief story's use of the term "ironic", it would be about the fact that many LISPers might not be as enthused about Clojure, so it's possible Peter hasn't really looked into it. Your question implied that Clojure is just "Lisp", though, and if we're talking about "Lisp" in a generic sense (i.e. the LISP family), I think Peter Norvig is one of those luminaries that everyone who pays attention to the social context and most important written works about LISP would know. I don't even pay that much attention to those aspects of LISP knowledge, and I know about him in the context of LISP.
That's not to say everyone who has an interest in LISP should be thought deficient for not knowing about Peter. It's fine if you haven't stumbled across him before. Sometimes, people just miss things that, in retrospect, might seem like something they should have known.
That doesn't mean you have to even have an interest in LISP.
This should, however, hopefully, give you a sense of why Peter might think it was "ironic", even if "ironic" feels a bit questionable as the appropriate choice of term there. I'm sure to him it felt a little ironic, and that makes sense to me as an emotional response, at least.
Does that help?
(Imagine telling William Shakespeare about the Renaissance era techniques of being a playwright, or telling James Cooke Brown about a conlang called Lojban. Of course, I suppose James might be dismissive of Lojban, given he tried to control Loglan by proprietary means after creating it, thus prompting others to reimplement it as Lojban, undermining his efforts at such control.)
edit: Note that I'm not saying there's anything wrong with someone not realizing one is speaking with a Big Name in LISP when meeting Peter Norvig. I'm just saying that Peter is perhaps justified in finding it a little "ironic", and jumping to conclusions about why he would feel that way (if that's what you're doing) might not be fair.
I would probably feel awkward in Peter's position. I've been in a similar position before, including once being told about a cool article that I actually wrote as if it would change my life, and I never know what to do in a case like that. How do you point it out without possibly making someone feel offended? Humans get offended at the silliest things sometimes, and I occasionally find it quite difficult to predict.
... (since, ya know, I rewrote a Lisp book to make it about Python, so if I said what I really think, there would be no end to the crow I'd have to eat), but anyway ...
https://news.ycombinator.com/item?id=1803815
>norvig on Oct 18, 2010 | parent | favorite | on: Ask PG: Lisp vs Python (2010)
>Peter Norvig here. I came to Python not because I thought it was a better/acceptable/pragmatic Lisp, but because it was better pseudocode. Several students claimed that they had a hard time mapping from the pseudocode in my AI textbook to the Lisp code that Russell and I had online. So I looked for the language that was most like our pseudocode, and found that Python was the best match. Then I had to teach myself enough Python to implement the examples from the textbook. I found that Python was very nice for certain types of small problems, and had the libraries I needed to integrate with lots of other stuff, at Google and elsewhere on the net.
>I think Lisp still has an edge for larger projects and for applications where the speed of the compiled code is important. But Python has the edge (with a large number of students) when the main goal is communication, not programming per se.
>In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice.
Kenny Tilton (smuglispweeny) tells this story, that ced posted a link to in the same discussion:
https://news.ycombinator.com/item?id=1803627
>ced on Oct 18, 2010 | parent | favorite | on: Ask PG: Lisp vs Python (2010)
>That reminds me of a cool story, in Norvig's talk about Python...
>When he finished Peter [Norvig] took questions and to my surprise called first on the rumpled old guy who had wandered in just before the talk began and eased himself into a chair just across the aisle from me and a few rows up.
>This guy had wild white hair and a scraggly white beard and looked hopelessly lost as if he had gotten separated from the tour group and wandered in mostly to rest his feet and just a little to see what we were all up to. My first thought was that he would be terribly disappointed by our bizarre topic and my second thought was that he would be about the right age, Stanford is just down the road, I think he is still at Stanford -- could it be?
>"Yes, John?" Peter said.
>I won't pretend to remember Lisp inventor John McCarthy's exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data.
>"No, John, it can't," said Peter and nothing more, graciously assenting to the professor's critique, and McCarthy said no more though Peter waited a moment to see if he would and in the silence a thousand words were said.
http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-wh...