nil78 has quit [Read error: Connection reset by peer]
nil78 has joined #commonlisp
kevingal has quit [Ping timeout: 265 seconds]
alfiee has joined #commonlisp
alfiee has quit [Ping timeout: 244 seconds]
droideqa has joined #commonlisp
alfiee has joined #commonlisp
<beach>
It is very unfortunate that SBCL is not performing well on generic dispatch. It discourages people from using generic functions.
alfiee has quit [Ping timeout: 252 seconds]
GalaxyNova has quit [Remote host closed the connection]
geminium has joined #commonlisp
geminium has quit [Ping timeout: 244 seconds]
<Pixel_Outlaw>
Heh, I think the biggest threat to Common Lisp is Lisp culture rotting from weaker Lisps being in the limelight. With the crucifixion of Java style OOP there is a movement to simply write code using as few language features as possible. Many people may not even reach for methods to begin with. Especially since they're weaker in Lisps like Clojure.
<beach>
That's the first time I hear about such a movement. Very unfortunate indeed.
alfiee has joined #commonlisp
ski has quit [Ping timeout: 245 seconds]
<Pixel_Outlaw>
Again, just an observation but I think "modern" programmers are trying to learn so much due to the language and framework bonanza that they seek out languages like Go which are simple to begin with. Essentially writing little more than framework glue for work is limiting language learning to languages where the same 10% can be relearned. That's more of the corporate world though. I love that Lisp gives me a good toolbox. I
<Pixel_Outlaw>
can really make my code model the problem.
<beach>
I see.
alfiee has quit [Ping timeout: 252 seconds]
<Pixel_Outlaw>
It's been very depressing for me to hear about how "bad" OOP is when I quite enjoy the CLOS and also methods.
<Pixel_Outlaw>
But Pascal and C++ didn't present quite such a clean model.
<Pixel_Outlaw>
Java too I suppose. That being the big one.
<beach>
Well, the corporate world has always tried to solve their problems with some simple idea like a new tool. They systematically fail to address the real issue which is that they need trained programmers.
<Pixel_Outlaw>
beach, that's an excellent point. There was a time when a company would pay to send their employees off to actually LEARN the language. COBOL isn't ideal but my former company did send programmers off for a week for education.
<aeth>
Pixel_Outlaw: I think the trend seems to be more moving towards certain kinds of type sytems, which don't tend to use inheritance/subtyping at all. Whether these languages are simple or not-so-simple.
<Pixel_Outlaw>
aeth, yes. In things like Rust.
<aeth>
or, as you said, Go
<Pixel_Outlaw>
I just see a lot of fear of "complexity" when really it's expressiveness and options.
edgar-rft_ has joined #commonlisp
<Pixel_Outlaw>
After working in Clojure for a few years I saw it was all arrows and hashmaps. It was a real "Look how they massacred my boy!" Lisp moment.
<Pixel_Outlaw>
To each their own. Just speaking my opinion.
<aeth>
Clojure was the product of its time and those ideas have mostly left the zeitgeist, too
<aeth>
something like Coalton is more in line with the past 10 years worth of trends
<aeth>
But there isn't really a popular/trendy Lisp in this current wave
edgar-rft has quit [Ping timeout: 252 seconds]
Devon has quit [Ping timeout: 260 seconds]
<aeth>
maybe SBCL without generic dispatch :-p
<Pixel_Outlaw>
beach, is it just SBCL in particular?
<beach>
Pixel_Outlaw: No, I don't think so. It has to do with PCL.
<beach>
Portable Common Loops.
* |3b|
wouldn't be surprised if sbcl makes it more obvious though, by being able to optimize other things more
<beach>
Many current Common Lisp implementation add CLOS at the end, on top of a pre-ANSI Common Lisp implementation, and they often use a PCL derivative then.
<Pixel_Outlaw>
Ah, ok. The roots run deep then across implementations.
<beach>
Yes.
<beach>
For one thing, PCL was written at a time when a memory access and a register operation had roughly the same cost, so dispatch is based on in-memory information.
<aeth>
is there a replacement for PCL?
<beach>
Of course. :)
<beach>
I published a paper in 2013 about a better dispatch algorithm, and I believe it is already used in Clasp. SICL uses it too, of course, but SICL doesn't exist (yet).
<Pixel_Outlaw>
|3b|, could be. People I've talked are often shocked at just how fast Lisp is. They've been convinced by Python and Ruby that languages with dynamic types HAVE to be slow.
<Pixel_Outlaw>
Again, popular languages souring opinion. :)
<aeth>
Pixel_Outlaw: There's a sort of Unix/C dogma where there are 'scripting languages' (interpreted, dynamic, slow, with a REPL) and 'compiled/systems languages' (compiled, static, fast, rigid)... and it even winds up in CS textbooks
<beach>
Pixel_Outlaw: Absolutely. It took an entire lecture to convince our students that "interactive" does not imply "interpreted".
<Pixel_Outlaw>
aeth, it is my opinion that we should stop using the term "scripting languages" in general. It holds languages like Python and Ruby to a higher standard of implementation and also doesn't give people an excuse to write sloppily because they're just "scripting".
<aeth>
This does seem to be on the way out. Mainly because of the whole decade or more when people tried to write literally everything in JavaScript
<beach>
aeth: Though, it is probably not enough to replace the dispatch of SBCL. SBCL has so many special cases for object representation (probably again due to the fact that it is basically a pre-ANSI Common Lisp) that more work would be required even in a new dispatch algorithm.
<Pixel_Outlaw>
They call it "bash" because you make your forhead do that to the desk. :D
<aeth>
do people even know what a unick OS is anymore
<Pixel_Outlaw>
beach, per your comment, one of my favorite things to do is DISASSEMBLE on SBCL after evaling a new defun. People are quite surprised.
<Pixel_Outlaw>
I think that the common PC Algol like languages kind of sent us back to the stone age. And we're still inventing new ones sadly.
<Pixel_Outlaw>
I suppose the best you could get at the time of the PC (early on) was Golden Common Lisp or Star Sapphire Common Lisp.
nil78 has quit [Read error: Connection reset by peer]
<aeth>
Pixel_Outlaw: just think about all of the issues that exist just because not everything is an expression in most languages, leading to a lot of otherwise unnecessary mutable variables... perhaps because naive compilers wouldn't be able to handle register allocation as optimally or something
nil78 has joined #commonlisp
nil78 has quit [Read error: Connection reset by peer]
nil78 has joined #commonlisp
<beach>
Pixel_Outlaw: Yes, I see. That's always an amusing thing to do.
alfiee has joined #commonlisp
alfiee has quit [Ping timeout: 268 seconds]
<Pixel_Outlaw>
aeth, yes. I've given that a lot of thought. The various incompatible "parts of a language" seem to have arisen because people were too hasty to not find a unified way of expressing things. Conditionals, stataements, operators, assignment, new syntax for each new feature, ... the list goes on. But in Lisp we have pieces that can be used in any parameter in any expression. (Ok, not /technically/)
<aeth>
better than most languages
<aeth>
even Scheme has two issues here: unspecified evaluation order (rather than left-to-right); and a lot of unspecified return values that are often just something like #<unspecified>
<Pixel_Outlaw>
The worst languages grow poorly because 1 new feature = 1 new piece of arbitrary syntactic noise.
<aeth>
yes. syntax isn't really searchable
<aeth>
and ever syntactic addition makes sense to someone who follows the language and stays active in the language, but adds to the complexity of learning it
<aeth>
s/and ever/and every/
random-jellyfish has quit [Ping timeout: 248 seconds]
<beach>
One thing that has surprised me for a very long time is that Common Lisp systems in some ways behave like implementations of batch languages.
<beach>
A batch language typically has separate compilation, that is, a function is compiled without taking into account what it calls or what calls it, and then it is never altered. This is by necessity because the run-time is so impoverished and can't alter code after the fact.
<beach>
Many Common Lisp implementations behave the same in that they compile a function and then never touch it. But we are lucky in that we always have all code available in the image, so we could modify code according to how it is called and what it calls. We don't do that very much.
<beach>
As I recall, languages like C++ struggle to do "link time" stuff similar to that, but they don't have the compiler available at run time like we do, so anything they do has to be duplicated form the compiler, or separately implemented.
<beach>
Take a function A that calls a function B where B has keyword parameters. Many Common Lisp systems compile B with costly argument-parsing code in it. This argument-parsing code is executed when A calls B, even though in almost all cases, the call site in A where B is called already determines what keyword arguments are supplied and what forms evaluate to those arguments.
mwnaylor has quit [Ping timeout: 248 seconds]
<|3b|>
beach: on the other hand, if you couldn't modify B at any time, the compilers probably would have optimized that call site :)
alfiee has joined #commonlisp
chomwitt1 has joined #commonlisp
alfiee has quit [Ping timeout: 260 seconds]
ixelp has quit [Ping timeout: 252 seconds]
ixelp has joined #commonlisp
chomwitt1 has quit [Ping timeout: 272 seconds]
olnw has joined #commonlisp
<beach>
I don't understand.
<|3b|>
if B can't change, processing keywords at the call site is an easy "static" optimization
<beach>
But B can change.
<beach>
And it is not that easy if the only entry point to B is one that parses keyword arguments.
<|3b|>
right
<beach>
And you can't recompile A because that would not be conforming behavior. And it might be too costly.
decweb has quit [Quit: Konversation terminated!]
* |3b|
was mostly just commenting on how the problem that could be solved by using the runtime compiler was originally caused by the same runtime compiler :)
<|3b|>
more JIT would be nice though (and/or ways to direct the compiler to make specialized variants of things AOT)
<beach>
I am very skeptical when it comes to JIT that is guided by run-time behavior. But I think there is a lot to be done just by taking into account everything that is available, which is literally everything in a Common Lisp system. That everything might change, of course, so code will have to change then.
<beach>
And, again, I am very surprised that so little of this seems to be done in current Common Lisp implementations.
mulk has quit [Remote host closed the connection]
King_julian has joined #commonlisp
<aeth>
I think there is a lot to be gained by using metaprogramming to semantically limit what can be done within a certain form.
<aeth>
Which is sort of what, say, DECLARE-ing a type is doing. At least in a compiler with reasonable semantics. But you can give a lot more information than that.
alfiee has joined #commonlisp
emacsomancer has quit [Remote host closed the connection]
alfiee has quit [Ping timeout: 248 seconds]
wbooze has joined #commonlisp
pve has joined #commonlisp
<Pixel_Outlaw>
Does the Cl standard guarentee some sort of internal navigation of who calls what?
<wbooze>
in what context ?
<Pixel_Outlaw>
In such a way that you could produce something like a "dot" diagram of functions calling other functions. Slime/SLY do something internally to navigate. I assumed they were using the active image to do so.
emacsomancerer has quit [Remote host closed the connection]
alfiee has quit [Ping timeout: 244 seconds]
markb1 has joined #commonlisp
ebrasca has joined #commonlisp
<jackdaniel>
is planet.lisp.org dead?
markb1 has quit [Ping timeout: 244 seconds]
<beach>
jackdaniel: varjag wrote the other day "planet lisp has its cert expired?"
danieli has quit [Read error: Connection reset by peer]
<beach>
But that's all I know.
danieli has joined #commonlisp
emacsomancerer has joined #commonlisp
tuck has joined #commonlisp
markb1 has joined #commonlisp
NotThatRPG has quit [Ping timeout: 248 seconds]
<jackdaniel>
I get host not found today
alfiee has joined #commonlisp
alfiee has quit [Ping timeout: 252 seconds]
wbooze has joined #commonlisp
nil78 has quit [Read error: Connection reset by peer]
geminium has joined #commonlisp
NotThatRPG has joined #commonlisp
markb1 has quit [Ping timeout: 276 seconds]
nil78 has joined #commonlisp
pranav has quit [Remote host closed the connection]
markb1 has joined #commonlisp
nil78 has quit [Read error: Connection reset by peer]
szkl has quit [Quit: Connection closed for inactivity]
ingeniot has quit [Ping timeout: 240 seconds]
tuck has quit [Ping timeout: 260 seconds]
nil78 has joined #commonlisp
alfiee has joined #commonlisp
pranav has joined #commonlisp
markb1 has quit [Ping timeout: 252 seconds]
alfiee has quit [Ping timeout: 252 seconds]
dra has joined #commonlisp
psilord` has joined #commonlisp
markb1 has joined #commonlisp
psilord has quit [Ping timeout: 265 seconds]
triffid has quit [Remote host closed the connection]
geminium_ has joined #commonlisp
bpanthi977 has quit [Ping timeout: 260 seconds]
geminium has quit [Ping timeout: 272 seconds]
triffid has joined #commonlisp
NotThatRPG has quit [Ping timeout: 248 seconds]
King_julian has quit [Ping timeout: 248 seconds]
NotThatRPG has joined #commonlisp
bpanthi977 has joined #commonlisp
varjag has joined #commonlisp
bpanthi977 has quit [Ping timeout: 252 seconds]
markb1 has quit [Ping timeout: 260 seconds]
Guest47_ has joined #commonlisp
markb1 has joined #commonlisp
alfiee has joined #commonlisp
apac has joined #commonlisp
cage has joined #commonlisp
cage has quit [Excess Flood]
alfiee has quit [Ping timeout: 248 seconds]
cage has joined #commonlisp
Lord_of_Life has joined #commonlisp
reb`` has quit [Remote host closed the connection]
skin has joined #commonlisp
reb has joined #commonlisp
nil78 has quit [Read error: Connection reset by peer]
apac has quit [Ping timeout: 244 seconds]
veqq has joined #commonlisp
wbooze has quit [Ping timeout: 265 seconds]
nybble has joined #commonlisp
JuanDaugherty has joined #commonlisp
wbooze has joined #commonlisp
wbooze has quit [Remote host closed the connection]
shka has quit [Remote host closed the connection]
<aeth>
planet lisp still down :-/
nil78 has joined #commonlisp
wbooze has joined #commonlisp
kagevf has quit [Ping timeout: 252 seconds]
kagevf has joined #commonlisp
shka has joined #commonlisp
mustafa has quit [Ping timeout: 265 seconds]
markb1 has quit [Ping timeout: 272 seconds]
cracauer has quit [Ping timeout: 265 seconds]
mustafa has joined #commonlisp
cracauer has joined #commonlisp
alfiee has joined #commonlisp
alfiee has quit [Ping timeout: 245 seconds]
markb1 has joined #commonlisp
<cmack>
the dig dns entry feels ominous. lisp.org.1705INSOAcuritiba.ns.porkbun.com. dns.cloudflare.com. 2365860248 10000 2400 604800 1800
<cmack>
ominous because I thought xach ran his own dns
surabax has joined #commonlisp
JuanDaugherty is now known as ColinRobinson
wbooze has quit [Read error: Connection reset by peer]
bpanthi977 has joined #commonlisp
tuck has joined #commonlisp
alfiee has joined #commonlisp
markb1 has quit [Ping timeout: 245 seconds]
alfiee has quit [Ping timeout: 248 seconds]
bpanthi977 has quit [Remote host closed the connection]
bpanthi977 has joined #commonlisp
surabax_ has joined #commonlisp
markb1 has joined #commonlisp
surabax has quit [Ping timeout: 248 seconds]
kevingal has joined #commonlisp
surabax has joined #commonlisp
surabax_ has quit [Ping timeout: 245 seconds]
<veqq>
Porkbun is really cheap, seductive
markb1 has quit [Ping timeout: 252 seconds]
alfiee has joined #commonlisp
markb1 has joined #commonlisp
alfiee has quit [Ping timeout: 244 seconds]
cage has quit [Quit: rcirc on GNU Emacs 29.4]
nybble has quit [Quit: WeeChat 4.5.1]
khinsen has joined #commonlisp
khinsen has left #commonlisp [#commonlisp]
<jackdaniel>
beach: but fast gf dispatch you've devised is JIT -- it uses the call history (run-time behavior) and computes the dispatch function based on that (
<ixelp>
talks/els2025-sbcl-nx/paper.pdf at master · Shinmera/talks
markb1 has quit [Ping timeout: 244 seconds]
bpanthi977 has quit [Ping timeout: 248 seconds]
psilord` is now known as ppsilord
ppsilord is now known as psilord
tuck has quit [Ping timeout: 252 seconds]
markb1 has joined #commonlisp
jonatack has joined #commonlisp
alfiee has joined #commonlisp
mishoo has quit [Ping timeout: 265 seconds]
alfiee has quit [Ping timeout: 252 seconds]
bpanthi977 has joined #commonlisp
younder has joined #commonlisp
geminium_ has quit [Ping timeout: 260 seconds]
mwnaylor has joined #commonlisp
<veqq>
Pixel_Outlaw: I've been wrestling with OOP recently. I spent ~ 5 years wondering but not investigating why various greats would like CLOS etc. growing up with antiOOP propaganda / being scared of Java in the mid 2000s. I've not yet seen the benefit, honestly
<aeth>
the benefit is polymorphism, but there are other ways to get polymorphism.
<madnificent>
veqq: it's a combination of representing state and adapting algorithms to that state. one of the tools of low coupling and high cohesion, but just another tool.
<ixelp>
When is OOP a More Useful Modelling Approach than Other Paradigms? | Lobsters
<aeth>
the strongest case would be dispatch on 2+ arguments, especially 3+... since on one, a typecase is probably much clearer, although not extensible (not like extensibility is easy without adding a ton of fragility or doing defensive coding around extensibility that might never be used, though)
<veqq>
I finished Keene's OOP in CL yesterday. It's helpful in clarifying the plumbing and giving some "whys" (which e.g. art of the metaobject protocol didnt) but I can't stop my mind from finding more succinct ways to implement everything
<aeth>
although if your typecase on one argument gets large enough, it may start looking like methods are better
<madnificent>
veqq: the value of high cohesion through OOP is better experienced through languages such as Java which force the code to be in a specific location. this helps to locate where a change needs to be made. Common Lisp's implementation is superior imo but it makes the freedom makes the benefits less obvious.
<aeth>
madnificent: but it's an annoying degree of organization... you can have files that are 20 lines long and files that are 5,000 lines long, neither being able to group classes together in the same file nor being able to split large sets of methods up
<madnificent>
i tend to prefer functional code thoug
<aeth>
you can probably work around this with "fake" classes, but now you're not really... doing OOP so much as messing with a weird module system
<madnificent>
aeth: yup. but it does make the intended high coupling more obvious than the freedom you get in Common Lisp where we're free to structure as we see fit.
<aeth>
you're also free to start with functions and only turn to methods when you need them
<madnificent>
aeth: if Java would have had multiple inheritance it would have been less bad
pve has quit [Quit: leaving]
Odin-LAP has joined #commonlisp
<madnificent>
but at least the intent is more obvious in Java than in Common Lisp. the forced structure in Java shows some of the good and some of the bad sides of the paradigm better than Common Lisp.
<aeth>
I'm not sure Java and CLOS are using the same paradigm
<Alfr>
madnificent, most people seem to prefer that over non-functional.
<aeth>
statically typed and dynamically typed languages tend to have very different OOP
<madnificent>
if you structure the Common Lisp program in a one file per class way, you'd be in the same ballpark i guess.
<aeth>
Alfr: the ideal way to program is mostly functional
<Alfr>
aeth, the other functional.
<madnificent>
aeth: Java is a mixed bag IIRC. there are some things at the compiler level but you do get introspection etc if you'd like (though it was advanced when i used it)
<veqq>
When you say "intended high coupling", what do you mean? That the goal's to make a giant arrow of "modify this behavior here!" to protect the rest of the implementation (since no one can keep all code in their head)? Why wouldn't more direct DSLs be better, since they encapsulate even more?
<aeth>
DSLs are the way to go. Create a language in which your problem is trivial
<aeth>
It's... not the fastest route. It's the stereotypical spend years to save a few days
<madnificent>
veqq: i think DSLs are superior. however, if you'd like to understand the appeal of OOP as championed by languages such as Java, then i think that's how you should try to structure the code to see what they're about.
<aeth>
madnificent: again, I don't think Java and CLOS are even in the same paradigm. "Static OOP" and "dynamic OOP" are quite different. And if "OOP" is a "choose m of n characteristics" kind of definition, they do go for very different m_1 and m_2
<aeth>
e.g. dynamically typed languages tend not to even have real encapsulation, except by convention, while Java's style is _all_ about encapsulation and organization
varjag has quit [Read error: Connection reset by peer]
<madnificent>
my personal opinion is that we're looking to build systems which capture and explain the behaviour through the least amount of mental processing.
varjag has joined #commonlisp
<aeth>
I think OOP's (at least) two different paradigms wearing the same name because it was the hype in the 1990s
<veqq>
My backgroun is a DSL cultist. I want to understand the appeal of OOP in Lisp. If Java's restrictions shed more light on why CLOS, great. But hm... I'm against code as flat files, so the organization part is quite difficult
<madnificent>
having a fixed set of guidelines can greatly help in mental processing. if that's not enough abstractions are built. if they are too complex then we build abstractions for the abstractions. Common Lisp gives a crazy amount of freedom there which can't be taken for granted.
<aeth>
Common Lisp is more of a shared notation (complete with very rigid adherence to code formatting style, thankfully) and runtime than anything else.
<aeth>
You have so many ways to solve a problem, you might be the only person writing code like you do.
<aeth>
For instance, some people use some other iteration macro instead of LOOP. Perhaps their own invention.
<veqq>
I recently discovered there are 2 actor models. The popular one (which is the same as lambdas cf. scheme), and a way clearer one. I wonder if there's a relation here
<ixelp>
ACTORS: A Model of Concurrent Computation in Distributed Systems (1985) | Lobsters
<madnificent>
veqq: in the value proposition of OO from CL's perspective, polymorphism is an obvious thing. another angle with CLOS is that it allows to express knowledge. the polymorphic dispatch can reason on the provided structure to select the right code in such case. metaclasses can further work within this same set of abstractions.
markb1 has quit [Ping timeout: 252 seconds]
NotThatRPG has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<veqq>
Tcl seems like a good example, where the "language" is just some parsing rules and everything else is an outside function implemented in e.g. c or composing them. Forth is similar. (Well, I guess most languages are similar, but it's quite direct when the language is only grammar instead of offering a lot of built in implementations etc.)
<madnificent>
aeth: you're arguing CLOS is a known abstraction, like LOOP, and because you may expect people to know the abstraction it can be a good candidate for easy to comprehend code?
NotThatRPG has joined #commonlisp
<veqq>
That's how I understood it. Where CLOS is an existing grammar for you to fit your DSLs in, with clear organization etc.
<aeth>
madnificent: well, it's one of many options people can use
<madnificent>
aeth: agree
<aeth>
I personally don't find CLOS easy to follow, though. Polymorphism in general sort of breaks M-.
<aeth>
you might not know which path is being taken
<TMA>
In my experience OOP (either Java style or CLOS style) sometimes makes easier to think about a particular problem. I cannot pinpoint exactly when it is the case though.
<aeth>
and OOP (CLOS or Java) does tend to add more indirection, too, so you have to M-. more
<aeth>
even though M-. is less useful
<madnificent>
it does provide obvious extension points through subclassing and providing more specific methods
<veqq>
I've been writing a book on software architecture and part of the beginning is that any repeated structures should be abstracted away (via macros) so no architecture should exist, just run a compression algorithm on it. (But it's a moving target and you need to name/label things, so approaching it from that direction.) I don't know if my preconception blinds me but this seems to agree with what you're saying?
<TMA>
I feel that it helps me in a domain where "things" are "active" and "do" some actions on their own or based on some asynchronous input "events" (I use quotes to convey that the labels are very fuzzy)
<aeth>
I don't think extending via OOP (subclassing, defining new methods (including e.g. :after/:around), etc.) is particularly clear as opposed to, say, a DSL, where you have a language you can compose linguistically.
<madnificent>
classes are often a good way to capture business information. once you're in this domain of capturing the information it can be logical to use methods to customize behavior. that's more the case with implementing business logic than other code because deviating behaviour is quite common.
<TMA>
in other domain, that is more of a "data transformation" kind, OOP is way less useful than functional decomposition and recursion
<aeth>
madnificent: I think that's more the nature of business logic being inherently chaotic
<aeth>
you may need to quickly patch something in with a subclass or something
<madnificent>
aeth: yeah, agree. but that may be the better way of handling that part of the chaos.
<aeth>
If you can model your problem, then functional seems to be more elegant. If.
skin has quit [Ping timeout: 244 seconds]
<aeth>
Functional helps if you have an algebra
<madnificent>
i also found CLOS with metaprogramming really nice when building a connection to postgres. though it could all indeed also be handled using a DSL.
<TMA>
if the problem maps to an algebraic structure, functional is the way to go
<TMA>
aeth: you're faster
<aeth>
CL isn't really an FP language... it's more a language for writing FP languages. Imo.
<aeth>
it'll do all of the messy mutation (whether using classes or not when underneath) so your DSL doesn't have to
<madnificent>
there's some other cases which worked well with OO but i also think FP is often the better approach.
skin has joined #commonlisp
alfiee has joined #commonlisp
markb1 has joined #commonlisp
<aeth>
CLOS to me seems like it shines when you don't know what you're doing. And I don't mean that in a bad way. I mean, you can redefine anything at any time, even in a running application.
<madnificent>
you could also redefine functions to get back some of that
<veqq>
TMA: I read some evocative comments about early smalltalkers' programs feeling like the code just writes/runs itself like a bunch of little workers. I've not been able to find them again nor ascertain what they meant
<aeth>
madnificent: somewhat, but the standard defclass instances are going to be the flexible data structures and whether you use defun or defmethod isn't that important for this use case
alfiee has quit [Ping timeout: 265 seconds]
theBlackDragon has quit [Ping timeout: 265 seconds]
theBlackDragon has joined #commonlisp
bpanthi977 has quit [Ping timeout: 252 seconds]
<TMA>
veqq: yes. sometimes it is basically just thinking about the problem and making trivial observations like "I want to record this property of that thing" "in order to do X on A and B, I need to change P of A and Q of be such that CONDITION holds"
<madnificent>
veqq: Pascal Costanza has some interesting work on Context Oriented programming which further builds on these method combinations. these may shed more light on the general way of thinking.
<madnificent>
cool thing about CL is that you can then even use that at compile-time in macros which is interesting in itself
bpanthi977 has joined #commonlisp
markb1 has quit [Ping timeout: 252 seconds]
farter_cat has quit [Read error: Connection reset by peer]
<veqq>
aeth: https://news.ycombinator.com/item?id=380862 "Most OO languages are based on no theory, while every FP language can trace its roots to the lambda calculus." (although not quite true) barks up the same tree
<ixelp>
Most OO languages are based on no theory, while every FP language can trace its ... | Hacker News
<TMA>
some haskellers claim that objects are just comonads
<aeth>
there is definitely an FP version of the AbstractFactory, etc., etc. kind of overarchitecting
josrr has quit [Ping timeout: 276 seconds]
Oladon1 has joined #commonlisp
Oladon has quit [Ping timeout: 248 seconds]
markb1 has joined #commonlisp
emacsomancerer has quit [Quit: IRCNow and Forever!]