freenode/#lisp - IRC Chatlog
Search
10:57:46
phenoble
I am working through Seibel's `Practical Common Lisp`, and just encountered behaviour using SBCL different from the book. I wonder why this is.
10:58:31
phenoble
So, Seibel explains that appending lists using append does not append copies of the passed lists, but essentially re-uses their memory.
10:58:46
phenoble
Such that, if any of those lists is changed afterwards using e.g. setf, the appended ...
11:00:22
phenoble
(progn (defparameter x (list 1 2)) (defparameter y (list 3 4)) (defparameter z (append x y)) (setf (first y) 20) z)
11:03:33
beach
phenoble: Well, obviously, if you re-evaluate the first defparameters, then you get new values of x and y.
11:05:04
phenoble
beach: yes, I am trying to recreate what I did before... entering these commands one after the other, does infact also lead to (1 2 20 4).
11:16:23
phenoble
Related question: is the rationale for having append behave in this way performance considerations that come to play in scenarios where the last element contains another cons cell (that links to another cons cell, ..and so on)?
11:17:05
phenoble
Because why else would one construct append to behave in this (otherwise odd?) way, I suppose?
11:17:29
phenoble
Asking because I am still a little uncertain regarding these list structures lisps use internally..
11:18:05
TMA
phenoble: APPEND is very old. by sharing as much as possible, you conserve memory (which was neither plentiful nor cheap those days)
11:20:05
TMA
phenoble: absent mutation, there is no natural way to tell, whether the last list is shared or not.
11:20:11
phenoble
Yes, but apparently things are shared only then, when dealing with "cons cells lists" I suppose (the way I use that term might reveal my lack of knowledge, sorry). Because in a scenario of e.g. (append (list ..) (list ..) (list ..)), only the last element is shared - which does not seem efficient.
11:21:44
TMA
phenoble: [[well, I am lying a bit. you can compare the conses for EQ, but from the point of what the list _contains_ there is no difference]]
11:22:57
TMA
phenoble: in general, you cannot share the non-last lists, because that would entail modyfying them
11:24:37
TMA
phenoble: NCONC does the modification. given your definitions of X Y, try (progn (defparameter q (nconc x y)) (values x y q))
11:25:43
phenoble
TMA: yes, I am starting to understand the details I think. This is essentially about how to deal with linked lists in different ways.
11:29:20
TMA
phenoble: drawing boxes helped me; this kind of boxes: http://d2vlcm61l7u1fs.cloudfront.net/media%2Ffda%2Ffda36e53-c6d1-47c8-88b7-9a418d0f7e84%2FphpFNhftT.png
11:38:17
phenoble
hmm, when I pass a "list" as an argument to a function, I'd assume that only the first cons-cell is copied. Is that correct?
11:39:42
phenoble
Though I would be surprised if that was not true, because from that it'd follow that the whole list is copied, would it not?
11:41:10
phenoble
mhn, I miss C++'s verbosity concerning these matters (pointers,references,lvalues,rvalues) - its explicit use of these concepts does make it explicit what is happening
11:50:50
TMA
phenoble: there is no pass-by-value -- everything is passed by reference (well, the implementation is free to do as it pleases, as always)
11:54:48
phenoble
TMA: I am starting to see why lisp is referred to as much as it in the context of functional programming. It's a good fit for it w.r.t. performance.
12:49:16
beach
phenoble: Common Lisp uses what I call "uniform reference semantics" which means that every object is manipulated through a reference to it. The calling convention uses call-by-value uniformly, in that arguments are evaluated before they are passed to a function, but the value obtained is a reference.
12:50:57
beach
This convention turns out to be the only sane one in a language with automatic memory management. It is much faster than what is possible in a language such as C++, which is why I frequently say that "it is possible to write a C++ program that is both fast and modular".
12:54:09
beach
To quote Paul Wilson: "liveness is a global property". So, in a C++ program, to make sure that you know the number of references to an object, you must either 1. break modularity so that you know it that way 2. introduce reference counters which makes things orders of magnitude slower, or 3. always copy objects so that you know that each one has a single reference, which is also disastrous for performance.
12:56:52
jackdaniel
beach: that was a joke. A: XXX *is* good. B: <hurrs with preparations to use XXX>. A: is NOT*. B: <halts the preparations>.
13:05:46
LdBeth
How does it determine the font name? Seems it’s neither by postscript name nor file name of TTF/OTF font.
13:07:31
shka
well, numbers probabbly are copied, but since they are inmutable anyway it makes zero difference
13:08:17
Bike
nothing is explicitly copied with respect to eql, which is all you care about most of the time
13:09:38
shka
anyway, manual memory managment is difficult, boring and basicly: https://dannydainton.files.wordpress.com/2017/06/angtft.jpg?w=636
13:12:07
Bike
well, C++ copies a lot because it puts things on the stack, so like if you return a complicated object from a function, it has to be copied
13:12:22
Bike
and it puts things on the stack because there's no way for it to put them on the heap itself
13:14:37
Bike
eq is in kind of a weird semantic place because it can distinguish objects that nothing else in the language does, in implementation dependent ways
13:14:52
beach
shka: "Nothing is ever implicitly copied" is what is known as a "pedagogical lie". And "Uniform reference semantics" has an emphasis on "semantics", i.e. it is AS IF every object is manipulated through a reference, simply because there is no portable way a programmer can determine whether it is true or not.
13:18:11
shka
anyway, I was looking for small forth interpreter of FORTH written in easy to understand CL code
14:13:57
phenoble
beach: Just reading your comments on our earlier discussion - thanks. I'll definitely keep your reference to memory management in mind in further study.
14:15:17
phenoble
beach: About C++ performance and modularity, though, I'm not sure I see the connection. I see C++ to be so flexible that you can essentially do everything you want - but at the price of complexity in using that... let's say, well-performing and modular thing, you've created.
14:16:50
beach
phoe: The problem with any language without automatic memory management is that you can't know what module is keeping references to your objects when you pass an object to such a module.
14:17:04
phenoble
beach: using smart-pointers that introduce some book-keeping logic via reference-counting mechanisms is not per-se slow
14:18:27
phenoble
beach: ah, you're discussing this still in the context of automatic memory management
14:20:20
beach
Or rather, you do have a choice, which is to break all modularity so that you know whether a module keeps a reference to your object.
14:20:27
phenoble
beach: Well, you could devise your own scheme of making sure that memory gets deallocated at the appropriate times I suppose.
14:22:09
phenoble
beach: ok, I'm not all that deep into language design under these aspects (modularity?). I can neither speak nor think with authority on this. You win :-).
14:22:13
beach
phenoble: But apparently C++ programmers are being lied to. They think they now have garbage collection in their language, and they think the compiler can generate fast code. Since they don't compare with anything else, they believe it.
14:28:05
TMA
beach: to be fair, there is a sentence in the standard, that says basically 'if you do this, you will probably break garbage collector (if you happen to use a implementation that provides it)'
14:32:14
minion
There are multiple help modules. Try ``/msg minion help kind'', where kind is one of: "lookups", "helping others", "adding terms", "aliasing terms", "forgetting", "memos", "avoiding memos", "nicknames", "goodies", "eliza", "advice", "apropos", "acronyms".
14:36:52
beach
phenoble: So let me just say one more thing. When I program an application in C or C++ (which I haven't done for some time), I use pointers for everything, so that I get uniform reference semantics, and I stick in the Boehm etc. garbage collector so that I don't have to worry about freeing objects that are dead.
15:42:12
phenoble
beach: ok, I was not aware that the question on which data primitive to use for keeping reference to dynamically allocated memory is something to consider in the context of performance. In my day-to-day dealing with a large C++ codebase many other considerations took precedence (so far).
15:49:45
beach
phenoble: Yet, people often cite performance as the main reason to use C++. But then apparently, they don't care so much about it after all.
15:52:12
phenoble
beach: The performance bottlenecks have, so far, been elsewhere. Besides - performance is rarely a topic. There's many other considerations to take into account when deciding on which programming language to use.
15:52:35
phenoble
beach: I'm not sure that attributing a "do-not-care-attitude" to anyone, is part of it.
15:53:32
on_ion
giving a talk to industry does not make one an expert =) else trolling irc i would have big points
15:54:10
beach
phenoble: Yes, but in general, decisions are made by incompetent decision makers, as the talk explains.
15:54:33
jeosol
a couple of my buddies, who program in other langs, keep questioning my choice of CL for a project I started
15:54:58
beach
on_ion: No, but (as my "bio" says), I have a life-long experience from academia and industry in 5 countries on 4 continents.
15:56:00
jeosol
on_ion: good question, first they see my screen (emacs) and kept wanting to know what strange language I was using
15:58:57
beach
jeosol: Yes, there is a very significant psychological barrier to admit that someone else made a good choice when choosing a programming language.
16:00:02
beach
jeosol: This essay explains the main such barrier: http://metamodular.com/Essays/psychology.html
16:00:50
beach
on_ion: That is part of it, but, as my essay explains, there is a great psychological barrier to even learning more languages than they already know.
16:02:28
easye
beach: Hmm <http://metamodular.com/Essays/psychology.html> is returning "An error has occurred." page for me.
16:03:23
jeosol
I feel working with CL, when you start out, you are productive, but that productivity, if you will, delta(productivity)/delta(time) actually increases, because of prior knowledge, prior building blocks etc
16:05:18
jeosol
phenoble: good question: my language history: fortran77, f90, then grad school (matlab, C/C++), upon graduating pick up CL,
16:06:21
phenoble
jeosol: interesting. I find that I get better at anything I seriously work with for a while - no matter the language :).
16:07:36
jeosol
phenoble: my programs are usually written in layers (mostly CLOS), what I meant by increasing productivity is that, adding new functionality or feature is much easier as I pickup previous layers or module
16:07:51
beginner_supreme
I'm a bit of a beginner at CL (lot of ways of doing things -> hard to determine best way) but I feel it's probably the best language to use for the majority of applications one can think of
16:08:12
on_ion
beach: i think there may be a contrasting anti-barrier as well, for those knowing too many languages
16:09:14
jeosol
if you had to lead a project and had a free choice, you probably will have to explain, if not defend your choice right?
16:09:27
phenoble
beach: I just meant to say that I do not know in which context the causal relationships you describe ("They are going to blame you") .. happens.
16:09:40
beach
jeosol: The only way I have found to work is to show that you can do work better and faster than others. Then, eventually, initiative will come from others and whey will want to know what you are doing.
16:09:50
xristos
beginner_supreme: it's not the best language if you treat engineers like cogs in a machine (commoditization)
16:10:35
beach
on_ion: apparently, yes. I don't know what the problem is. It worked for me a few minutes ago. And I haven't changed anything since.
16:12:01
phenoble
xristos: interesting. What inherent quality of lisp makes you think that engineers using it are harder to treat like cogs in a machine, than, say, engineers using C++?
16:12:14
beach
jeosol: My talk emphasizes establishing a risk analysis to make the choices. In particular, if you include programmer productivity in that analysis, you can compare the gain to the cost of training staff, etc. But it is entirely possible that the decision makers do not accept that there is a productivity difference between different languages.
16:13:00
jeosol
beach: good point. I was actually at the point of starting to teach CL or at least introduce them gradually
16:13:37
beginner_supreme
There is an observation called "zipf's law" where the 2nd most common thing is about half as common as the first, the 3rd 1/3, etc... So you get an 20% of items cover 80% of the area.
16:13:56
jeosol
parentheses complaints was not a big issue for me when I started, because I was coding C/C++ in emacs then.
16:14:00
beach
phenoble: If you want to be able to hire and fire programmers at will, you need to use a programming language that every programmer knows.
16:14:23
beach
phenoble: If you use Common Lisp, you have to invest in training and keeping your programmers.
16:14:57
xristos
phenoble: trying to find ron garret's post about the attitudes he encountered at Google
16:14:59
beach
phenoble: But since decision makers don't know that there might be a productivity difference between different languages, they can't justify the additional investment.
16:15:08
_death
the simple fact is that a huge amount of effort went into writing and supporting performant libraries in C and C++.. and Lisp is not on the radar for many performance-critical applications..
16:18:45
jeosol
once spoke to guy at 21s inc, some company in the east coast, US, using mostly allegro, you guys may have heard of the company. He did say they use CL actively for defense projects
16:19:06
beach
_death: When I hear expressions such as "on the radar", I think of failure to do a real cost and risk analysis, and I think of incompetent decision makers making decisions based on "gut feeling", even though they have neither training nor experience with the alternatives.
16:20:47
_death
beach: ok.. when I used this expression, I meant that I recognize that it's off the radar given the current state of the world.. so in this case I would be the decision maker
16:21:21
beach
_death: Sure, I can admit that there are restrictions when you are faced with an existing code base.
16:22:41
beach
I explain that "We need all the speed we can get... so we choose C++" really means "No matter how minuscule the additional performance turns out to be with C++, we want it, and we are willing to spend any amount of money and any amount of time to get it."
16:22:53
_death
I use lisp (incl. ffi to said libraries) when I can get away with it, and when I know it'll give me a good advantage.. but otherwise, it really depends on what you're doing, and I'd be wary of generalization
16:23:54
beach
I explain that "All our programmers already know Java, so we choose Java" really means "I know for a fact that there is no other language out there that would be so much more productive for this project that it could compensate for the investment in training our programmers".
16:24:44
beach
_death: Totally agree. Hence my emphasis on risk analysis (which is most often not even considered).
16:25:31
phenoble
beach: But that argument does sound very reasonable to me, in a real-world scenario.
16:26:05
phenoble
beach: Or put another way: it's not an argument of which it'd be immediately obvious to me that it'd be blatantly wrong. Always. Everywhere. All the time.
16:27:57
beach
Yes, it sounds plausible, but that is also why decision makers have to force themselves to establish a real budget.
16:27:59
phenoble
beach: I said that it is not obvious to me that the decision against using Java in favour of e.g. CL (disclaimer: I hate Java), in a business context, is obvious in favour of CL. All the time. Everywhere.
16:28:51
beach
phenoble: Of course. All I am saying is that, in order to make an informed decision, you cant rely on "gut feeling", because it is often totally wrong.
16:29:22
beach
phenoble: It is plausible that Java or C++ comes out as the right answer, but then it should be the result of a real cost and risk analysis.
16:29:25
phenoble
beach: Yes. But if that is the take-away message, the take-away message seems a little thin to me.
16:29:52
_death
in many applications, it may also be the case that Lisp would only need a little help.. and if that is done then it's awesome.. but then it also depends on the people you work with and their background..
16:30:03
beach
Not to me. It means that the software industry is making hugely incorrect decisions because they don't know how to make such analyses.
16:30:46
beach
_death: And in my talk, I also introduce the possibility of hiring different people for a new project. That is another item in the cost analysis.
16:31:05
jeosol
from the link xristos provided, the VP shut down the use of lisp, from the write out, without much discussion, hmmm.
16:31:39
beginner_supreme
Maybe people aren't exposed to more languages, so they learn the ol' java and ye ol' c++ and stick to those forever because they're "good enough"
16:33:03
_death
beach: I see.. that may work in some fields.. some are quite specialized though and an informed analysis would likely still result in the "status quo" language of that the ecosystem
16:33:20
beginner_supreme
True but I for example enjoy reading about languages so I go looking for things like CL, Forth, and tcl.
16:33:49
beach
_death: Again, I agree. And in such fields, the cost of a different language choice would show up as a huge negative budget item.
16:33:50
beginner_supreme
That most people don't really have, they just consume languages and compilers
16:34:35
jackdaniel
good for you that you have a) time for learning new things; b) you are genuinely curious
16:34:40
phenoble
beginner_supreme, anecdotically: "good enough" is often a goal in life you very much hope to achieve
16:35:57
jackdaniel
but it all comes to what you consider your goal. If you treat programming languages as a vehicle to carry your thought, then finding "good enough" language is an acceptable heuristic
16:36:18
jackdaniel
spending considerable amount of life on studying programming languages - arguably is not (given stated constraints)
16:37:48
beginner_supreme
Perhaps selecting [close to] all-encompassing language would allow one to do both. In this case CL is a good choice, at least in my limited learning experience.
16:37:48
phenoble
jackdaniel: oh, we've ventured off discussing lisp in particular a while ago. I do find the discussion still relevant though.
16:38:19
_death
beach: maybe your talk is aimed towards a target audience that does not consist of Lispers, so the intention is just to make possible a different train of thought with such considerations..
16:39:15
jeosol
saw an aws talk on microservices where they stressed multi-language, i.e., used the best language for each service and make services talk to others. Is this really viable?
16:39:44
beginner_supreme
I was just sitting here pondering this question and saw your message when I looked up
16:40:48
phenoble
jeosol: good question. I've been learning haskell,elisp,CL and brushed up on some serious Python programming in the past 12 months, next to a day-job doing C++. I'm doing fine, but I suppose it's not for everyone.
16:41:38
jeosol
I didn't mean it not doable, I was coming from the point of building, maintaining a team
16:42:18
jeosol
if each person in each of a microservice decides to use a different language, or have a small set of languagges, e.g., python for ML tasks, C/C++ for critical tasks, etc
16:42:27
beginner_supreme
Maybe multi-language is viable when there are many people involved, but I would imagine that a single language (CL) that can absorb different features via macros/read-macros is better for smaller teams?
16:43:02
phenoble
jeosol: I didn't mean to comment on possibility, just that I can very much relate to that question :). I'd also guess it be pretty hard to manage (a) dev team(s) in such a "context".
16:44:01
phenoble
jeosol: this could be a fine read for some in that context: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/
16:44:49
phenoble
(apologies for slight off-topicness, though author makes case against using too many languages in single company)
16:46:48
phenoble
jeosol: actually, that's not the article. I was looking for his telling of his personal story. -Very- good read. Somewhere on that page...
16:52:00
jeosol
this was good discussion overall, some good points. may be no need to explain my choice of CL
17:01:15
phenoble
jeosol: funny of you to ask, I'm planning on working on my machine-learning skills, and given the available tools and resources out there, Python will indeed be my choice for that.
17:01:52
phenoble
jeosol: but I am about to have a look at Racket for Scientific Programming soon, too.
17:02:36
phenoble
jeosol: ...just got to finally finish works on my every-growing (but also every-improving) emacs configuration in elisp :)
19:34:17
Josh_2
Hopefully gonna have my first paid dev work over the summer because of my Uni project that I wrote in common lisp :)
19:44:30
beginner_supreme
I mean vlime, it's like slime but for vim. Similar to the slimv project except slimv is written in python, while vlime is a mix of CL and C
19:45:59
beginner_supreme
I'd love to but I saw C-c C-x C-h C-<insert letters> and my brain cache had a few misses
19:47:52
_death
beginner_supreme: it has emacs already configured and you drop straight into a CL repl
19:50:36
beginner_supreme
So far I've been using a regular editor without the repl server connection.
19:50:59
phenoble
beginner_supreme: you should try spacemacs (an emacs distribution) with evil (a vim emulation). Both together do away with what many would consider, Emacs' unintuitive keybindings.
19:53:30
beginner_supreme
I'll look into portacle and spacemacs (disclaimer: I don't use vim either - it just seemed less steep a learning curve)
19:55:37
_death
I don't know if the curve is that steep... especially if you're going to learn Lisp anyway
19:57:51
phenoble
_death, beginner_supreme: The steepness might also depend on how satisfied you are with the default configurations of vim and emacs. I know that I wasn't, so,... 2 years later I'm on freenode in #lisp.
19:58:28
oleo
i'm not sure why an explicit upgrade of asdf after loading quicklisp makes so much problems
19:59:01
oleo
but this way quicklisp can decide if it wants to upgrade stuff from the asdf in common-lisp/source/asdf
19:59:58
beginner_supreme
Anyways, thanks for the great conversation everyone, till next time [possibly with other nicknames, don't feel like registering yet]
20:04:50
aeth
Imagine if beginner_supreme registered and continued using that name for decades, while becoming one of the biggest experts in Lisp.
20:39:38
pjb
aeth: well it would be a major inconvenience, since he used _ instead of - in his name…
20:47:43
aeth
pjb: well the lisp community is the only community I know of in Freenode not to use -'s in channel names
20:48:22
aeth
I know it's because - is something like a namespace in Freenode and they're all (afaik) independent, but it's still kind of funny
22:07:05
aeth
I wonder if a normally AOT Lisp could JIT FFI to increase CFFI performance. Apparently JIT CFFI function calls have lower overhead than equivalent C function calls. https://news.ycombinator.com/item?id=17171252
22:39:45
ZigPaw
but the difference is probably insignificant (like few cycles). If you need to gain so few cycles, you are probably better off inlining the function (and it might be done by JIT I think). But I'm not an expert.