@screwlisp is having some site connectivity problems so asked me to remind everyone that we'll be on the anonradio forum at the top of the hour (a bit less than ten minutes hence) for those who like that kind of thing:
-
@kentpitman @screwlisp @cdegroot @ramin_hal9001
There were other weirdnesses as well.
Even if GC saves you the horror of referencing freed storage, or freeing stuff twice, you still have to worry about memory leaks and moreover, dropping references as fast as you can matters
With copying GC, leaks are useless shit that has to be copied -- yes it eventually ends up in an old generation but until then it's getting copied -- and copying is where generational GC is doing work, and it's stuff unnecessarily surviving to the medium term that hurts you the most (generational GC *relies* on stuff becoming garbage as quickly as possible)
And so, tracking down leaks and finding places to put in weak pointers started mattering more...
4/3
@wrog @screwlisp @cdegroot @ramin_hal9001
Thanks for this detailed reply. Lotta good stuff there. Also thanks especially for indulging the improper fraction. I mostly do not use the fractional labeling for posts for fear of that scenario. Sometimes you promised to stop and then realize you want to keep going and feel impeded. I'm glad you kept on.
-
@wrog @screwlisp @cdegroot @ramin_hal9001
Thanks for this detailed reply. Lotta good stuff there. Also thanks especially for indulging the improper fraction. I mostly do not use the fractional labeling for posts for fear of that scenario. Sometimes you promised to stop and then realize you want to keep going and feel impeded. I'm glad you kept on.
@kentpitman @screwlisp @cdegroot @ramin_hal9001
yeah, usually I start with 1/n and then edit all of the n's later, but today I was lazy
-
@ramin_hal9001 @screwlisp @wrog @dougmerritt @cdegroot
The LispM did a nice thing (at some tremendous cost in hardware, I guess, but useful in the early days) by having various kinds of forwarding pointers for this. At least you knew you were going to incur overhead, though, and pricing it properly at least said there was a premium for not side-effecting and tended to cause people to not do it. And the copying GC could fix the problem eventually, so you didn't pay the price forever, though you did pay for having such specific hardware or for cycles in systems trying to emulate that which couldn't hide the overhead cost. I tend to prefer the pricing model over the prohibition model, but I see both sides of that.
If my memory is correct (so yduJ or wrog please fix me if I goof this): MOO, as a language, is in an interesting space in that actual objects are mutable but list structure is not. This observes that it's very unlikely that you allocated an actual object (what CL would call standard class, but the uses are different in MOO because all of those objects are persistent and less likely to be allocated casually, so less likely to be garbage the GC would want to be involved in anyway).
I always say "good" or "bad" is true in a context. It's not true that side effect is good or bad in the abstract, it's a property of how it engages the ecology of other operations and processes.
And, Ramin, the abolishing of mutable variables has other intangible expressional costs, so it's not a simple no-brainer. But yes, if people are locked into a mindset that says such changes couldn't improve performance, they'd be surprised. Ultimately, I prefer to design languages around how people want to express things, and I like occasionally doing mutation even if it's not common, so I like languages that allow it and don't mind if there's a bit of a penalty for it or if one says "don't do this a lot because it's not aesthetic or not efficient or whatever".
To make a really crude analogy, one has free speech in a society not to say the ordinary things one needs to say. Those things are favored speech regardless because people want a society where they can do ordinary things. Free speech is everything about preserving the right to say things that are not popular. So it is not accidental that there are controversies about it. But it's still nice to have it in those situations where you're outside of norms for reasonable reasons.
@kentpitman
> Ultimately, I prefer to design languages around how people want to express things, and I like occasionally doing mutation even if it's not common, so I like languages that allow it and don't mind if there's a bit of a penalty for it or if one says "don't do this a lot because it's not aesthetic or not efficient or whatever".Me too -- although I remain open to possibilities. Usually such want me to switch paradigms, though, not just add to my toolbox.
-
@dougmerritt @screwlisp @cdegroot @ramin_hal9001
> it seems you are saying that Lisp macros aren't so bad if their use is constrained to safe uses
Well, what I'm saying isn't formal, and that in itself bugs some people. But the usual criticism of the CL system isn't that "people have to be careful", it's that "ordinary use is not safe". But there's safe and then there's safe.
There is a sense in which C is objectively less safe than, say, Python or Lisp. And there is a sense in which people who write languages that aspire to more proofs think those languages still are not safe. So there's a bit of a continuum here that makes terminology tricky, so I have to make some assumptions that are fragile because some after-the-fact dodging can be done where critics do not acknowledge the incremental strengths, they just keep pointing out other problems as if that's what they meant all along.
In scheme, and ignoring that you could do this functionally, writing a macro foo that takes an argument and yields the list of that argument can't look like `(list ,thing) because if used in some some situation like (define (bar list) (foo list)) you would fall victim to namespace clashes. And so scheme people dislike this paradigm. But even without careful planning, the same probably is FAR LESS likely to happen in CL because:
Parameters that might get captured are usually in the variable namespace. You CAN bind functions, but it's rare, and it's super-rare for the names chosen to be things that would be the name of a pre-defined function. you'd have to be in some context where someone had done (flet ((list ...)) ....) for the list function to be bound to something unexpected, and even then you're not intended to bind list to something unexpected for other reasons, mainly that the symbol list is shared.
I allege that in the natural course of things, it's FAR more rare for the expansion of a macro to ever contain something that would get unexpectedly captured, for reasons that do not exist in the scheme world. Formally, yes, there is still a risk, but what makes this such an urgency in the Scheme world are the choices to have a Lisp1 and the choice to have no package system. Each of these things creates an insulation. In practice, the functional part of the CL world does not vary, as uses of FLET are very rare. And it's equally rare for a macro to expand into free references that are not functional references.
Also, the CL world has gensyms easily available, and CL systems often have other mechanisms that package up their use to be easy. In the Scheme world, there is no gensym and the language semantics is not defined on objects but on the notation itself. This makes things hard to compare, but it doesn't make it easy to see how package separation also eliminates a broad class of the surprise, because usually you know what's in your own package and aren't affected by what's in someone else's where in scheme symbols are symbols and it's far more dangerous to just be relying on lexical context to sort everything out.
So yes, CL is less dangerous if you limit yourself, but also it's less dangerous because a lot of times you don't have to think hard about limiting yourself. The languages features it has create naturally-more-safe situations. Note I am making a relative, not an absolute measurement of safety. I'm saying if CL were full of the conflict opportunities that Scheme is, we'd have rushed to use hygiene, too. But mostly it wasn't, so no one felt the urge.
@kentpitman
On the one hand, that is all well said.On the other hand, I always have some nitpicky reply.
(On the gripping hand -- no, I'll stop there)
You're talking about what is common and what is rare, and I can see why such was your overriding concern.
But I feel like I'm always the guy who ends up needing to fix the rare cases that then happen in real life.
For instance, when implementing a language that is wildly different than the implementation language -- "rare" seems to come up a lot there.
And also many times when I am bending heaven and earth to serve my will despite the obstinacy of the existing software infrastructure. "Just don't do that", people say.
It is indeed a lot like the needs of the formal verification by proof community, that is looking for actual math proofs, versus mundane everyday user needs.
Humpty Dumpty said "The question is, which is to be the master -- that's all" ("Through The Looking Glass", by Lewis Carroll).
Here, perhaps the master is which community you aim to serve.
-
@kentpitman
On the one hand, that is all well said.On the other hand, I always have some nitpicky reply.
(On the gripping hand -- no, I'll stop there)
You're talking about what is common and what is rare, and I can see why such was your overriding concern.
But I feel like I'm always the guy who ends up needing to fix the rare cases that then happen in real life.
For instance, when implementing a language that is wildly different than the implementation language -- "rare" seems to come up a lot there.
And also many times when I am bending heaven and earth to serve my will despite the obstinacy of the existing software infrastructure. "Just don't do that", people say.
It is indeed a lot like the needs of the formal verification by proof community, that is looking for actual math proofs, versus mundane everyday user needs.
Humpty Dumpty said "The question is, which is to be the master -- that's all" ("Through The Looking Glass", by Lewis Carroll).
Here, perhaps the master is which community you aim to serve.
@dougmerritt @screwlisp @cdegroot @ramin_hal9001
Well, I'm just trying to explain why hygiene seems more like a crisis to the Scheme community than it did to the CL community, who mostly asked "why is this a big deal?". It is a big deal in Scheme. And it's not because of the mindset, it's because different designs favor different outcomes.
The CL community would have been outraged if we overcomplicated macros, while the Scheme community was grateful for safety they actually perceived a need for, in other words.
So yes, "the master is which community you aim to serve". We agree on that.
-
@kentpitman
> Ultimately, I prefer to design languages around how people want to express things, and I like occasionally doing mutation even if it's not common, so I like languages that allow it and don't mind if there's a bit of a penalty for it or if one says "don't do this a lot because it's not aesthetic or not efficient or whatever".Me too -- although I remain open to possibilities. Usually such want me to switch paradigms, though, not just add to my toolbox.
"the abolishing of mutable variables has other intangible expressional costs, so it's not a simple no-brainer."
@kentpitman@climatejustice.social I prefer the term "constraint" to "expressional cost," because constraints are the difference between a haiku and a long-form essay. For example, I am very curious what the code for the machine learning algorithm that trains an LLM would look like expressed as an APL program. I don't know, but I get the sense it would be a very beautiful two or three lines of code, as opposed to the same algorithm expressed in C++ which would probably be a hundred or a thousand lines of code.
Not that I disagree with you, on the contrary, that is why I was convinced to switch to Scheme as a more expressive language than Haskell. I like the idea of starting with Scheme as the untyped lambda calculus, and then using it to define more rigorous forms of expression, working your way up to languages like ML or Haskell, as macro systems of Scheme.
@dougmerritt@mathstodon.xyz @screwlisp@gamerplus.org @wrog@mastodon.murkworks.net @cdegroot@mstdn.ca
-
"the abolishing of mutable variables has other intangible expressional costs, so it's not a simple no-brainer."
@kentpitman@climatejustice.social I prefer the term "constraint" to "expressional cost," because constraints are the difference between a haiku and a long-form essay. For example, I am very curious what the code for the machine learning algorithm that trains an LLM would look like expressed as an APL program. I don't know, but I get the sense it would be a very beautiful two or three lines of code, as opposed to the same algorithm expressed in C++ which would probably be a hundred or a thousand lines of code.
Not that I disagree with you, on the contrary, that is why I was convinced to switch to Scheme as a more expressive language than Haskell. I like the idea of starting with Scheme as the untyped lambda calculus, and then using it to define more rigorous forms of expression, working your way up to languages like ML or Haskell, as macro systems of Scheme.
@dougmerritt@mathstodon.xyz @screwlisp@gamerplus.org @wrog@mastodon.murkworks.net @cdegroot@mstdn.ca
@ramin_hal9001
Just as a BTW, LLMs have layers of necessary algorithms, rather than just one single algorithm.That said, someone no doubt *has* reduced that core to one line of APL.
P.S. arguments about whether "expressiveness" is the right description may end up being about differences without distinctions.
-
"the abolishing of mutable variables has other intangible expressional costs, so it's not a simple no-brainer."
@kentpitman@climatejustice.social I prefer the term "constraint" to "expressional cost," because constraints are the difference between a haiku and a long-form essay. For example, I am very curious what the code for the machine learning algorithm that trains an LLM would look like expressed as an APL program. I don't know, but I get the sense it would be a very beautiful two or three lines of code, as opposed to the same algorithm expressed in C++ which would probably be a hundred or a thousand lines of code.
Not that I disagree with you, on the contrary, that is why I was convinced to switch to Scheme as a more expressive language than Haskell. I like the idea of starting with Scheme as the untyped lambda calculus, and then using it to define more rigorous forms of expression, working your way up to languages like ML or Haskell, as macro systems of Scheme.
@dougmerritt@mathstodon.xyz @screwlisp@gamerplus.org @wrog@mastodon.murkworks.net @cdegroot@mstdn.ca
I'm not 100% positive I understand your use of constraint here, but I think it is more substantive than that. If you want to use the metaphor you've chosen, a haiku reaches close to theoretical minimum of what can be compressed into a statement, while a long-form essay does not. This metaphor is not perfect, though, and will lead astray if looked at too closely, causing an excess focus on differential size, which is not actually the key issue to me.
I won't do it here, but as I've alluded to more than once I think on the LispyGopher show, I believe that it is possible to rigorously assign cost to the loss of expression between languages.That is, that a transformation of expressional form is not, claims of Turing equivalence notwithstanding, cost-free both in terms of efficiency and in terms of expressional equivalence of the language. It has implications (positive or negative) any time you make such changes.
Put another way, I no longer believe in Turing Equivalence as a practical truth, even if it has theoretical basis.
And I am pretty sure the substantive loss can be expressed rigorously, if someone cared to do it, but because I'm not a formalist, I'm lazy about sketching how to do that in writing, though I think I did so verbally in one of those episodes.
It's in my queue to write about. For now I'll just rest on bold claims.
Hey, it got Fermat quite a ways, right? But also, I had a conversation with ChatGPT recently where I convinced it of my position and it says I should write it up... for whatever that's worth.
-
@dougmerritt @screwlisp @cdegroot @ramin_hal9001
Well, I'm just trying to explain why hygiene seems more like a crisis to the Scheme community than it did to the CL community, who mostly asked "why is this a big deal?". It is a big deal in Scheme. And it's not because of the mindset, it's because different designs favor different outcomes.
The CL community would have been outraged if we overcomplicated macros, while the Scheme community was grateful for safety they actually perceived a need for, in other words.
So yes, "the master is which community you aim to serve". We agree on that.
@kentpitman@climatejustice.social I just want to say, I never had much of an opinion on hygienic macros, other than they seemed like a very good idea. But your explanation of why it isn't a big deal in Common Lisp, because namespaces and libraries prevent nearly all name collisions, was very convincing. And when you consider how complicated the Racket macro expander is, you start to wonder whether it is really worth all of that complexity to ensure a very particular coding problem never happens.
@dougmerritt@mathstodon.xyz @screwlisp@gamerplus.org @cdegroot@mstdn.ca
-
@wrog
> but I can't see how more than 2 would ever be necessary for a copying GCIt's not "necessary", it's "to make GC performance a negligeable percentage of overall CPU".
It was about a theoretical worst case as I recall, certainly not about one particular algorithm.
And IIRC it was actually a factor of 7 -- 5 is merely a good mnemonic which may be close enough. (e.g. perhaps 5-fold keeps overhead down to 10-20% rather than 7's 1%, although I'm making it up to give the flavor -- I haven't read the book for 10-20 years)
But see the book (may as well use the second edition) if and when you care; it's excellent. Mandatory I would say, for anyone who wants to really really understand all aspects of garbage collection, including performance issues.
@dougmerritt @screwlisp @kentpitman @cdegroot @ramin_hal9001
Is this the book you're talking about?
(sorry this was after my time in Scheme Land, hadn't heard of it before) -
@dougmerritt @screwlisp @kentpitman @cdegroot @ramin_hal9001
Is this the book you're talking about?
(sorry this was after my time in Scheme Land, hadn't heard of it before)@wrog
Yes, that's it. (And every time I've checked, it [in 1st & 2nd edition] is the only book ever dedicated to purely Garbage Collection) -
@kentpitman@climatejustice.social I just want to say, I never had much of an opinion on hygienic macros, other than they seemed like a very good idea. But your explanation of why it isn't a big deal in Common Lisp, because namespaces and libraries prevent nearly all name collisions, was very convincing. And when you consider how complicated the Racket macro expander is, you start to wonder whether it is really worth all of that complexity to ensure a very particular coding problem never happens.
@dougmerritt@mathstodon.xyz @screwlisp@gamerplus.org @cdegroot@mstdn.ca
@ramin_hal9001
Well, people used to take advantage of the freedom of the original unhygenic lisp macros to do all manner of unholy coding. -
I'm not 100% positive I understand your use of constraint here, but I think it is more substantive than that. If you want to use the metaphor you've chosen, a haiku reaches close to theoretical minimum of what can be compressed into a statement, while a long-form essay does not. This metaphor is not perfect, though, and will lead astray if looked at too closely, causing an excess focus on differential size, which is not actually the key issue to me.
I won't do it here, but as I've alluded to more than once I think on the LispyGopher show, I believe that it is possible to rigorously assign cost to the loss of expression between languages.That is, that a transformation of expressional form is not, claims of Turing equivalence notwithstanding, cost-free both in terms of efficiency and in terms of expressional equivalence of the language. It has implications (positive or negative) any time you make such changes.
Put another way, I no longer believe in Turing Equivalence as a practical truth, even if it has theoretical basis.
And I am pretty sure the substantive loss can be expressed rigorously, if someone cared to do it, but because I'm not a formalist, I'm lazy about sketching how to do that in writing, though I think I did so verbally in one of those episodes.
It's in my queue to write about. For now I'll just rest on bold claims.
Hey, it got Fermat quite a ways, right? But also, I had a conversation with ChatGPT recently where I convinced it of my position and it says I should write it up... for whatever that's worth.
@kentpitman
> That is, that a transformation of expressional form is not, claims of Turing equivalence notwithstanding, cost-free both in terms of efficiency and in terms of expressional equivalence of the language. It has implications (positive or negative) any time you make such changes.I hope everyone here is already clear that "expressiveness" is something that comes along on *top* of a language's Turing equivalence.
Indeed Turing Machines (and pure typed and untyped lambda calculus and SKI combinatory calculus and so on) are all *dreadful* in terms of expressiveness.
And for that matter, expressiveness can be on top of Turing incomplete languages. Like chess notation; people argue that the algebraic notation is more expressive than the old descriptive notation. (People used to argue in the other direction)
-
@kentpitman
> That is, that a transformation of expressional form is not, claims of Turing equivalence notwithstanding, cost-free both in terms of efficiency and in terms of expressional equivalence of the language. It has implications (positive or negative) any time you make such changes.I hope everyone here is already clear that "expressiveness" is something that comes along on *top* of a language's Turing equivalence.
Indeed Turing Machines (and pure typed and untyped lambda calculus and SKI combinatory calculus and so on) are all *dreadful* in terms of expressiveness.
And for that matter, expressiveness can be on top of Turing incomplete languages. Like chess notation; people argue that the algebraic notation is more expressive than the old descriptive notation. (People used to argue in the other direction)
@dougmerritt@mathstodon.xyz yes, I am maybe a little unclear in what I wrote. I tend to take shortcuts when I write about Scheme that make it seem I am equating it to the untyped lambda calculus.
I have heard of the Turing Tarpit. And I have inspected the intermediate representation of Haskell before (the Haskell Core), so I have seen first-hand that expressing things in lambda calculus makes the code almost impossible to understand.
@kentpitman@climatejustice.social @screwlisp@gamerplus.org @wrog@mastodon.murkworks.net @cdegroot@mstdn.ca
-
@kentpitman
> That is, that a transformation of expressional form is not, claims of Turing equivalence notwithstanding, cost-free both in terms of efficiency and in terms of expressional equivalence of the language. It has implications (positive or negative) any time you make such changes.I hope everyone here is already clear that "expressiveness" is something that comes along on *top* of a language's Turing equivalence.
Indeed Turing Machines (and pure typed and untyped lambda calculus and SKI combinatory calculus and so on) are all *dreadful* in terms of expressiveness.
And for that matter, expressiveness can be on top of Turing incomplete languages. Like chess notation; people argue that the algebraic notation is more expressive than the old descriptive notation. (People used to argue in the other direction)
@dougmerritt @kentpitman @ramin_hal9001 @screwlisp @cdegroot
[..it's possible I'm missing the point, but I'm going to launch anyway...]
I believe trying to define/formalize "expressiveness" is roughly as doomed as trying to define/formalize "intelligence". w.r.t. the latter, there's been nearly a century of bashing on this since Church and Turing and we're still no further along than "we know it when we see it"
(and I STILL think that was Turing's intended point in proposing his Test, i.e., if you can fool a human into thinking it's intelligent, you're done; that this is the only real test we've ever had is a testament to how ill-defined the concept is...)
1/11
-
@dougmerritt @kentpitman @ramin_hal9001 @screwlisp @cdegroot
[..it's possible I'm missing the point, but I'm going to launch anyway...]
I believe trying to define/formalize "expressiveness" is roughly as doomed as trying to define/formalize "intelligence". w.r.t. the latter, there's been nearly a century of bashing on this since Church and Turing and we're still no further along than "we know it when we see it"
(and I STILL think that was Turing's intended point in proposing his Test, i.e., if you can fool a human into thinking it's intelligent, you're done; that this is the only real test we've ever had is a testament to how ill-defined the concept is...)
1/11
@dougmerritt @kentpitman @ramin_hal9001 @screwlisp @cdegroot
The point of Turing equivalence is that even though we have different forms for expressing algorithms and there are apparently vast differences in comprehensibility, they all inter-translate, so any differences in what can utltimately be achieved by the various forms of expression is an illusion. We have, thus far, only one notion of computability.
(which is not to say there can't be others out there, but nobody's found them yet)
2/11
-
@dougmerritt @kentpitman @ramin_hal9001 @screwlisp @cdegroot
The point of Turing equivalence is that even though we have different forms for expressing algorithms and there are apparently vast differences in comprehensibility, they all inter-translate, so any differences in what can utltimately be achieved by the various forms of expression is an illusion. We have, thus far, only one notion of computability.
(which is not to say there can't be others out there, but nobody's found them yet)
2/11
@dougmerritt @kentpitman @ramin_hal9001 @screwlisp @cdegroot
I believe expressiveness is a cognition issue, i.e., having to do with how the human brian works and how we learn. If you train yourself to recognize certain kinds of patterns, then certain kinds of problems become easier to solve.
... and right there I've just summarized every mathematics, science, and programming curriiculum on the planet.What's "easy" depends on the patterns you've learned. The more patterns you know, the more problems you can solve. Every time you can express a set of patterns as sub-patterns of one big super-pattern small enough to keep in your head, that's a win.
I'm not actually sure there's anything more to "intelligence" than this.
3/11
-
@dougmerritt @kentpitman @ramin_hal9001 @screwlisp @cdegroot
The point of Turing equivalence is that even though we have different forms for expressing algorithms and there are apparently vast differences in comprehensibility, they all inter-translate, so any differences in what can utltimately be achieved by the various forms of expression is an illusion. We have, thus far, only one notion of computability.
(which is not to say there can't be others out there, but nobody's found them yet)
2/11
-
@dougmerritt @kentpitman @ramin_hal9001 @screwlisp @cdegroot
I believe expressiveness is a cognition issue, i.e., having to do with how the human brian works and how we learn. If you train yourself to recognize certain kinds of patterns, then certain kinds of problems become easier to solve.
... and right there I've just summarized every mathematics, science, and programming curriiculum on the planet.What's "easy" depends on the patterns you've learned. The more patterns you know, the more problems you can solve. Every time you can express a set of patterns as sub-patterns of one big super-pattern small enough to keep in your head, that's a win.
I'm not actually sure there's anything more to "intelligence" than this.
3/11
@dougmerritt @kentpitman @ramin_hal9001 @screwlisp @cdegroot
I still remember trying to teach my dad about recursion.
He was a research chemist. At some point he needed to do some hairy statistical computations that were a bit too much for the programmable calculators he had in his lab. Warner-Lambert research had just gotten some IBM mainframe -- this was early 1970s, and so he decided to learn FORTRAN -- and he became one of their local power-users.
Roughly in the same time-frame, 11-year-old me found a DEC-10 manual one of my brothers had brought home from college. It did languages.
Part 1 was FORTRAN.
Part 2 was Basic.But it was last section of the book that was the acid trip.
Part 3 was about Algol.
4/11
-
@dougmerritt @kentpitman @ramin_hal9001 @screwlisp @cdegroot
I still remember trying to teach my dad about recursion.
He was a research chemist. At some point he needed to do some hairy statistical computations that were a bit too much for the programmable calculators he had in his lab. Warner-Lambert research had just gotten some IBM mainframe -- this was early 1970s, and so he decided to learn FORTRAN -- and he became one of their local power-users.
Roughly in the same time-frame, 11-year-old me found a DEC-10 manual one of my brothers had brought home from college. It did languages.
Part 1 was FORTRAN.
Part 2 was Basic.But it was last section of the book that was the acid trip.
Part 3 was about Algol.
4/11
@dougmerritt @kentpitman @ramin_hal9001 @screwlisp @cdegroot
This was post-Algol-68, but evidently the DEC folks were not happy with Algol-68 (I found out later *nobody* was happy with Algol-68), so ... various footnotes about where they deviated from the spec; not that I had any reason to care at that point.
I encountered the recursive definition of factorial and I was like,
"That can't possibly work."
(the FORTRAN and Basic manuals were super clear about how each subprogram has its dedicated storage; calling one while it was still active is every bit an error like dividing by zero. You're just doing it wrong...)
5/11
