freenode/#lisp - IRC Chatlog
Search
5:38:16
asarch
I did: (ql:quickload "clim-examples") in "This is SBCL 1.3.14.debian, an implementation of ANSI Common Lisp." and everything is fine, however when I do: (clim-demo:demodemo) I get: https://pastebin.com/0adz1s7D
6:39:14
jackdaniel
since quicklisp distribution seems to be the same, you probably have another mcclim copy somewhere in local-projects or common-lisp directory
6:39:42
jackdaniel
notice difference in instructions: ";; try (CLIM-DEMO:DEMODEMO)" vs ";; try (CLIM-DEMO::DEMODEMO)"
6:41:57
asarch
I didn't see this: ./.cache/common-lisp/sbcl-1.3.14.debian-linux-x64/usr/share/common-lisp/source/mcclim
8:29:54
makomo
does cl-who only recognize the "htm", "str", etc. symbols if they're interned in its own package?
8:31:25
makomo
hmm i guess that makes sense, since how would you otherwise call your own functions with those names
10:03:08
shangul
I've ran into a problem. I decided to spend 1-2 year on Lisp and do my stuff in this language. but now I see I may not have my projects done in Lisp because I'll program them in my previous language's way. on the other hand I can't wait 1-2 year or even months to have enough experience.
10:03:59
phoe
the thing I've employed is write snippets or pages of code and then post it here and on #clnoobs to get reviews
10:04:13
phoe
that way I got a lot of information about how to write the same thing in more idiomatic Lisp.
10:04:38
phoe
there's a lot of lispers around here who are willing to freely share that information and do small reviews. you can leverage that fact.
10:05:26
phoe
make sure that you get these right, then use that information to construct larger stuff.
10:05:35
shangul
I know I'll be able to learn and program my project in Lisp even through I'm a beginner. but I'll do them not in Lisp's way
10:06:30
shangul
So I shouldn't program my projects till I get enough experience. but I can't wait till then.
10:09:14
phoe
you are free to customize the language to your own liking, but don't expect other people to abide to that liking
10:10:33
pjb
Coding conventions aren't universal. If your problem calls for other conventions, then your project can apply entirely different coding conventions.
10:11:33
phoe
it's hard to learn how to properly use macros to customize Lisp if you don't learn the basics of them first. which is where the basic conventions come in.
10:11:34
shangul
for example someone who comes to Python from C, writes something like "for i in range(len(L))"
10:12:23
phoe
where in Lisp that would be (loop for i below (length list) ...) if I understand that snippet correctly
10:13:11
pjb
shangul: this example is low-level in the global program architecture. It doesn't matter. The higher levels matter more.
10:16:33
shangul
Problem: Write a program which asks user's name, greets him. Then asks 2 numbers(3 digits max), connects those 2 together(23,54 => 2354), multiplies this number at reversed version of itself(e.g. 543 and 345). Solution: https://apaste.info/7HeB
10:17:55
pjb
shangul: see, you wrote low level expressions. They may be correct and nice and all. But your program architecture is bull shit. Literally. A huge pile of nothing.
10:19:21
pjb
You should have written: (defun program () (great-user (ask-user-name)) (let ((n (connect (ask-number) (ask-number)))) (* n (reverse-number n))))
10:19:45
pjb
Then you could see and prove that this program does exactly what the problem statement says.
10:21:03
pjb
Then, you can learn about nice lisp types and operators, to benefit from what CL provides. But this is less important than having a good program structure.
10:21:35
phoe
if you try to compile this, Lisp will complain about undefined functions GREET-USER, ASK-USER-NAME, ASK-NUMBER, REVERSE-NUMBER.
10:23:00
phoe
The thing is, these smaller functions have much smaller responsibilities. One of them is for greeting the user, the other is for asking a number, the other is for connecting them, and so on, and so on.
10:23:24
phoe
Smaller, well-defined functions make it much easier to find erroneous program behavior.
10:25:42
shangul
yes but in this program, these functions are not going to be used, I'm not greeting the user anymore
10:25:44
pjb
shangul: using functions, small or big (actually they should not be big), is raising the abstraction level of your code. This is good, because it makes it easier to understand.
10:26:11
pjb
It makes it closer to the domain of your problem. So you can see more directly the link between your problem statement and your solution program.
10:26:23
phoe
and you separate the control flow of your program from what the program is actually doing
10:28:05
phoe
I need to run and do a thing now - I will refactor your code to more idiomatic Lisp in about an hour if no one does it before me.
10:30:49
phoe
you'll likely need some examples to mimic in the beginning so you can bootstrap your Lisp knowledge.
10:31:14
phoe
doing a single assignment ourselves to give you an example isn't going to do all of your Lisp job. (:
10:34:32
LdBeth
phoe: I think it’s more sane to complain about it after loaded the entire project or file
10:39:37
LdBeth
kuribas: Traditionally Lisp functions only accept fixed number arguments, and people used something like pattern match to do complicated work.
10:45:32
White_Flame
Lisp tends to be a verbose language, with its literal AST formatting, compared to languages whose syntax is specialized to do very specific things
10:46:12
White_Flame
but that also means Lisp can pretty easily express the AST transform of basically any language
10:46:41
MichaelRaskin
So yes, it makes sense to implement them via macros, which is done a few times
10:46:48
White_Flame
and that's not even getting into reader macros, were you _can_ define your own syntactic punctuation if you desire
10:54:17
pjb
Normally, you would put tests in a separate file, but here I left them in the order it was programmed: as soon as you write a function you should test it. you do it normally at the repl, but if you copy your test cases from the repl to a test function you keep it for posterity.
10:54:49
phoe
also it bugfixes one thing in your code - your code will not work correctly if you give it numbers 1234 and 4321
10:57:06
pjb
Well, users tend to come later and ask for bigger limits. So you shouldn't put artificial limits in your code, if you want to avoid irritation.
10:59:17
pjb
Sorry, there's a typo in reverse-number, it should be: https://apaste.info/Ecli was missing the argument to decimal-representation-length
11:01:57
White_Flame
that sort of style is fine for banging out quick & dirty utilities for one-off use or prototypes
11:02:31
White_Flame
but as far as code that you're going to keep goes, that's going to be an opaque blob if you come back a month or two later and need to rework something
11:02:49
pjb
Now, the funny thing with that exercise, is that it cannot be so easily implemented in C on a 32-bit machine :-)
11:03:51
White_Flame
that sort of style is fine for banging out quick & dirty utilities for one-off use or prototypes
11:03:52
White_Flame
but as far as code that you're going to keep goes, that's going to be an opaque blob if you come back a month or two later and need to rework something
11:07:55
shangul
perhaps you are right. But I've red a part of PCL and wrote that code and another one a little longer than that. I'll get frustrated if I go like this.
11:09:20
White_Flame
code golf is fine when you're learning and fiddling with how to call certain standard functions
11:09:37
pjb
shangul: for example, you use read-line to read the numbers. Fine. But users are know to add spaces before or after their inputs! So at least you should use string-trim to remove those spaces.
11:09:57
White_Flame
but as I was talking above in comparison to haskell, Lisp tends to be a bit verbose in the micro-issues, but becomes much more compact for larger projects
11:10:28
White_Flame
it doesn't hyper-optimize on the line-by-line syntactic issues, but rather allows you to build abstractions well, which makes difficult problems much easier to tackle
11:12:53
White_Flame
if something doesn't make sense to you yet (like why people whould make all thse named defuns for everything), then just keep going with other things first
11:13:59
shangul
pjb, I'm not saying you are wrong, I'm just saying 100 lines for a one week beginner is too much
11:16:03
White_Flame
the thing is, the complexity is not high there. You just have to get more comfortable with the language (like any language) to be able to skim & read it well, instead of seeing it as a big impenetrable wall
11:19:47
shangul
pjb, phoe, I was afraid of this. that you write 100 lines for me and I waste your time by not using it
11:20:22
White_Flame
at some point in the near future you'll look back to this problem and say "oh, duh"
11:22:34
pjb
shangul: granted, there are two different phases. When you're just learning the language, you write small expressions just to exercise the operators you're learning. In that case, you're essentially writting tests for the language operators :-)
11:23:27
pjb
shangul: but if you present a small problem statement, like a school exercise, I would grade differently the two kinds of solution.
11:25:07
pjb
In the first phase, you are analysing and studying the details of each operators. In the second phase, you are synthesizing small programs, demonstrating your understanding on how the individual language elements can be combined to implement a solution. This is more like real programming.
11:25:52
beach
kuribas: Here are some ideas for you: http://metamodular.com/Common-Lisp/suggested-projects.html
11:25:53
pjb
kuribas: this is wrong; those great libraries are usually implemented in C or C++ and they are just used from python. you can use them as well fromCL.
11:41:47
White_Flame
kuribas: the appeal of Python is that it makes the easy easy. There's a lot of simple tools at hand, and low barrier to entry for the syntax
11:42:33
kuribas
White_Flame: I suppose also that it has easy answers to most problems. Unfortunately those aren't always the best.
11:43:03
White_Flame
sure, but it keeps a lot of newbies, which then take the language beyond where it really is comfortable going
11:43:56
kuribas
And then they get into problems because of the backwards way of doing things in Python.
14:20:13
jmercouris
So I was reading a bunch of the response to my article on reddit about eco-programming
14:20:46
jmercouris
"An interesting example of an inefficient part of a language would be LISP's 'list' structure - compared to say C++'s vector. Vector is specified to be a single contiguous block of memory - allowing for efficient pointer arithmetic lookup."
14:20:54
jmercouris
"Although theoretically you can store your cons-list thing in a contiguous memory block; you can't do the same pointer arithmetic to give you the nth cell (unless you make a non conforming LISP with the guarantee attached)."
14:21:24
jmercouris
Now, I am thinking I am pretty sure it is possible to make the pointer arithmetic hold true AND have a conforming lisp by layering some abstraction on top
14:22:06
jmercouris
beach: to put things into context, the discussion was, can one design a language such that the implementation HAS to be inefficient
14:22:29
jmercouris
my answer was, I don't believe so, the implementation can always make something implementation as long as it fulfills the grammar syntax, and built-inrequirements of the language
14:23:04
jmercouris
beach: here's the sub-thread: https://www.reddit.com/r/programming/comments/8r9ngc/the_ecoprogrammers_dilemma_use_electron_or_save/e0rn7kq/?context=3
14:23:17
beach
jmercouris: Vectors are faster for random access, but list are more flexible in that they can grow and shrink easily. They can also share elements between several lists.
14:23:39
jmercouris
but the question is rather, can one design a language such that the implementation *MUST* be slow
14:25:09
jmercouris
is it possible to design a language specification such that the counting of the numbers would take longer in language A then language B
14:25:33
jmercouris
given that the implementation is free to implement the language however they so choose
14:26:31
beach
I suppose you can specify in your language definition that numbers have to use Church encoding.
14:29:12
beach
jmercouris: What *is* true is that Common Lisp lists pretty much have to have O(n) lookup complexity. But comparing them to vectors is really dumb too, because vectors are bad with other things.
14:29:43
Bike
old lisp implementations did cdr coding so there were O(1) lists, but it's kind of silly
14:29:46
beach
jmercouris: Try adding a new element to the front of a vector. That's an O(n) operation, where n is the length of the vector.
14:30:05
Bike
and on the flipside, just being able to get pointers into a vector doesn't actually mean they're contiguous, or that access is O(1)
14:30:17
beach
jmercouris: So vectors and lists are two different data structures that are good for different use cases.
14:30:30
Bike
c.f. whatever latest article about how turing is wrong because cpu caches exist, or whatever
14:31:57
jmercouris
beach: yes, but couldn't one had a vector with the addresses to each element in the list?
14:33:00
jmercouris
Here's what you'd have to do, you'd have to shuffle all sorts of elements around whenever you cons something
14:33:11
jmercouris
depending on whether you need to allocate a new array to grow it, or insert something in the middle etc
14:33:32
jmercouris
you'd lose a lot of those characteristics, BUT, you would have the very fast look up time
14:33:34
Bike
well, that's what beach said earlier- you're losing the "can grow and shrink easily" property
14:34:05
jmercouris
as long as you are adding and removing from the end of the list, it should be fine
14:34:54
jmercouris
yes, of course, but if you pad enough, it could result in very fast look up times, and some other interesting properties
14:34:56
Bike
it's just a resizable vector, which is a nice structure, but has different characteristics from a list
14:38:00
Bike
i mean, lisp has this already, you make an adjustable vector and vector-push-extend it
14:54:15
pjb
jmercouris: Of course there are comparisons of lists vs. vectors, eg. by Stroustrup in C++, but: 1- the author is obviously biazed, 2- it depends on the hardware (notably caching), 3- it's rather unrelated to global performance, which depends more on other language design factors. For example, C const is used so inconsistently, that you often have to copy a const char* string to pass it to a char* parameter, even if most of the t
14:54:15
pjb
it won't be mutated. It's even worse in C++, where a lot of copying is done or has to be done when in lisp you would just pass a reference.
14:56:25
pjb
jmercouris: notice notably how passing a reference to a mutable or an immutable object in lisp doesn't depend on compilation time declarations, but on run-time check. Therefore if the actual processing doesn't try to mutate the object, when an immutable one is passed, it will work perfectly good. It's all win, programmer time, compiler time, run-time. At the minimal cost of a small dispatch or check at run-time. On the other ha
14:56:25
pjb
equivalent would require a big cost in programmer time, compiler time (compiling lots of generics variants or templates), AND still at run-time in copying things everywhere.
14:59:37
jmercouris
I guess there are indeed many assumptions, and lots of external factors not considered within this argumentation
15:00:06
jmercouris
a complete analysis would probably be too much work and effort for the sake of replying to a comment on reddit
15:00:10
pjb
For example, there's the famous argv thing. In programs, usually it's treated as an immutable vector of immutable strings. However, some programs want to overwrite some of the argument strings (eg. passwords). The actual effect is implementation dependent (eg. whether this has consequences on how ps(1) reports the command). Nonetheless, in programming languages as C or C++, there's no easy way to denote that you won't mutate an
15:00:10
pjb
in general, but sometimes you will stil mutate it. In lisp, if the string are mutable then they're mutable, and if not, then they're not, and it's a run-time check.
15:01:04
pjb
Basically, what I mean is that C and C++ programmers and language designers don't have the means of what they aim at.
15:02:22
pjb
If you understand lists in lisp, then all your accesses to list elements will always be O(1).
16:03:13
loke
Scrolling in the climaxima windows looks horrible, and in the videos you get a taste of that
16:10:53
loke
beach: I was looking at the WITH-DOUBLE-BUFFERING macro, and tried to use it in the simplest possible way when scrolling.
16:11:09
loke
Something did happen (I got lots of garbage on the screen, and _some_ of the content moved)
16:11:39
loke
beach: Do you know how that thing works? It clearly wors in some cases (like the cube game in demodemo)