freenode/#clim - IRC Chatlog
Search
7:58:11
bjorkintosh
good lord beach. you have a small essay on perfection vs performance orientation.
7:58:49
bjorkintosh
well, you didn't say anything yesterday! it's a good essay. a light bulb has gone off in my head as a result.
8:00:25
bjorkintosh
no. thank you. I simply didn't know there was a name for the concepts in question.
8:02:27
bjorkintosh
ecraven, http://metamodular.com/Essays/psychology.html this is in relation to a little thing that came up about student attitudes yesterday.
8:03:23
bjorkintosh
it's short and sweet. beach you should definitely include that information at the end of the essay, you know for the perfection oriented!
8:04:03
bjorkintosh
so which marvelous feature did you discover, and which programming language was it beach?
8:04:50
bjorkintosh
"The people in the category perfection-oriented have a natural intellectual curiosity. They are constantly searching for better ways of doing things, new methods, new tools. They search for perfection, but they take pleasure in the search itself, knowing perfectly well that perfection can not be accomplished. To the people in this category, failure is a normal part of the strive for perfection. In fact, failure gives a deeper
8:04:50
bjorkintosh
understanding of why a particular path was unsuccessful, making it possible to avoid similar paths in the future."
8:05:32
jackdaniel
beach: did you think about specialized editor in which you can annotate the code? not only with comments, but also with drawings and possibly other media
8:05:58
jackdaniel
that would require a specialized editor which doesn't work directly on a text file
8:07:31
beach
jackdaniel: My main objective at the moment is to have an unbeatable tool for editing Common Lisp code.
8:08:02
jackdaniel
beach: I'm aware of it, just thought you might have had idea about it in the past
8:08:41
beach
I did have ideas about how to connect program text to external information such as documentation.
8:10:21
jackdaniel
bjorkintosh: I've skimmed quick description now - how is it related to annotating code in the editor?
8:10:42
beach
I think that is very different from what I have in mind. Knuths work was meant to allow the rigid order of Pascal code to be modified so that it would follow the thinking of the developer instead.
9:02:44
bjorkintosh
it's the fundamental idea behind it isn't it? that the thought process and the program need not be so divorced.
9:03:25
bjorkintosh
loke, it's true. 'computer science' and 'software engineering' remain misnomers. it is early days yet for the field.
9:03:34
loke
And I've recently been reading the TeX document (i.e. the book that comes out of the TeX source code)
9:05:06
bjorkintosh
oh? you want to read about structural analysis and the design process for such things?
9:07:56
jackdaniel
I think there is a difference between something you read because you want to know how it works (no need for thought process)
9:08:32
jackdaniel
and something you read to modify later (knowing thought process allows avoiding problems which were already solved - you know for instance why this and this passage is *so* ugly)
9:09:21
loke
“Each noad is four or more words long. The first word contains the type and subtype and link fields that are already so familiar to us; the second, third, and fourth words are called the noad’s nucleus , subscr , and supscr fields. Consider, for example, the simple formula ‘$x^2$’, which would be parsed into an mlist containing a single element called an ord noad . The nucleus of this noad is a representation of ‘x’, the subscr is
9:09:21
loke
empty, and the supscr is a representation of ‘2’. The nucleus , subscr , and supscr fields are further broken into subfields. If p points to a noad, and if q is one of its principal fields (e.g., q = subscr (p)), there are several possibilities for the subfields, depending on the math type of q.”
9:11:32
bjorkintosh
it's a technical document. he talks about the design process in two other books.
9:14:09
bjorkintosh
loke 'digital typography' and 'literate programming' are the counterparts to the tex book and the tex program.
9:15:57
beach
Knuth is a great theoretician, but he is not a great programmer and not a great software engineer. TeX is very useful, but the design is a disaster. It only caught on because there was nothing else, and his colleague theoreticians (still) firmly believe that everything he touches is the greatest thing since sliced bread.
9:17:40
loke
The reason that tex.tex is such a pain to read is because it doesn't have any abstractions. That's why my quote contains such low level stuff, which is a qupte from page 250(!), half way through the document.
9:18:42
beach
https://www.lrde.epita.fr/~didier/research/publications/papers/verna.12.tug.slides.pdf
9:19:15
loke
“The page builder has another data structure to keep track of insertions. This is a list of four-
9:19:15
loke
word nodes, starting and ending at page ins head . That is, the first element of the list is node r 1 =
9:19:15
loke
link (page ins head ); node r j is followed by r j+1 = link (r j ); and if there are n items we have r n+1 =
9:19:18
loke
page ins head . The subtype field of each node in this list refers to an insertion number; for example,
9:19:21
loke
‘\insert 250’ would correspond to a node whose subtype is qi (250) (the same as the subtype field of the
9:19:24
loke
relevant ins node ). These subtype fields are in increasing order, and subtype (page ins head ) = qi (255), so
9:19:29
loke
page ins head serves as a convenient sentinel at the end of the list. A record is present for each insertion
9:21:08
beach
After watching those talks by Alan Kay, I am now even more convinced than ever before that there is a lot to gain by replacing the use of lower-level languages like C, C++, in this case Pascal/Web, and even Java and C# by Common Lisp.
9:21:48
bjorkintosh
beach and why not? if 30 years ago, entire OSes could be written on the metal in common lisp...
9:22:34
beach
I am convinced that a lot of the difference between accidental complexity and intrinsic complexity is a lot less when Common Lisp is used than when many other languages are used.
9:22:45
loke
bjorkintosh: Because although computers have imporved, the incorrect beliefs of the average programmer has not. Hence the people who believe that Ruse is the future.
9:23:57
jackdaniel
if I had all the time in the world I'd replace them with something a bit nicer than CL (truth to be told, it has some ugly corners and lacks in some capabilities), but that language would be indeed very similar to Common Lisp
9:25:35
beach
jackdaniel: Reader macros are not a problem. I can still parse Common Lisp code in Second Climacs.
9:25:50
jackdaniel
jack_rabbit: I don't know, I'm not language designer. That's why I've said: if I had all the time in a world
9:27:01
jack_rabbit
I wish some of the cl functions were generic. It would be handy, for instance, to be able to define car and cdr, etc. on list-like objects.
9:27:35
jackdaniel
beach: without executing reader macros you may miss important bits, but with executing them, well - it's not really parsing anymore, is it? but even if it were – claim that parsing CL is hard is fact, and I'd expect better from sexp-based syntax
9:28:19
jackdaniel
jack_rabbit: car/cdr are cons accessors. for generic sequences you have, hm, extensible sequences extension (in SBCL and ABCL currenty afair)
9:30:42
jackdaniel
beach: I won't argue with that, but do you also claim that parsing CL is easy for average lisp programmer?
9:30:43
jack_rabbit
Lists were just an example though. I can remember wanting to extend other built-ins, although I can't remember presently.
9:31:49
jackdaniel
either way, I'm not interested in rewriting CL (even if it weren't way above my skills)
9:32:18
beach
jackdaniel: I would think so, but I don't know where you are going with that question. Most Common Lisp code does not use custom reader macros. And I don't buy the idea that we should design languages for "average" programmers.
9:33:06
jackdaniel
I've said "average lisp programmer", so I had something slightly different in mind
9:33:06
beach
Or, rather, there might be a place for such languages, but I am using Common Lisp precisely because it was NOT designed for average programmers.
9:35:02
beach
I like the parallel with the violin. Nobody complains that a violin takes decades to master, and there is no movement to get rid of violins in favor of an instrument that can be played by musicians with a two-year university degree.
9:38:57
jackdaniel
I think my point is: CL isn't the finishing line of language evolution. Taking this analogy I'd say: fine, but nobody says we should replace a saxophone with a violine everywhere (regarding the very beggining of this discussion)
9:39:00
beach
Well, there is this tendency in software development to accuse people of "elitism" if they require some significant qualifications by people who write programs. It is interesting to me that no such accusations are heard when it comes to heart surgeons, airline pilots, violinists, etc.
9:39:54
beach
jackdaniel: Oh, I agree. However, I don't consider myself smart enough to start from scratch, especially not on my own. So I am happy trying to provide libraries for the improvements I find I need.
9:41:25
bjorkintosh
there's a stronger analogy with writing. no one ever accuses writers of elitism because even though anyone could potentially do it, it is VERY hard to do well.
9:41:33
beach
bjorkintosh: But many people who have the few 100 € to buy a computer then think that this is ALL it takes to be a programmer.
9:50:30
loke
beach: I think you made a typo in the following changelist: 219230e607b24c4a6b1c18ef72d5a08b1786a3de
10:15:15
beach
loke: I am afraid you are going to have to wade through a lot of obsolete code at this point, simply because I haven't taken the time to clean it out and/or document it as such.
10:23:37
loke
beach: So where can I find the actual command definitions? If I want to find th ecommand for, say, next-line?
10:37:26
jackdaniel
I still hold dear the idea of having SLIM library bundled with CLIM which "shrinks" it a little