freenode/#lisp - IRC Chatlog
Search
3:31:44
aeth
What video is that? There's no title bot in here and I don't trust YouTube links. (Although it probably is safe or else |3b| would have commented.)
3:32:03
aeth
Oh, it's this one, don't even need to click, it matches the URL on the front of HN. https://news.ycombinator.com/item?id=15880172
3:39:37
vtomole
From around 43 minutes in that video he talks about what the interns thought of Lisp.
6:53:52
Hiver
I found this (https://gist.github.com/endofinnsmouth/009a7a3a91b180371fea20cc983898ed) online, and it said it was an "nlp". What is that, and can you explain this program?
6:56:37
Hiver
just so i know what not to do though. what is bad about that code? I dont wanna fuck up. ooooooooooh and thanks
6:58:21
jackdaniel
line breaks are bad, it is not clear what functions do (not docstrings or comments)
7:03:27
Zhivago
That's just general advice -- but it also applies regarding people who can't spell "can't".
7:03:53
beach
Hiver: It uses SETQ to define special variable, but that is undefined behavior. And it does not use earmuffs on special variables, which is bad style.
7:08:08
jackdaniel
no, style is just a strong indicator it is not worth reading. program doesn't look useful either
7:12:05
Zhivago
They're trying to get intelligent people to ignore them so that they can focus on the stupid ones.
7:13:40
Zhivago
No. They just get the intelligent people to decide that the message is obviously a scam so that they then don't respond, which would waste the scammers' time.
7:15:01
Hiver
ooooh. ok. so, he wont come here because he is afraid of the advice? or is the program a scam?
7:15:09
Zhivago
The same process applies to software. Intelligent people avoid using software that looks like it was written by a twelve-year old who had been dropped frequently on its head as a child.
7:16:02
Zhivago
Which is generally a good idea, because software that looks like that probably hasn't been written carefully or well thought out, and the cost of maintaining it is high.
7:17:24
Zhivago
One problem is that to beginners, they are so bad at reading code that they can't distinguish between good code and bad code.
7:20:17
minion
Hiver: direct your attention towards pcl: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
7:22:41
Hiver
Also to respond to beach. He used to do a bit of Java (idk if it is true). Recently switched to LisP
7:22:59
beach
Hiver: Your friend should also learn to use an editor that can handle Common Lisp code so as to obtain correct indentation.
7:27:19
turkja
lol, why so harsh? it for sure looks like someone's first lisp program.. but it's a start anyways :)
7:38:25
vtomole
One of these days I'm going to have enough money to go to that Bay Area Lisp meet up and ELS.
7:44:51
jackdaniel
then you'll be able to say proudly at ELS: I'm here, because I've solved bunch of McCLIM problems
7:54:12
pjb
defvar and defparameter are top-level forms, you would never use them to set a variable. Use setf for that!
11:01:08
lisp_guest
i have a question about style. in this function (from yesterday) https://plaster.tymoon.eu/view/685#685
11:01:27
lisp_guest
this when bothers me a bit, because the usual way i would implement this is to have a check for the opposite and then just return early before proceeding
11:06:42
jackdaniel
I'm working on semaphores for BT (will try to merge it upstream if possible) – this is generic implementation (using cv): https://plaster.tymoon.eu/view/686#686 -- fallback for implementations which doesn't have semaphores
11:07:03
jackdaniel
I'd appreciate comment on this (for instance if I got it right) if someone have a slice of time
11:07:09
Shinmera
Especially since the return-from increases mental overhead by requiring the explicit function name, having an inverted check, and introducing an explicit control flow transfer.
11:08:26
Shinmera
jackdaniel: In fact, having a list is awful because it means you don't get a distinct type for the semaphore.
11:09:04
jackdaniel
because I would have to check somehow, if implementation has semaphores implemented "its way"
11:10:05
Shinmera
The implementation potentially providing its own semaphore object doesn't really change anything.
11:10:05
jackdaniel
there is bt:timeout type defined without such conditionalization, but SBCL with-timeout signals different condition – this is a source of many programmer errors
11:10:31
jackdaniel
I want to avoid such situation for semaphores, that programmer does check-type on bt:sempahore
11:10:32
Shinmera
jackdaniel: Make the struct named %foo and provide a deftype that aliases to the concrete type on each impl
11:11:25
Shinmera
I really don't think that any amount of implementation overhead is going to justify using a list
11:12:43
jackdaniel
I've explained initial motivation for such avoidance, I may reconsider (or change upon maintainer request)
11:13:55
loke
jackdaniel: if so, you could make it three-elemtn array instead? That'll make lookups fast.
11:17:29
Shinmera
His argument is that he would need to conditionalise the existence of the struct or type for each implementation if they provide their own native semaphore object type.
11:17:40
loke
Isn't his point that you shouldn't be able to do CHECK-TYPE (or whatever) on the object, becasue in specialised implementations the type of the object can be unpredictable?
11:18:26
Zhivago
It's rather then class can differ -- but CL has that leak back into the type for array, which sucks.
11:19:06
loke
That said, I'd like to see a custom type that is defined to be whatever the underlying impleemntation uses. That way I cal always use (CHECK-TYPE BT:SEMAPHORE) and it'll word regardless of implemnetation. Then a struct would be fine.
11:19:18
Shinmera
the solution is (defstruct %semaphore ..) (deftype semaphore #+sbcl 'sb-whatnot:whatever #-... '%semaphore)
11:20:04
jackdaniel
Shinmera: and where should I put this deftype, if implementation doesn't have native semaphore on %semaphore?
11:29:55
beach
lisp_guest: It is considered bad style to use WHEN in a situation where the value matters. It is better to use an IF and return NIL in the "else" branch.
11:30:30
lisp_guest
beach: so making explicit the fact that i want "nil" to be returned if sym is not a symbol?
11:36:41
Shinmera
beach: Sure. In this case one could argue that returning NIL on failure is an explicit property of WHEN so the return value of NIL is already explicit too.