freenode/#lisp - IRC Chatlog
Search
2:00:13
kuwze
Xach: does this still work for you? http://lispblog.xach.com/post/112939066338/using-paredit-within-screen
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.