freenode/lisp - IRC Chatlog
Search
5:48:17
moon-child
(though that may not be the best example since there are definite improvements to alphabetic writing systesm systems over syllabaries and logographies)
5:48:20
beach
ey[m]: People like what they are familiar with, and since Lisp is not often taught in teaching programs, it is unfamiliar, and thus, people don't like it.
6:10:08
edgar-rft
What do I think of those who say that lisp is hard to read ? I do think that there is also no language that is soft to read. Stupid statements need stupid answers.
6:25:11
beach
edgar-rft: I am sure ey[m] had a purpose with the question. But we still don't know what it is.
6:25:37
beach
Maybe we should come up with arguments against the statement to be used on those other people who think Lisp is hard to read?
6:28:42
ey[m]
beach: I was watching an old python conf video and the presenter said he left lisp for python because he felt python's syntax was much clearer.
6:32:15
beach
In the past, I have seen or read about other people who decide to change from Lisp to something else, and they almost always give some excuse that suggests that there is something wrong with Lisp.
6:32:15
beach
Often they accuse the "community" of not doing anything about these perceived problems. But in fact, it is just a personal preference that made them change, and they are trying to protect themselves from criticism concerning their decision.
6:33:27
ludston
It's more intuitive, given than most of us grow up rote-learning euclidean geometry, so it uses more of our pre-learned framework
6:34:51
beach
And, the fact that Lisp is not often taught in CS or SE teaching programs then reinforces the familiarity with this notation.
6:34:51
pranavats
That could depend on your background. For someone used to mathematical syntax that equals sign could be confusing.
6:36:06
ludston
pranavates: Interesting that you mentioned that, because I saw the results of a test for first-time programmers and that did indeed happen
6:42:40
beach
So, anyway, I don't think there is anything that can be done about the people who claim that Lisp is hard to read.
6:43:47
pranavats
I have heard more convincing claims about comprehension being affected by the syntax, after one has gotten familar with the syntax. Though that is about APL, and tendency of APL programmers to rely on recognizable idioms, instead of just creating new layers of abstraction.
6:44:06
plisp
more relevant to the topic: the couple programmers I talked to were fairly quick to accept indentation-based reading. Almost as quickly as they brought up parentheses
6:48:09
pranavats
I mean comprehension of programs, not the language. Following from that, embedded DSLs can make the job of reading a program a bit of a task; needing to jump from one layer of abstraction to the other frequently, depending on the way the program is written, of course.
6:49:54
ludston
Personally, I think that the worst thing we lisp programmers do is teaching car and cdr before make-array
6:52:04
ludston
The power of lisp over other languages, in my opinion, is that you can manipulate cons cells to generate code dynamically
6:53:23
ludston
And singly linked lists are a terrible data structure for beginner programmers, because writing algorithms to manipulate singly-linked lists can be very fiddly
6:56:06
ludston
Because of this, I think it is better to gain fluency using lisp data-structures like array, and hashtable, because, if you want to write fast lisp code, you will be using these data-structures most of the time
6:56:55
python476
I always feel that perf is better added onto a good overall design and problem space mapping
6:57:12
ludston
And then, mastering list manipulation later, for the sake of writing macro's, is a good approach
6:58:22
ludston
I think that teaching '(), car and cdr first encourages programmers to first try and model their problems in the singly-linked list space, but singly-linked lists are very often a poor abstraction for many algorithms
7:00:21
ludston
pranavats: For example, try writing the quick-sort algorithm using singly-linked lists
7:03:21
python476
but it's very important to make new devs see how the language can impact your coding
7:06:51
ludston
pranavats: If somone was looking over your shoulder, like, "No don't do it like that, just use make-array" you'd have had a much better time, see?
7:09:11
ludston
My experience with common lisp, was that I learned it in my first year of university, because someone else said it was cool. The first book I picked up was Land of Lisp, which taught me a pile of bad habits that I had to unlearn, and then it was not until after I'd done some datastructures and algorithms courses and coming back to lisp was like, "Wow this language is so much better than C#"
7:10:50
beach
You choose the first element as a pivot. Then partition the rest of the list according to that pivot. Recursively sort the partitions. Append the results. Done.
7:15:25
beach
python476: I wasn't arguing about the value of using a list. I was reacting to ludston thinking it was hard to implement.
7:17:07
ludston
beach: Unfortunately, choosing the left-most cell as the partition gets the worst possible performance on an already sorted list
7:17:08
python476
yeah I'm from a recent times where immutable ds / lists influenced me more than CL ways
7:20:16
ludston
beach: The reason I don't agree with you is that I'm looking at a stackoverflow question about this, and none of the answers do it in place https://stackoverflow.com/questions/19082032/quicksort-in-lisp
7:21:05
ludston
beach: It is, in the very least, less trivial to implement quicksort over a list vs over an array
7:21:46
beach
ludston: I strongly disagree. For an array, it gets tricky to avoid an infinite recursion.
7:22:23
ludston
Which is irrelevant to the power of lisp, which supports arrays just as easily as lists, but relevant to which to teach first
7:22:31
beach
You have to be very careful with excluding the pivot and putting it back in the right place.
7:23:40
pranavats
Btw, I didn't use any imperative code when I tried implementing quick sort in Lisp.
7:29:57
ludston
pranavats: You also cannot write a functional algorithm that doesn't have O(n) allocation, by definition, given that you aren't allowed to modify the source list
7:46:05
pyc
Ah! I see one does not add a newline and the other one does while printing the string but they both seem to return the same string.
7:48:58
ludston
pyc: Easy to test the difference with (let ((s (make-new-output-stream))) (write-string "blah" s) (get-output-stream-string s))
11:44:12
pyc
Is there any best practice guidelines for write-line vs. format? Is format to be avoided when write-line would suffice?
11:45:37
pyc
I see all tutorials and PCL book use format even while printing simple strings. Makes me wonder why write-line is ignored. For simple strings, the code looks neater with write-line.
11:46:43
phoe
for me it's (format t "...~%") or (format t "~A~%" variable-string); possibly superfluous, but I never really felt the need to use write-line
11:47:30
pyc
phoe: thanks. that is what I wanted to know. for single characters, I guess you use write-char (still not write-line), am I right?
12:01:57
pyc
Xach: thanks! Incidentally, I was looking for write-line on the web and I came across your code. I agree I like (write-line line) to be cleaner than (format t "~A~%" line).
13:50:56
ralt
_death: are you still maintaining dbus? I've been playing with it again this week, and the main issue I have with it is the error reporting. For example, an invalid list of parameters returns an EOF error
13:53:35
ralt
Because the introspection is runtime but the classes and their slots are defined at compile time :/
15:28:19
_death
ralt: sure, I can review and accept patches.. not using it nowadays so there are no changes coming from me
15:38:43
_death
ralt: I guess one way to make a lispy interface would be to write something that generates stub code from an interface and dump it to a file.. then your code could depend on that stub (harnessing asdf) and the names it exports