freenode/#clim - IRC Chatlog
Search
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
13:10:11
jackdaniel
at least part of the problem comes from the fact, that when we change mirror geometry Xserver generates configuration event which change this geometry again
13:14:26
fittestbits1
presentation-replace-input builds a file name string using directory-namestring and file-namestring so no host name.
13:14:35
nyef
jackdaniel: Note that in the case of substructure redirection, you can change mirror geometry and then get DIFFERENT geometry back.
13:15:31
fittestbits1
OK - take a look at the log. There's definitely a problem, but I'm not sure how to fix it.
13:16:06
nyef
And there's also the bit where you get "real" and "synthetic" geometry notifications, one of which accounts for the frame ("window decorations") and one which doesn't.
13:17:28
jackdaniel
fittestbits1: isn't it possible to always include host name in completion? modifying presentation-replace-input that is
13:17:31
fittestbits1
Right, but the I think the problem is that the insert text code of mcclim generates a different text string than the completion code uses for matching.
13:18:15
jackdaniel
I don't know these parts of system well so not sure what is the right thing (and my head is still wrapped around mirrors)
13:18:31
jackdaniel
btw, there will be some changes with mirroring code (head-ups regarding mezzano port)
13:18:34
fittestbits1
Yeah, modifiying presentation-replace-input seems right, but someone went to a lot of work to avoid just using namestring and I don't know why.
13:19:03
jackdaniel
fittestbits1: I would just ignore the "I don't know why" part if it is not obviosu after hour-or-so investigation
13:19:48
jackdaniel
at one session I was able to remove ~700 lines of code without changing *any* functionality
13:20:08
jackdaniel
but that was after confirming, that part of the functions is not: a) exported, b) not used anywhere
13:20:56
jackdaniel
or that they can't be called (because some condition always resolves to one of branches) - stuff like that
13:21:10
fittestbits1
Cool. I wish my changes would go as smoothly. I put in some performance changes that I though made no difference for functionality, but running through the examples showed some differences.
13:22:44
jackdaniel
I had weird issue yesterday – after changing name of two slots (just a name!) and all with-slots or slot-value or package imports everything worked fine – except the performance which dropped drastically in case of ellipsis bounding regions
13:24:33
jackdaniel
I've started with post about ports, then I've moved into simplistic-gadgets what led me to layout protocol and now mirrors
13:24:35
fittestbits1
I'm still making forward progress on the mezzano port. Performance seems a lot better, I think because of a logging change.
13:26:46
fittestbits1
It worked OK when creating windows with empty FIFOs just printed a bunch of zeros. But with mcclim using a shared FIFO, it printed out a bunch of event objects which generated a lot of text plus the processing to generate the text.
13:28:42
fittestbits1
I think reading the font files lots of times stops when all of the characters get cached. So, that's more of a startup issue than an on going issue.
14:16:53
jackdaniel
“To keep large problems well structured, you either need superhuman will power or proper language support for interfaces.” - Greg Nelson
14:24:02
nyef
... What constitutes "proper" language support for interfaces here? I sense a "no true Scotsman" fallacy.
14:25:56
jackdaniel
I can't tell what was the quote author idea, but I understand it as a limitation on how objects interact with each other
14:26:40
jackdaniel
example of implementation of such idea is "never use slots directly" principle – using only a protocol for accessing objects
14:27:19
jackdaniel
this contract assures, that you won't hit "gotcha", because some :after method didn't get executed
14:28:54
jackdaniel
if there weren't convenient way to define accessors in CL, then each library would have to come up with its own idea how to access object innards
14:29:39
jackdaniel
what would lead to raised cognitive effort when working with libraries (different ways of doing the same thing) and introduced unnecessary mess
14:32:50
nyef
So, I see five potential lines of argument here, centered around the Linux kernel... 1. Does C have "proper" language support for interfaces? 2. Is the Linux kernel not "well structured"? 3. Do the kernel developers have "superhuman" will power? 4. Is the Linux kernel not dealing with a large problem? Or 5. Is the Linux kernel an existence proof for a counterargument?
14:34:02
jackdaniel
I would argue if it is well structured, but it is also a fact that it has strong leadership
14:34:30
jackdaniel
also bear in mind, that "quotes' carry only limited amount of truth (like general direction), so they are not claims per se
14:34:50
nyef
Yes. I would argue that "superhuman" will power is attainable, provided that you involve more than just one human.
14:36:13
nyef
I would further argue that /this is the most useful line of inquiry/, and that the follow-on question is "how might superhuman will power be replicated on a smaller scale?"
14:37:31
nyef
And that this is not a "technical" problem as such. (Well, it IS, but it's a social-technology thing, not a computer-technology thing.)
14:38:15
jackdaniel
if technology makes things easier, then having this computer technology as your aim influences greatly the overal result
14:39:15
jackdaniel
also attaining superhuman will power sounds like a lot of a hassle, so having language support which deems it unnecessary is something desireable
14:41:42
nyef
Mmm. Will power is a finite resource. Renewable, yes, but you can only have so much of it at a time. The less you need to use it, the more of it you have to use for important things.