freenode/lisp - IRC Chatlog
Search
3:36:24
Josh_2
I left my laptop on, I was attacked by someone I know so that sobered me up pretty fast
6:43:44
krwq
hello, I wonder, does every lisp implementation use cons or is there any where (equal () t)? ( () would be an empty list but nil is not a list )
6:45:38
SaganMan
I think every implementation use cons but lisp intepretor doesn't bother to print nil
6:47:12
krwq
sbcl but currently writing my tiny interpreter which I'd like to eventually expand to compiler
6:50:14
krwq
if every lisp implementation chose cons I'll go with implementing list with conses if there is a precedence for choosing more memory friendly list representation I'll go with that
6:52:51
krwq
I noticed when I write in common lisp i rarely play such low level as list manipulation so there is not much gain in doing linked list
6:54:11
krwq
I wouldn't mind reversing it so that regular list would be implemented with vector but linked list implementation could be there too
6:54:17
jdz
krwq: if you've looked at basic data structures you'd know that these are different data structures, and have different properties and tradeoffs.
6:54:53
krwq
jdz: i did a lot of algorithms and from my experience linked list is almost always slower than vector
6:58:20
krwq
but when you compile to machine code you could easily put non-mutable vector on the stack while mutable conses will be a PITA
7:06:48
jdz
krwq: it basically defines the "seq" protocol, and one can use it on all kinds of things, including lists and vectors and strings.
7:07:50
krwq
Zhivago: but you could easily define a sub-vector type which could be used the same way - besides that is mostly used with tail-recursion which is easily optimized
7:08:56
krwq
I'm thinking of a list as a plain block of memory and two pointers marking beginning and the end
7:09:46
basket
jdz: Well Common Lisp has the SEQUENCE class with all kinds of subclasses, including lists and vectors and strings
7:12:00
krwq
i think I'll try implementing list with vector and move back to cons-es if it will become annoying
7:14:41
krwq
that will make it much easier - i will have to quirk code all over the place if I implement list with vector and have to assume that empty vector is NIL
7:15:06
beach
krwq: For a compact representation of lists, see the Lisp-machine feature called "CDR coding".
7:16:58
beach
krwq: Lists are much faster for things like adding or removing a single element from the front.
7:17:50
krwq
beach: that's true I admit but if a compiler detects that you only do that then it can switch direction of vector
7:18:31
beach
krwq: A vector won't solve the problem. It would need to be re-allocated from time to time.
7:18:40
jdz
Funny how the Wikipedia page on CRD coding links to https://en.wikipedia.org/wiki/Unrolled_linked_list.
7:20:25
beach
krwq: Different data structures have different performance characteristics. The creators of Common Lisp were very concerned about performance. That is why Common Lisp gives the programmer a choice, as opposed to (say) implementing lists as balanced trees which would be slower for the operations for which lists are particularly fast.
7:20:36
krwq
thread safe queue might be the only example where linked list might actually win - or if you do a lot of manipulation in the middle which is quite rare IMO
7:21:35
beach
krwq: If you add or remove elements in the middle, you should use neither a list nor a vector.
7:21:35
krwq
beach: memory used to be more expensive when lisp was invented so it made sense back then - right now almost always it is better to have one chunk of memory
7:23:06
shka_
"so, this vector thingy, aren't you sure that in fact it is some radix tree based functional data structure?"
7:23:49
beach
shka_: Just like we can't predict the performance of adding a single element to a vector.
7:26:39
krwq
beach: I never said they are always better - they are almost always better than linked lists
7:27:21
beach
krwq: "almost always" makes no sense. It depends on the use case. You must state it relative to the use case. Besides, what if you are right? Does it mean we should eliminate lists?
7:29:22
beach
krwq: Anybody can say anything on YouTube. That video does not in any way show that "vectors are almost always better than linked lists".
7:30:36
beach
krwq: To make such a statement, you would have to look at all programs that use lists, then re-implement them using vectors, count the number of programs that have their performance improved, and if it is greater than half, then you are right.
7:32:29
shka_
and some people know what they are doing, so forcing vectors in each throat is quite pointless
7:36:41
krwq
https://www.codeproject.com/Articles/340797/Number-crunching-Why-you-should-never-ever-EVER-us - the only case where linked list is better is when you have fragmented memory
7:39:29
jdz
It should have been "Why you should never, ever, EVER use linked-list in your code again if you program in C++".
7:40:29
hajovonta
the article actually states: "The number crunching prefix is key to this whole article. If the "Number crunching:" part of the title is ignored it might be understood as a general advice to always stay away from linked-list, that is not the purpose of this article. "
7:41:29
jdz
The choice of programming language and libraries constrains (or at least heavily influences) the data structure, algorithm and general problem solving choice.
7:43:38
jdz
krwq: For instance the section(s) about locality of reference completely disregard garbage collection and GC'd language implementations.
7:47:54
krwq
jdz: considering that in almost every benchmark linked list loses I'd rather have linked list as a separate data structure - it's true that we can't tell for sure which one is better without implementing reasonable size lisp program and checking how it performs on both implementations
7:50:22
hajovonta
but then there is versatility and maintainability and linked list may be advantageous when these are more important than number crunching performance
7:51:23
jdz
hajovonta: if linked list is not the right data structure, use the one that _is_ right. Where's the problem?
7:52:11
hajovonta
I often use a linked list when first attacking the problem and then later switch if it becomes a performance problem
7:54:05
jdz
Again, I think the original question was about implementing single-linked lists with vectors, and people in this channel argue that that is the wrong thing to do.
9:02:17
miatomi_
anyone know if there's a "newbie friendly" distribution of common lisp? the thing I'm looking at is this: between learning asdf, learning about quickproject, quicklisp, slime, etc. on top of just learning common lisp, there was a lot of friction that I had to go through that might throw some other newbies off. if there was a distribution of sbcl, lets say, that came bundled with quicklisp and automatically installed quickproject with
9:02:17
miatomi_
a short tutorial, that would probably take down the TTL (time to learn) for new people a ton, and give them an almost clojure/leiningen like experience
9:04:39
pjb
clisp has a number of features that are newbie friendly: it includes readline, and has a usable debugger, so you can use it in the terminal without slime.
9:05:27
pjb
Some care is given to return unsurprising results for newbies. Eg. sort will keep the first and last cons cells in place.
9:05:55
pjb
Of course, it is not a good idea to rely on it, but while learning how to program, it is a question that may stay delayed.
9:06:57
pjb
clisp also has a number of modules included, so that you can write interesting programs without having to load any quicklisp libraries.
9:07:34
pjb
So you can spend a couple of years in clisp, without having to learn slime, asdf, quicklisp, quicklproject, etc. Just pure Common Lisp.
9:08:00
pjb
Once you know Common Lisp you can learn emacs and then include slime. And later you can include libraries with asdf and quicklisp.
9:16:39
jdz
I dropped clisp back when I found the debugger was actually useless for me, and never looked back. I don't even remember what my problem with clisp was.
9:17:55
jdz
Also using lisp without proper environment will only waste time that could be used learning the environment from the start.
9:25:18
shka
miatomi_: portacle is easy to setup (not sure if "set up" term does apply here), i think CCL is quite good and explains things that happen better then SBCL, i did not use clisp so i don't have opinion on it
9:28:35
miatomi_
portacle looks interesting! thanks all for that. I wonder if "learn emacs" might even be too high of an entry, but this looks like it abstracts away the emacs part of it which is nice.
9:29:27
Shinmera
it doesn't remove emacs as a learning component, but it at least includes a reference guide that teaches the concepts and important bindings.
9:33:34
pjb
miatomi_: emacs has a 1/2 hour tutorial. If that's too high of an entry, what are you doing here?
9:37:44
miatomi_
pjb: to be clear, I've passed all of these barriers already. but asking a newbie to learn a bespoke text editor to get up and running in their new language is a lot. other lisps have recognized this, take racket for example
9:39:49
miatomi_
beach: what do you mean? originally I was asking in order to learn if this is a worthwhile project to take on myself. just wanted to get a sense if there was anything newbie friendly out there. I think portacle qualifies
9:44:04
beach
What does the situation look like in industry? Suppose for instance that someone wants to learn C# for Windows. Can they get away with using the editor they are already familiar with? It is not a rhetorical question and it is not meant for miatomi_. I am asking in general because I just don't know. If the answer is "yes", do they then miss out on some features that they could have had if they converted to whatever Microsoft
9:44:52
Shinmera
VS is free nowadays, and it uses the same kinds of keybindings people already know from other software.
9:45:58
Shinmera
I haven't checked, but I wouldn't be surprised if IntelliJ and Eclipse also support C#. Those are, I believe, the other two "top" IDEs.
9:47:13
beach
OK. Thanks. So when people complain about having to learn Emacs, they basically already know one of those, and they all have the same key bindings?
9:47:18
Shinmera
Generally if the language in question has enough industry pull most major IDEs are going to include support for it.
9:47:56
Shinmera
beach: They diverge in details, but most people complain about copy, cut, paste, undo, redo, open file, save.
9:48:36
Shinmera
And you can't really change them in Emacs because the defaults would clash with too many other keybindings. (C-c prefix, for instance)
9:49:31
Shinmera
I've considered the idea of including more standard keybindings in Portacle, but rejected it because it would make getting help harder since I'd have to change too much.
9:49:52
beach
That really sucks. I mean, Emacs predates all those, and I think the Emacs bindings are quite well thought out. Frequent operations are short, infrequent ones are long. And it is rare that two key sequences are similar if one is "dangerous".
9:50:13
basket
Shinmera: Emacs ships with cua-mode that does that; it's not too much of an issue for clashes because C-x and C-c are only cut and copy when the region is active
9:50:46
Shinmera
basket: I'm aware of cua mode, I still don't consider it a good idea, especially because C-c etc are still useful when regions are active.
9:52:58
scymtym
people's wish to keep working within their respective environments has been recognized in a certain way, though. many IDEs are now basing their support for programming environments on the "language server protocol" which is like a JSON-based, language-agnostic, specified version of the swank protocol
9:53:41
basket
Shinmera: Yes, but it does make it much more viable for newbies who just want a Lisp editor with familiar keybindings and see learning Emacs as a hurdle, I think
9:54:19
Shinmera
basket: I consider the potential for confusion in the bindings clash too high a risk
9:55:36
beach
We have had system administrators who found it a good idea to provide a "standard" startup file for (say) students. The result was that nobody knew exactly what key sequences to use, or what happened when the wrong one was accidentally issued.
9:59:13
pjb
At least Xcode implements the basic emacs control keys, and integrates good enough with an emacs editing workflow…
9:59:29
miatomi_
pjb: haha, fair. I love emacs too, I had the advantage of learning it before taking on clisp weirdly.
10:03:17
jdz
pjb: not sure it's Xcode specifically, because emacs keybindings work in all text fields on OSX.
10:10:32
d4ryus
readline, which is pretty wide spread among shell utilities, also uses Emacs Keybindings (as default, at least)
10:11:09
jdz
Yes, and Emacs users usually use them, other people even don't know their command line has undo.