iamFIREcracker has quit [Ping timeout: 260 seconds]
<sm2n>
for sure
Lord_of_Life has quit [Read error: Connection reset by peer]
orivej has joined #lisp
Lord_of_Life has joined #lisp
wxie has quit [Ping timeout: 240 seconds]
sjl has quit [Quit: WeeChat 2.2-dev]
Josh_2 has quit [Ping timeout: 256 seconds]
Alfr has joined #lisp
__jrjsmrtn__ has joined #lisp
_jrjsmrtn has quit [Ping timeout: 256 seconds]
gko_ has joined #lisp
iamFIREcracker has joined #lisp
Oladon has quit [Quit: Leaving.]
iamFIREcracker has quit [Ping timeout: 258 seconds]
kaftejiman has quit [Remote host closed the connection]
wxie has joined #lisp
FennecCode has quit [Ping timeout: 272 seconds]
secretmyth has joined #lisp
gaqwas has quit [Ping timeout: 246 seconds]
gaqwas has joined #lisp
FennecCode has joined #lisp
sjl has joined #lisp
wxie has quit [Ping timeout: 256 seconds]
secretmyth has quit [Ping timeout: 260 seconds]
aaaaaa has joined #lisp
Alfr_ has joined #lisp
Alfr has quit [Ping timeout: 240 seconds]
uhren has joined #lisp
<uhren>
ok
<uhren>
Hello?
<Bike>
wassup uhren
<no-defun-allowed>
Hello uhren.
<uhren>
nice to see that this irc is not that dead
contrapunctus has left #lisp ["Disconnected: Replaced by new connection"]
<markasoftware>
is it correct that the Visitor patten from traditional OO programming is unnecessary in Lisp, because it's easy to (defmethod) on an existing class?
contrapunctus has joined #lisp
<Bike>
well, yeah, you can define operations on objects without altering the structure of the objects
<Bike>
i can't say i know the details of the visitor pattern, though
<markasoftware>
the wikipedia page on visitors is quite obtuse but the understanding i'm getting is that java doesn't let you define methods on a class that's already been defined in another file, hence the need
<uhren>
>spend 2 years learning Python, Java>spend 2 years learning Python, Java, JS and such >have almost nothing done > sees superior Lisp > has useless knowledge in these Langs >wants to learn Lisp. I have seen Common Lisp, is it good to begin with? what implementation ( I am on Linux )?
<markasoftware>
(same with c++, etc)
<Bike>
sbcl and ccl for example are solid
<Bike>
markasoftware: with the way virtual dispatch works in C++, the set of virtual functions has to be known at class definition time. java might work the same way
<uhren>
Ok, I am compiling it...ehm...do you have any beginner tips or mistakes I should not dook, it is compiling...ehm..do you have any beginner mistakes or some tips for me ( I want to focus on networking )
<Bike>
hm, i guess don't expect a separate object file? that trips up a lot of newbies. but if you're familiar with python you're presumably used to a repl anyway
<Bike>
try getting a ui like slime that facilitates interactive development
<uhren>
do I need a IDE for it ( like in Java, where it is just a huge pain without IDE ) or can I just use Vim?
<no-defun-allowed>
I had thought the visitor pattern was a kludge for not using multiple dispatch.
<Bike>
sure, you can use vim. look up slimv.
<no-defun-allowed>
SLIME is an extension for Emacs, but there is also SLIMV for Vim.
<Bike>
i haven't used it myself, but people seem to like it.
<moon-child>
uhren: it's difficult to assign lisp many tangible attributes beyond its ability to gather more. Generally, anything you would want to use lisp for, you can make it be usable for.
<bjorkintosh>
uhren, it's a tool. how well you learn it determines how well you can use it.
<uhren>
it seems like the perfect language. Are there like some libs I HAVE to learn in order to write good code or something.
<uhren>
*?
<bjorkintosh>
of course. I'd start with the language though!
<beach>
I think it was drmeister who once said something like [and I paraphrase] "C++ is a DSL that is excellent for deciding exactly where to put each bit of information in memory". Common Lisp is definitely not good for that, but that is also what you absolutely don't want to decide most of the time.
<uhren>
yeah, I am just used to python because pentesting and stuff. So maybe Lisp is a good lang to replace Python with
<bjorkintosh>
why are you replacing python? for the heck of it?
<beach>
uhren: Definitely. It is 50 times faster if you choose a good implementation, and you rarely have to write C code to make it fast.
<uhren>
>why are you replacing python? for the heck of it? tired of seeing and using it tbh
<beach>
uhren: There is no need to quote the question. Just prefix the answer with the nick of the person who asked, followed by a colon. Your IRC client should complete for you.
<uhren>
I have just looked into some documentations and tuts online to start with it. First tarded question: What is teh differnce between (write-line "Hello World") and (format t "Hello World")?
<bjorkintosh>
there is more than one way to do it in lisp.
<uhren>
so what is the better way?
<moon-child>
format gets a format string, like printf in c. So you can say (format t "Hello ~a" "world")
<bjorkintosh>
good question.
<beach>
uhren: WRITE-LINE does one thing. FORMAT is its own language that lets you do lots more things. If all you want to do is to output some text without any formatting directives, either way is fine.
<uhren>
ah ok
<Plazma>
Pentesting is fun..but yea lots of the libs are python sadly
<Plazma>
Haven't seen If there is similar for lisp or stuff for binary analysis
<drmeister>
Hey folks - here's a little demo of displaying 28 molecules all aligned so they are rendered in a similar way in a Jupyterlab notebook. All implemented in Cando (Common Lisp + C++)
<drmeister>
We generate a drawing for one molecule and then generate the other 27 in parallel threads using lparallel promises.
<no-defun-allowed>
moon-child: I don't think it's a curse, admittedly. Being able to piss off and do your own thing is quite an amazing feat in software development.
jesse1010 has quit [Ping timeout: 240 seconds]
<drmeister>
The 27 are drawn so the core of the molecule is aligned in a similar fashion as the first molecule so that a chemist can instantly recognize the common and different features of each molecule.
<no-defun-allowed>
Fancy.
secretmyth has joined #lisp
<drmeister>
I just realized there's an audio track recorded - phew - hardly any cursing. :-)
<beach>
Nice demo!
<drmeister>
Thank you. I made lparallel a standard part of cando - so there are no barriers to using multiple threads.
<uhren>
ehm...I feel a bit tarded again...so sry for that question: is this ccl-init.lisp something like the main in C? Or is it just optional?
<beach>
uhren: It is rare that you need to make an executable for your Common Lisp project.
<Bike>
it is an rc file. it is optional.
<Bike>
it's just a file of stuff that's executed every time you start ccl.
<beach>
uhren: You would work in the REPL of the system for most of the development time.
secretmyth has quit [Ping timeout: 240 seconds]
<uhren>
hmm, so I do not need to compile it?
<uhren>
but how would I do so, if I wanted to?
<beach>
Oh, that's a different question altogether.
<beach>
Most modern Common Lisp implementations compile by default.
<beach>
When you type a (defun ...) it is compiled.
<uhren>
? in Vim?
<beach>
You are confusing on the one hand batch/interactive and on the other hand compiled/interpreted.
<uhren>
ah, ok, so what shall I do when I want to compile it?
<beach>
I am talking about the REPL of your Common Lisp system. You should work interactively with it.
<no-defun-allowed>
Using the REPL (and shortcuts for sending function definitions) will compile functions.
<uhren>
hmm, so I use CL like soem shell?
<beach>
I recommend SLIME with Emacs, but I understand there is something that does part of what SLIME does, but for VIM.
<beach>
uhren: That's what the REPL is, yes.
<no-defun-allowed>
If you evaluate (disassemble (lambda (f) (funcall f 2))), you will see an assembler printout. Although no object file is generated, functions are still compiled.
<beach>
uhren: If you work in Common Lisp the way you work in a batch language, you will lose many of the advantages of Common Lisp.
uhren has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 258 seconds]
AmatureProgramme has quit [Quit: Leaving]
<xristos>
CL is definitely not a good replacement for Python re: pentesting
<xristos>
given the proliferation of Python in that domain
<xristos>
for masochists only!
<no-defun-allowed>
I recall being quite annoyed with the boilerplate:exploit-doing ratio in Metasploit (written in Ruby), so writing a more concise environment wouldn't be entirely for nothing.
<xristos>
metasploit is vast, and having worked on its commercial competitor, i can say that CL is not very suitable
<xristos>
a compact scheme would be a better fit
<xristos>
(which was actually done, look at mosquito lisp / wasp vm)
<no-defun-allowed>
Hm, it doesn't look so bad after reading some sources again.
<no-defun-allowed>
Are we running Lisp code on the target?
<xristos>
with mosquito lisp? yes
<no-defun-allowed>
Yes, that could be tricky with Common Lisp.
<xristos>
well if you had to use CL, you'd use it on the server-end
<xristos>
as a compiler for whatever you end up deploying
<xristos>
but again having done all that, it's not a good fit :)
<xristos>
far better alternatives out there
flazh has quit [Ping timeout: 256 seconds]
<no-defun-allowed>
Right, I haven't really looked at any code-generating stuff; and I wouldn't be able to make any useful commentary on it.
<Plazma>
So for a cl program you essentially load the code in the repl and interact with it?
<no-defun-allowed>
Yes.
<Plazma>
Hmm what about writing a server or something that typically runs as a daemon?
<bjorkintosh>
isn't that a daemon, Plazma?
<bjorkintosh>
a server that runs as a daemon ...
<beach>
Plazma: You can create an executable, but that is typically done once at the end of the project, so you spend most of your time in the REPL. Users of static languages tend to want to create an executable every time they want to test a new features, and that is usually a waste of time.
<xristos>
Plazma: the REPL can be exposed over a TCP socket
<xristos>
so you can have a server and still interact with it over the network
<Plazma>
Ohhh so just during development and such
<White_Flame>
also, the basic IDE (SLIME) is a TCP socket into the running lisp image as well
<White_Flame>
which can remote into already-running lisp programs
<White_Flame>
instead of just launching a new one
_paul0 has joined #lisp
paul0 has quit [Ping timeout: 265 seconds]
<borei>
uhren: im beginner as well. Well would love to spent much more time with lisp, but reality is pushing me not in the way i want. Im still getting lisp ideas and lisp way, it is not like traditional languages like C. For the start i got "Practical Common Lisp" - very useful book covering practical programming in Lisp. It would be extremely good to find task/problem/project you can work on. More you are using Lisp more you are injoing it. T
<borei>
ypes of the tasks you can solve with lisp - endless.
<beach>
borei: I think uhren left.
<borei>
hope that not forever :-)
<beach>
Sure.
gravicappa has joined #lisp
mindCrime_ has quit [Ping timeout: 260 seconds]
mindCrime_ has joined #lisp
Bike has quit [Quit: Lost terminal]
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 246 seconds]
Lord_of_Life_ is now known as Lord_of_Life
Oladon has joined #lisp
narimiran has joined #lisp
johnjay has quit [Ping timeout: 264 seconds]
johnjay has joined #lisp
iAmDecim has joined #lisp
v3ga has joined #lisp
_whitelogger has joined #lisp
iAmDecim has quit [Ping timeout: 264 seconds]
iAmDecim has joined #lisp
borei has quit [Ping timeout: 240 seconds]
lavaflow has quit [Quit: WeeChat 2.9]
iAmDecim has quit [Ping timeout: 240 seconds]
FennecCode has quit [Ping timeout: 244 seconds]
lavaflow has joined #lisp
PuercoPop has joined #lisp
terpri has quit [Ping timeout: 244 seconds]
Volt_ has quit [Quit: ]
Oladon has quit [Quit: Leaving.]
iamFIREcracker has joined #lisp
Necktwi has quit [Ping timeout: 260 seconds]
anewuser has joined #lisp
flazh has joined #lisp
karayan has joined #lisp
kaun_ has joined #lisp
karayan has quit [Remote host closed the connection]
karayan has joined #lisp
lavaflow has quit [Quit: WeeChat 2.9]
rotty has joined #lisp
iAmDecim has joined #lisp
bilegeek has quit [Quit: Leaving]
lavaflow has joined #lisp
iAmDecim has quit [Ping timeout: 264 seconds]
Necktwi has joined #lisp
terpri has joined #lisp
orivej has joined #lisp
jonatack has quit [Ping timeout: 272 seconds]
lavaflow has quit [Quit: WeeChat 2.9]
galex-713 has quit [Ping timeout: 272 seconds]
entel has quit [Ping timeout: 244 seconds]
kilimanjaro has quit [Ping timeout: 244 seconds]
FennecCode has joined #lisp
gendl has quit [Ping timeout: 244 seconds]
Gnuxie[m] has quit [Ping timeout: 240 seconds]
gendl has joined #lisp
pent has quit [Ping timeout: 244 seconds]
karlosz has quit [Quit: karlosz]
kilimanjaro has joined #lisp
tfb has quit [Ping timeout: 244 seconds]
banjiewen has quit [Ping timeout: 244 seconds]
splittist has quit [Ping timeout: 244 seconds]
karlosz has joined #lisp
Gnuxie[m] has joined #lisp
karlosz has quit [Remote host closed the connection]
pent has joined #lisp
yonkunas has quit [Ping timeout: 244 seconds]
wwolf[m] has quit [Ping timeout: 244 seconds]
banjiewen has joined #lisp
even4void[m] has quit [Ping timeout: 244 seconds]
splittist has joined #lisp
yonkunas has joined #lisp
tfb has joined #lisp
Volt_ has joined #lisp
anewuser has quit [Quit: Leaving]
galex-713 has joined #lisp
wwolf[m] has joined #lisp
kelamir[m] has quit [Ping timeout: 240 seconds]
iamFIREcracker has quit [Ping timeout: 240 seconds]
gaqwas[m] has quit [Ping timeout: 240 seconds]
materialfuture[m has quit [Ping timeout: 240 seconds]
Volt_ has quit [Client Quit]
cairn has quit [Ping timeout: 244 seconds]
MrtnDk[m] has quit [Ping timeout: 244 seconds]
dilated_dinosaur has quit [Ping timeout: 244 seconds]
fwoaroof[m] has quit [Ping timeout: 244 seconds]
lavaflow has joined #lisp
entel has joined #lisp
mindCrime_ has quit [Ping timeout: 260 seconds]
dilated_dinosaur has joined #lisp
karayan has quit [Remote host closed the connection]
gaqwas[m] has joined #lisp
karayan has joined #lisp
materialfuture[m has joined #lisp
cairn has joined #lisp
daniel-s has joined #lisp
<daniel-s>
What is the command to lookup a function online, from emacs (slime)?
even4void[m] has joined #lisp
<no-defun-allowed>
C-c C-d h
kelamir[m] has joined #lisp
<phoe>
Plazma: the Lisp process is already enough of a daemon
<phoe>
mine usually runs for weeks until I finally reload emacs or restart the computer
<phoe>
or, in case I screw the image up in development, until I restart the lisp process to get it back to a clean state
MrtnDk[m] has joined #lisp
fwoaroof[m] has joined #lisp
<daniel-s>
no-defun-allowed: Perfect. Thanks
shka_ has joined #lisp
toorevitimirp has joined #lisp
hendursa1 has joined #lisp
hendursaga has quit [Ping timeout: 240 seconds]
jw4 has quit [Read error: Connection reset by peer]
mindCrime_ has joined #lisp
jw4 has joined #lisp
jonatack has joined #lisp
mindCrime_ has quit [Ping timeout: 244 seconds]
pve has joined #lisp
narimiran has quit [Ping timeout: 256 seconds]
space_otter has quit [Remote host closed the connection]
ebrasca has joined #lisp
ebrasca has quit [Remote host closed the connection]
ebrasca has joined #lisp
scymtym has quit [Ping timeout: 256 seconds]
gko_ has quit [Ping timeout: 256 seconds]
kaun_ has quit [Ping timeout: 256 seconds]
iAmDecim has joined #lisp
kelamir[m] has quit [Quit: authenticating]
kelamir[m] has joined #lisp
Bourne has joined #lisp
random-nick has joined #lisp
aeth has quit [Ping timeout: 260 seconds]
aeth has joined #lisp
aartaka has joined #lisp
scymtym has joined #lisp
Bourne has quit [Ping timeout: 260 seconds]
aartaka has quit [Read error: Connection reset by peer]
toorevitimirp has quit [Remote host closed the connection]
MichaelRaskin has quit [Ping timeout: 260 seconds]
MichaelRaskin has joined #lisp
chosenone has quit [Quit: Ping timeout (120 seconds)]
chosenone has joined #lisp
ldbeth has joined #lisp
<ldbeth>
good evening
gko_ has joined #lisp
luckless_ has quit [Remote host closed the connection]
luckless_ has joined #lisp
Alloc has quit [Ping timeout: 256 seconds]
Alloc has joined #lisp
cage_ has joined #lisp
sonologico has joined #lisp
cage_ has quit [Client Quit]
cage_ has joined #lisp
Alloc has quit [Ping timeout: 244 seconds]
Alloc has joined #lisp
ayuce has joined #lisp
orivej has quit [Ping timeout: 240 seconds]
narimiran has joined #lisp
ggole has joined #lisp
brown121407 has joined #lisp
jonatack has quit [Read error: Connection reset by peer]
liberliver has quit [Read error: Connection reset by peer]
liberliver has joined #lisp
aaaaaa has quit [Quit: leaving]
karayan has quit [Remote host closed the connection]
karayan has joined #lisp
bitmapper has quit [Ping timeout: 264 seconds]
ldbeth has quit [Quit: ERC (IRC client for Emacs 26.3)]
Inline has joined #lisp
Inline has quit [Remote host closed the connection]
galex-713 has quit [Ping timeout: 272 seconds]
FennecCode has quit [Ping timeout: 260 seconds]
Josh_2 has joined #lisp
skapata has joined #lisp
cmack has joined #lisp
cmack is now known as Guest48427
skapata has quit [Remote host closed the connection]
Alloc has quit [Ping timeout: 244 seconds]
brown121408 has joined #lisp
FennecCode has joined #lisp
brown121407 has quit [Ping timeout: 244 seconds]
madage has quit [Ping timeout: 240 seconds]
Alloc has joined #lisp
Necktwi has quit [Read error: Connection reset by peer]
cylb has quit [Ping timeout: 240 seconds]
wxie has joined #lisp
daniel-s has quit [Remote host closed the connection]
EvW1 has joined #lisp
madage has joined #lisp
Inline has joined #lisp
Bourne has joined #lisp
<Josh_2>
Afternoon all
Alloc has quit [Ping timeout: 258 seconds]
Alloc has joined #lisp
<beach>
Hello Josh_2.
FennecCode has quit [Ping timeout: 240 seconds]
Bourne has quit [Ping timeout: 244 seconds]
<Plazma>
So are you all also associated with the lispers facebook group
<Josh_2>
Not me
parjanya has quit [Quit: Using Circe, the loveliest of all IRC clients]
parjanya has joined #lisp
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #lisp
<Plazma>
Or any Facebook group rather
<Josh_2>
Not me
Bike has joined #lisp
iAmDecim has quit [Ping timeout: 244 seconds]
parjanya has quit [Remote host closed the connection]
aartaka has joined #lisp
<beach>
Not me.
parjanya has joined #lisp
<phoe>
not me
aartaka has quit [Read error: Connection reset by peer]
<phoe>
I frequent some Lisp-related channels on Freenode, the Lisp Discord server, Reddit, and mailing lists; that's all
<phoe>
but then there's a bunch of various places where lisp programmers hang out in general, here is just one of them
<phoe>
one of the biggest ones nowadays, but still
<Plazma>
i just wasn't sure since it seems to be a closer-knit community than most i've seen
<Plazma>
phoe: also thanks, earlier for some reason i was interpreting that the REPL was the only way to run CL, but it seems the typical development is ust do things in the REPL and test everything out, then eventualy compile it to a binary when it works
aartaka has joined #lisp
<phoe>
Plazma: yes, one usually leaves the Lisp image only for deployment purposes or when one screws the image up beyond repair or when one needs to test loading some code from a fresh image
<beach>
Right, it cuts the duration of the edit/compile/execute cycle to almost zero.
<phoe>
^
<beach>
Especially compared to a static language that has to do a lot of things in include files like C++.
<beach>
Plus, the link cycle can be very long with such a language.
<eta>
fwiw this is like *the* reason I do most new projects in lisp nowadys
<eta>
a*
<phoe>
and livecoding support! mutating the image as the code runs is a nice thing too
<Plazma>
so i know in say python's REPL for instance, if i screw something up in a method, i have to basically type the whole method definition again, and i can't go back up and edit it easily like i could if it was just in a separate file.. is the lisp REPL the same?
<eta>
because I'm a lazyish programmer and having very little barriers to writing code and running it is good
<eta>
Plazma, well usually you write the function in another editor buffer
<Plazma>
ohh
<eta>
and use some key combination to compile it
<beach>
Exactly.
<phoe>
Plazma: "the Lisp REPL" is not a well-defined term
<Plazma>
so you're almost compiling as you go.. so to speak
<phoe>
e.g. in slime, the REPL is just one of the parts of the whole connection
<Plazma>
or in simple terms
<ebrasca>
Hi
<phoe>
another part of the connection is the ability to send file chunks for compilation and side effects
<beach>
It usually starts with an asdf:load-system, but then for minor changes, it's C-c C-c in the editor buffer.
<beach>
Hello ebrasca.
<Plazma>
i feel like smalltalk took alot of inspiration from lisp with the image like design
<phoe>
and that's mostly independent from the REPL, really; if you really want to, you can run slime without the REPL but with the ability to C-c C-c some forms from the editor
<phoe>
smalltalk is image based too! that's the same paradigm
<phoe>
even though CL can be implemented in a non-image-like way, no one really does that nowadays
<beach>
Plazma: Yes, Alan Kay was much inspired by Lisp.
<Plazma>
i love that guy
<Plazma>
and i like smalltalk, it's a shame java beat it out
<Plazma>
though everything as an object is probably the one thing i don't like myself, as i like having some base primitive, but everything else was just spot on
<beach>
He is very smart and very knowledgeable. Unfortunately his talks are very hard to understand. One basically has to know the subject beforehand.
FennecCode has joined #lisp
<aap>
"images based" was quite normal at the time
chewbranca has quit [Ping timeout: 272 seconds]
<Plazma>
still makes a lot of sense even in todays world i think, but the bulk of the world doesn't
<beach>
The main problem i would have with Smalltalk, now that I know CLOS is the single dispatch and the "message passing" paradigm.
<aap>
you'd load machine code into memory, possibly linking it to other code, perhaps modify it with a debugger, and then dump it again
<Plazma>
i always like the message passing idea, you just send a message to some code/method to execute/do what it neds to do
<beach>
Yes, and that is very problematic when you want to select based on more than one object.
<beach>
You have to simulate multiple dispatch, and that gets ugly and slow.
chewbranca has joined #lisp
rvirding has quit [Ping timeout: 272 seconds]
aeth_ has joined #lisp
<beach>
And the distinction between the receiver of the message and the remaining arguments is very asymmetric and ugly as well.
<beach>
It means you can't treat your method as a first-class function for things like mapping.
aeth has quit [Disconnected by services]
<Plazma>
hmm
aeth_ is now known as aeth
yonkunas has quit [Ping timeout: 272 seconds]
rvirding has joined #lisp
<beach>
CLOS makes all that very much more orthogonal. And the result fits much better with the rest of Lisp.
<Plazma>
i'm not sure i follow the orthogonal part in this context
dnm has quit [Ping timeout: 272 seconds]
<Plazma>
as in independant?
<beach>
CLOS does not use message passing. It uses generic functions. And a generic function is just like any other function.
dnm has joined #lisp
yonkunas has joined #lisp
<beach>
An method in a "traditional" object-oriented language is not a function. It doesn't exist without the message receiver.
<beach>
So there is typically no notation to map a method over a sequence of objects.
kilimanjaro has quit [Ping timeout: 272 seconds]
<Plazma>
hmm..
OptimusMKD has joined #lisp
drmeister has quit [Ping timeout: 272 seconds]
<Plazma>
beach: as in a method being utilized (the same method) for multiple objects?
Oladon has joined #lisp
orivej has joined #lisp
wxie has quit [Ping timeout: 256 seconds]
drmeister has joined #lisp
<beach>
That's what mapping is, yes. You apply the same function to every objects in a sequence.
aartaka has quit [Read error: Connection reset by peer]
kilimanjaro has joined #lisp
yitzi has joined #lisp
<beach>
For instance, you can say (mapcar #'1+ '(1 2 3 4 5)) in Common Lisp.
<beach>
But if you have message passing, you can't do (mapcar #'method '(object1 object2 ...)).
<Plazma>
because you have to send multiple messages.. right?
<beach>
So you need to do something like (mapcar (lambda (object) object.method()) '(object1 object2...)) unless, of course they invented a special notation for that.
<beach>
In CLOS, it is just an ordinary function application. No special treatment for the message receiver. It is handled just like any other argument.
<Plazma>
huh , i see where that's useful
<beach>
So object.method becomes (method object) in Common Lisp.
<Plazma>
and i kinda think i like that generic treatment of things, in theory
X-Scale` has joined #lisp
<Josh_2>
generic functions are very cool
<Josh_2>
so cool they wear sunglasses and have a leather jacket
<Plazma>
i need to get a pair of those for my cat
X-Scale has quit [Ping timeout: 260 seconds]
<beach>
Plazma: Consider the (artificial) example of displaying figures on windows. In a message-passing system, you have to decide whether to make the display method part of the figure class or the window class.
X-Scale` is now known as X-Scale
<beach>
Plazma: And that decision has to be made early, which is typically too early.
<beach>
And you have to decide whether to write window.display(object) or object.display(window).
<beach>
In Common Lisp, you just say (display object window), or whatever order you prefer. It makes no difference.
<beach>
And methods of the generic function can specialize on both parameters, as in (defmethod display ((object triangle) (window x11-window)) ...)
<Plazma>
hm
<Plazma>
interesting
<beach>
Interesting, sure, but also invaluable and unique.
<Plazma>
yea i'm trying to process it to be honest
<beach>
I am betting that, when you learn more about CLOS, that your appreciation for message passing will vanish.
<beach>
And multiple dispatch is but one feature of CLOS. Auxiliary methods make some of the traditional design patterns disappear as well.
jonatack has joined #lisp
<beach>
Method combinations come in very handy too.
<Plazma>
probably, if i can keep up and actually start using it more, and try to balance being stuck in academic/python land
<beach>
None of that stuff exists in traditional object-oriented languages.
<beach>
Why would academia make you stuck with Python. I thought academia was one place where you are free to explore and choose your tools.
<beach>
No?
<Plazma>
well that's what a lot of the scientific libraries are in
<Plazma>
for machine learning, quantum computing, etc
<beach>
I am sorry to hear that.
<Plazma>
i mean you don't HAVE to, but yea.. and it's a mess
yitzi has quit [Read error: Connection reset by peer]
<beach>
Are you sure about those libraries? I mean, I would think those domains would need performance, and there is no way Python can provide that. So I am guessing they are really written in C. And if so, it would be even better to use them from Common Lisp, via CFFI or something like that.
jonatack has quit [Ping timeout: 244 seconds]
Bourne has joined #lisp
<Plazma>
beach: so it's more the API's themelves than anything, the libraries they reference are often originally in fortran or C, but there is something called CPython that it essenitally uses for the performance bits
jesse1010 has joined #lisp
<Plazma>
i mean it's still slow as balls since a lot fo QC/ML is matrix math and mainpulations
<Plazma>
and factoring
<beach>
I am frankly amazed that academics would choose such a strategy.
<Plazma>
they're lazy
jonatack has joined #lisp
<Plazma>
i wish i was kidding honestly
<beach>
Maybe scientists, like chemists, and physicists, but those domains are computing domains.
<aeth>
They're too busy doing research/teaching to write wrappers in languages that aren't Python.
<Plazma>
well alot of the need comes from chemists , physicists and such making/contributing to them, and then CS folks enhance them and go with it
<Plazma>
and they dont' want to be arsed with doing things in a better language overall
<Plazma>
python is easy and simple
<Plazma>
also aeth hit the nail on the head too, sadly
<beach>
Well, CS used to be viewed as a "service discipline" for the sciences, but I thought that ended some 2 decades ago.
<Plazma>
or another library that's 'better'
<Plazma>
beach: still is in some ways but it's got it's own street cred in the sciences too
<Plazma>
symbiotic relationships really
<beach>
Oh, well. I am glad I can choose my tools.
<Plazma>
maths and physicists think they're good programmers and it shows :D
<Plazma>
chemists too
<Plazma>
but hey it works for everyone, somehow so
<beach>
Sort of. But it's a huge waste of money, effort, and brain power.
<beach>
Anyway, we are drifting off topic. So to summarize, CLOS is WAY better than traditional object-oriented languages.
<Plazma>
fair enough :D
jcowan has joined #lisp
yitzi has joined #lisp
<jcowan>
Do people still use struct types with defined representations? I see the logic of the unnamed variety: someone passes you a list or vector (perhaps from an FFI) where each element has a distinct meaning, and by imposing a struct convention on it so that it's easier to work with.
<jcowan>
But the named variety is more mysterious. Why would you use those rather than ordinary structs? It's unlikely that some external system will conveniently plant a symbol, or whatever, in element 0.
<aeth>
beach: I disagree a bit. I see foo(bar, x) and bar.foo(x) as essentially equivalent. So (foo bar x) and (dot bar foo x) or something like that. I mean, it's not quite the same because it's often more like (send-message bar 'foo x) or something... but OOP in a cross-language sense is pretty loosely defined in general.
<jcowan>
OOP is a ridiculously flexible term. For each writer on the subject, OOP is either defined as good (in which case we want our system to be OOP) or as bad (in which case we our system not to be OOP but something else much better).
<aeth>
It's just that bar.foo(x) can make sense over foo(bar, x) if you only have single dispatch and you're an infix language, although if it's not just syntactic sugar for foo(bar, x) then you still can't use it in a map().
<Plazma>
could be like golang and reverse everything and don't use objects but structs
<Plazma>
:P
<jcowan>
Note that Lua doesn't care which syntax you use
<jcowan>
s/we our/we want our
Bourne has quit [Ping timeout: 265 seconds]
EvW1 has quit [Ping timeout: 240 seconds]
iAmDecim has joined #lisp
Alloc has quit [Ping timeout: 240 seconds]
iAmDecim has quit [Ping timeout: 256 seconds]
<beach>
aeth: You are, of course, entitled to your opinion.
<jcowan>
aeth: Perhaps one should allow it to be written as "foo .bar x", without the parens.
CrazyPython has joined #lisp
<beach>
Plazma: The thing with Common Lisp is that it does not have this silly idea that traditional object-oriented languages have, namely that classes are both for data representation and for encapsulation. In Common Lisp, those aspects are handled by two different features. Classes are for data representation, and packages are for encapsulation.
<beach>
So in Common Lisp, saying that something is an "object" does not restrict what it is very much. An integer is an object just like a stream or a symbol. And you can write methods that specialize to integers, like (defmethod add3 ((x integer)) (+ x 3))
<beach>
This is the sane way of doing object-oriented programming.
<beach>
No doubt aeth will disagree, but again, aeth is entitled to disagree.
<Plazma>
oh hmm
<Plazma>
that's interesting
<beach>
Plazma: And every Common Lisp object has a unique class. (CLASS-OF X) will return a class object for any X.
<phoe>
I thought he's disagreeing about a different point though
<jcowan>
I agree as far as classes go, but packages are very weak encapsulations indeed. Closures, on the other hand, are good encapsulations, just hard to use as things stand.
<jcowan>
s/go//
<beach>
jcowan: I don't believe in preventing programmers from doing things.
<phoe>
I understood that his point is that single dispatch OO/message passing is a natural subset of multiple dispatch OO
<phoe>
and that foo.bar(baz) is therefore equivalent to (bar foo baz) with specialization on FOO
<jcowan>
A subset, certainly: {3, 1, 4, 5, 9} is a subset of the integers, but who cares?
<beach>
jcowan: It makes it nearly impossible to write programming tools like debuggers.
<phoe>
whereas (bar foo baz) with specializations on both FOO and BAZ has no direct equivalence in single-dispatch OO without a dispatcher/strategy design pattern
<jcowan>
That is because, for better and worse, we have no way of breaking the encapsulation of closures when we need to.
<phoe>
and that gets ugly immediately
<jcowan>
Yes. Been there, done that, trying to add new numeric types to Smalltalk.
<phoe>
yes, exactly
<beach>
jcowan: And if we could, their strength would be similar to that of Common Lisp packages, and the use of closures as objects would just be more cumbersome.
<aeth>
phoe: Exactly that, with the added point that . notation only really seems desirable at all if the language is infix in the first place.
<aeth>
since it infixifies a method function
<phoe>
so, "who cares"
<aeth>
(or at least, something that could be done this way, if it was a well-designed single-dispatch system)
<phoe>
jcowan: I think that tons of people who do single-dispatch languages are forced to care whenever they write them
<phoe>
I'm glad that I don't need to care about that in Lisp
<beach>
A "well-designed single-dispatch system" has got to be a contradiction.
<jcowan>
Having procedures like closure-alist and its converse are hardly comparable to adding a single extra colon.
<aeth>
beach: well, in the sense that it wouldn't remain like that for long because a well-designed single-dispatch system should be fairly easily extensible to a multiple-dispatch one
<jcowan>
At least one system (forgive me for forgetting its name) has in its evolution backed off from multiple dispatch to single-specified-argument dispatch, finding that it's more efficient and handled almost all their existing code.
<jcowan>
So people were writing MD code but not actually exploiting it that much.
<beach>
That must be because the didn't know how to do multiple dispatch efficiently.
<beach>
Probably it was in the days when table-driven techniques were the norm.
<aeth>
jcowan: MD does seem fairly rare in practice, but I don't see how the presence of MD would significantly slow down the SD common path.
<beach>
aeth: That's a very valid point. I see absolutely no reason for that.
<jcowan>
(If I wasn't clear, the idea is that you get to say for each generic function which argument it will be dispatched on.)
<beach>
Especially since one way of doing multiple dispatch is to cascade single dispatch.
<beach>
jcowan: How is that better than being able to choose any SUBSET of the arguments, in ANY ORDER?
<jcowan>
That is precisely the dispatcher pattern that phoe mentioned above.
<aeth>
beach: which is exactly the kind of approach I'd intuitively look into first if I had to implement it
<jcowan>
aeth: So did I.
<phoe>
jcowan: the difference is that it's implicit
<phoe>
the programming system dispatches for you
<beach>
But it's also a silly way of doing it.
<phoe>
instead of you explicitly needing to write, code, and use the dispatcher
<jcowan>
Absolutely. But macros.
<beach>
I am betting there are also limitations to doing it one argument at a time.
* jcowan
scratches his head
<phoe>
multiple dispatch and single dispatch are equivalent from the mathematical point of view since you can implement one in terms of the other and then (meta)circularly
<jcowan>
Well of course there are, compared to MD.
<phoe>
the question is which one has the best tradeoffs for the given problem at hand.
<jcowan>
Oh, wait, you mean efficiency limitations, beach?
<beach>
No.
<beach>
Like if you have a method ((x class) y) and another (x (y class))
<jcowan>
Can you explain further?
<beach>
But yeah, I am betting you can do better (performance wise) if you have all the information available to the dispatcher for all the parameters.
<beach>
I may be wrong, but how would this situation be handled by cascading single dispatch?
<jcowan>
Surely. In a whole-program compiler where you have all the information about all the calls as well, you can probably do even better.
<beach>
We do, though.
<jcowan>
(with thoroughgoing type inference, I mean)
<beach>
It is just that we collect that information as we go.
rpg has joined #lisp
<beach>
It has the additional advantage that a call that is never actually executed does not influence the result.
<jcowan>
Something like "assign a small integer to all types in the system, then represent the call possibilities as a bitmap", for instance.
<jcowan>
True. But I still don't understand the force of your ((x class) y) example.
<beach>
Like I said, I may be wrong, but I don't see how to simulate it with cascading single dispatch.
<beach>
Maybe someone can help me.
<jcowan>
Why is it any different from ((x some-type) y)?
<beach>
It isn't. Just that there are two methods, and one specializes only on the first argument and the other one only on the second.
<jcowan>
OIC. Which reminds me that another thing I dislike about CL's MD (and MI) is that they arbitrarily resolve ambiguities instead of signaling an error about them.
<beach>
Of course.
<jcowan>
Self is good on both points.
<beach>
I mean, "of course you would dislike that". But I much prefer consistent behavior.
<jcowan>
What's inconsistent about treating ambiguity as an error?
<beach>
You have a point. "consistent" was the wrong term.
<beach>
I don't have a good name for the behavior I prefer.
karayan has quit [Remote host closed the connection]
<Alfr_>
beach, I think we have the same problem in CL. But a default resolution strategy is defined, something about ordering applicable methods.
<jcowan>
How about "artificial"? :-)
karayan has joined #lisp
<aeth>
perhaps "implicit" behavior?
<ggole>
Isn't that class example much like pattern matching? eg, match (a, b) with (C, _) -> 1 | (_, C) -> 2? There are well-known techniques for translating this to single-branching decision trees (or similar constructs)
<Alfr_>
beach, and then there also is :argument-precedence-order to make unintuitive cases.
<beach>
Alfr_: Yes, but could that situation be handled by cascading single dispatch?
<ggole>
Although with pattern matching you get all the rows up front, which surely helps
<aeth>
ggole: class dispatch sounds a lot like pattern matching to me... a lot of the time, at least ime, the design choice is between typecase or defmethod (where defmethod increasingly wins out the more dispatches you need to do, like e.g. dispatching two sides (human, remote human, AI) in a chess game)
<phoe>
a bit more contrived, since then you'd need to search for the methods some more
<beach>
phoe: That doesn't look like cascading single dispatch though.
<phoe>
wait a second
<beach>
It looks like both arguments are involved in both branches of the outermost IF.
<phoe>
oh, yes, I see what you mean
<phoe>
yep, this requires a dispatcher pattern
<phoe>
(dispatch dispatcher foo bar) where DISPATCHER is specialized on
<jcowan>
Reading C3/Dylan articles about the hard-to-predict behavior of CL class flattening shows how anti-lawful it is. ("C3" means you get a consistent global graph that preserves local order and is monotonic.)
<phoe>
and then this code is the body of its DISPATCH method
<jcowan>
Concisely put: "The C3 superclass linearization of a class is the sum of the class plus a unique merge of the linearizations of its parents and a list of the parents itself. The list of parents as the last argument to the merge process preserves the local precedence order of direct parent classes."
<shka_>
yeah, C3 is accepted to solve some kind of problem
<shka_>
... that i never encountered
<jcowan>
We all hope we never do.
<Alfr_>
beach, the default left-to-right one, I think you then could simply dispatches on the first match, in your example ((x some-type) y). And for (x (y class)), wouldn't (x t) simply only have to dispatch further on y's type?
VincentVega has joined #lisp
<Alfr_>
beach, not entirely sure, just woke up. :D And I didn't say it'd be pretty.
<phoe>
Alfr_: an alternative form of this question is how to express it in the Java-like dot method call notation
<beach>
You may be right. I just have this hunch that cascading single dispatch can't do everything that multiple dispatch can. Maybe some day I'll dig into it and write a paper about what I find.
<phoe>
IMO in this case, it would be dispatcher.dispatch(foo, bar)
<beach>
Certainly, I can imagine performance issues, where it would be a better idea to go back and forth between arguments to determine an effective method to call.
<shka_>
phoe: more like findEffectiveMethod(methodName, foo, bar).execute(foo)
<shka_>
or something
<phoe>
sure, if findEffectiveMethod is a static function of some sort
<Alfr_>
jcowan, it it's that paper I think I've read, then they also noted that in most of their test cases C3 didn't produce a different ordering than CLOS.
<beach>
Sorry, "effective-method FUNCTION" to call. An effective method can't be called.
<phoe>
but then you need a way to extend findEffectiveMethod in some way
<jcowan>
Yes, indeed, as shka_ said. You hope this (arguable) bug in CL never bites you.
<shka_>
as for what multiple dispatch can do and cascading dispatch can't
<phoe>
e.g. Java won't let you do that in a nice and pleasant manner.
<shka_>
in theory i think that cascading dispatch can do everything, it is just in practice it is awkward
<phoe>
in theory sure, they're equivalent
<shka_>
the visitor pattern in particular is designed to go around single dispatch
<shka_>
and oh boy, it is as awkward as it gets
Lycurgus has joined #lisp
<shka_>
and again, you often can avoid using it, but sometimes at the performance hit
<Alfr_>
phoe, if you'd ask me to do it, I'd probably just somehow slap the clos behaviour onto it maybe using C3 for ordering; and define it as what you get in that case. lol
<shka_>
for instance, at work we had a basic CL:MAP like function
<shka_>
it worked by taking iterator
<phoe>
Alfr_: at which point you no longer have a single dispatch system :D
<shka_>
and then moving that iterator forward
<shka_>
each move forward was a method call
<shka_>
after switching to the visitor it became possible to remove iterator and operate directly on the data structure, therefore removing virtual method call penalty
<shka_>
it really made a difference in this case
<Alfr_>
phoe, I was more thinking about how to emulate, if you'd like, it given single dispatch. And currently that'd require a ton of boilerplate in java I guess.
<shka_>
Alfr_: the visitor pattern is how you do it
<shka_>
maybe java has some reflection stuff that can help you
<shka_>
or you can use Clojure
<shka_>
oh, visitor is also typically slower then a direct multiple dispatch
karayan has quit [Remote host closed the connection]
<Alfr_>
shka_, thanks, heared of it. But I honestly don't know what that is right now.
Oladon has quit [Quit: Leaving.]
karayan has joined #lisp
<shka_>
you can google it
<shka_>
heh, it is a beach-like thing to say
<shka_>
but consider programming in the CL instead
<shka_>
;-)
<Alfr_>
shka_, yeah already put it on my bucket list.
jonatack has quit [Ping timeout: 244 seconds]
<Alfr_>
shka_, some time soon™.
<shka_>
hopefully!
<shka_>
ok, got to go, take care
bitmapper has joined #lisp
VincentVega has quit [Ping timeout: 245 seconds]
drl has joined #lisp
<jcowan>
any feedback on my question about list-structs and vector-structs?
johnjay has quit [Ping timeout: 240 seconds]
<Bike>
what question was that? i'm missing it in the logs
<Bike>
oh, way up there, i see
<Bike>
i'd say it's rare to use structs at all and even rarer to use the typed kind
iamFIREcracker has joined #lisp
<Bike>
i always assumed the feature was a holdover from the old world
<jcowan>
Probably true. But getting (typed) vectors of this kind from the FFI, where the vector is really a struct on the other side, can't be rare, and copying them into standard structs/classes seems a bit useless.
<Bike>
why would copying it into a standard structure of class be more useless than copying it into a vector?
<Bike>
or class*
jmarciano has joined #lisp
iamFIREcracker has quit [Ping timeout: 260 seconds]
<jcowan>
I'm assuming your FFI puts it into a vector already, because it doesn't know what class it is. Your code does, and this allows it to be used as a struct without copying it again. If my assumption is bad, let me know.
<jcowan>
s/class it is/& on the C side/
<Bike>
i believe how it works in cffi is that by default it returns a plist, but you can specialize some generic functions to get whatever object you like
<Bike>
and that function deals with the foreign memory directly, so there's no double copy
aartaka has joined #lisp
<jcowan>
I'll read that in detail, but I don't understand how it can deal with the foreign memory directly *and* return a plist, as the foreign memory is going to use full-word (or the like) representations.
drl has quit [Quit: Ex-Chat]
<Bike>
as far as i know it's some arbitrary c object, so it could have slots with a different layout than a series of words
jmarciano has left #lisp ["ERC (IRC client for Emacs 28.0.50)"]
<Bike>
you have to teach cffi how the c memory is laid out using defcstruct
<Bike>
then it knows the offsets and sizes and all
Christ0pher has joined #lisp
aeth has quit [Ping timeout: 256 seconds]
aeth has joined #lisp
<jcowan>
Ah, that's reasonable. I have a design like that for Scheme, where you write a nested-list schema that describes the struct/union and all its parts, including other structs/unions. There are two interfaces, a macro one where the schema is constant (and can be compiled) and a procedural one where it is an object.
<Bike>
an ffi where you can only deal with word sequences seems pretty limiting. i mean, wouldn't you need to write bridge code in C for any C system with any objects that don't fit that mold?
<jcowan>
Not sure I understand which idea you're talking about.
<Bike>
i don't understand "as the foreign memory is going to use full-word representations". i mean, in general it's not, right?
<jcowan>
In general, no. I was thinking about the case when it is.
<jcowan>
And by full-word I meant as opposed to fixnum or bignum representations.
<jcowan>
Chicken Scheme's FFI special-cases bignums with two bigits: any more than two on the Lisp->C and it raises an error, on the C->Lisp side it is prepared to create either depending on the value.
<jcowan>
either a fixnum or a 2-bigit bignum
gko_ has quit [Ping timeout: 260 seconds]
jonatack has joined #lisp
iAmDecim has joined #lisp
brown121408 has quit [Read error: Connection reset by peer]
brown121407 has joined #lisp
iAmDecim has quit [Ping timeout: 244 seconds]
EvW has joined #lisp
aartaka has quit [Read error: Connection reset by peer]
iamFIREcracker has joined #lisp
brown121407 has quit [Remote host closed the connection]
Oladon has joined #lisp
<Plazma>
So code signing is a separate process after compilation yes?
bhartrihari has quit [Ping timeout: 246 seconds]
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<phoe>
signing? you mean like when Apple complains that your application isn't notarized or something?
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life_ is now known as Lord_of_Life
iAmDecim has joined #lisp
Lycurgus has quit [Quit: Exeunt]
<Plazma>
Phoe that yea basically
<Plazma>
But it's also a security feature to sign binaries I'm general for authenticity even on the desktop
iAmDecim has quit [Ping timeout: 265 seconds]
<phoe>
you usually want to do that after dumping the image, yes
<phoe>
md5sum and gpg are the way to go
<Plazma>
Yea ok cool
kaftejiman has joined #lisp
ayuce has quit [Remote host closed the connection]
<jackdaniel>
my app sing songs
ayuce has joined #lisp
bsd4me has joined #lisp
bsd4me has left #lisp [#lisp]
mindCrime_ has joined #lisp
<Bike>
https://github.com/Bike/iterator i wrote this on kind of a whim and i'm curious if anyone has thoughts on it/could use it. you can do things like (map (accumulator nil :from-end t) #'1+ (iterator (vector 4 5 6) :start 1)) => (7 6)
johnjay has joined #lisp
Oladon has quit [Quit: Leaving.]
<jackdaniel>
20h project, sounds like fun :)
johnjay has quit [Ping timeout: 240 seconds]
Archenoth has quit [Read error: Connection reset by peer]
atobtoc has joined #lisp
Jeanne-Kamikaze has joined #lisp
iAmDecim has joined #lisp
EvW has quit [Ping timeout: 244 seconds]
EvW has joined #lisp
Oladon has joined #lisp
atobtoc has quit [Remote host closed the connection]
space_otter has joined #lisp
<kelamir[m]>
Do you all prefer I capitalize your nicknames or leave them lowercase?
<kelamir[m]>
IRC by default has lowercase nicknames, if I am not mistaken.
<Josh_2>
Why not just reproduce them as you see them ¯\_(ツ)_/¯
<emacsomancer>
kelamir[m]: I think you should stick to however people have them, so those of us who have notifiers when we're mentioned will indeed get notifications
rpg has joined #lisp
<emacsomancer>
many irc clients do completions anyway
Bourne has joined #lisp
CrazyPython has quit []
<kelamir[m]>
Makes sense. Thanks, Josh_2, Emacsomancer!
<emacsomancer>
kelamir[m]: (hmm, though it turns out my notifier is smart enough to ignore case)