freenode/#lisp - IRC Chatlog
Search
4:58:12
beach
Today, for my daily exercise, I watched the first half of a presentation by Brandon Rhodes, entitles "Python as C++'s limiting case", given at code::dive 2018. It reminded me of something I frequently repeat, namely "People spend a lot of time and energy to avoid learning Common Lisp."
4:58:59
beach
This presentation also reminded me of the sorry state of the fields of computing, programming, and software engineering.
5:01:40
aeth
The most disappointing part of modern software seems to be design. Every time there's a new update that changes the design, usability and feature discoverability go way down. Most recently, with Firefox for Android.
5:02:32
aeth
And any feature that telemetry shows is uncommonly used will eventually get removed, no matter how useful it is
5:04:16
beach
Well, I was mostly referring to the time and energy spent by the developers, project leaders, etc. But maybe this minimalism trend is due tot he fact that their tools are so complex that they can't do otherwise.
5:16:55
aeth
beach: Well, cutting features seems to be incredibly common these days, so perhaps the issue is maintaining software.
5:32:54
beach
That's part of what I was referring to. The hypothesis was that, in order to simplify their work (design, first-time development, maintenance), since their main tool (i.e., the programming language) makes their task so hard, they need to cut down on the features.
5:41:03
beach
What was so "interesting" about this presentation was that the speaker took features of C, C++, Perl, Awk, JavaScript, etc. and for each one stated why it was problematic. Then he pretended to design a new and improved scripting language that fixed the problem. It so happened that the fix was exactly what Python does.
5:41:05
beach
However, what he failed to mention was that Lisp had fixed these problems ages ago, and in a better way than Python does. Too bad that his fixes are going to result in a scripting language rather than a general-purpose programming language like Common Lisp.
5:43:52
beach
I mean, I think he failed to mention that, not as a deliberate omission, but by simple ignorance. Hence my analysis about the sorry state of the fields of computing.
5:48:45
ggole-
Actually C's scoping rules (for variables) are also fine, that's not really the part of C that is bad
5:50:08
aeth
C/C++ let you do a { /* foo */ } i.e. brackets with no preceding keyword, and it behaves not too unlike a LET
5:55:26
beach
aeth: I would not attribute popularizing scoping rules to Scheme. Pretty much every language invented in the spirit of Algo60 got it right. Like Simula, Pascal, etc.
6:02:28
beach
aeth: And, when I programmed in C, I considered local scope to be an important tool for limiting the portion of the code where variables are in scope. It is (or should be) an important tool for every developer in every language. But, again, ignorance strikes in the field of computing.
6:05:55
beach
I vividly recall teaching this tool to students in 1988, and I had to justify it by telling them about compiler design, because they were convinced that, if a variable were introduced inside a loop, then it somehow needed to be "created" for each iteration, thereby slowing down the code.
6:07:33
beach
And this necessity is part of the reason why I think every serious developer must know about compiler technology, computer architecture, and programming-language design.
6:09:32
beach
If they don't know about those things, they are going to make incorrect guesses, and the code is going to reflect those guesses in so many negative ways.
6:10:57
no-defun-allowed
My C++ lecturer told us that not having to zero initialise variables makes C++ programs faster than other languages. I suppose data flow analysis wasn't invented that long ago...
6:17:01
aeth
DISASSEMBLE does a good job attacking false assumptions of "if I put this variable here it'll slow down my code" since often you'll see absolutely no difference.
6:17:12
no-defun-allowed
That's probably about the time the people who wrote the programming curriculum for high schools here are stuck in.
6:17:58
no-defun-allowed
aeth: I demonstrated that to be false by writing two programs, one with `int foo = 0; foo = 3;` and one with `int foo = 3;` You only needed to use -O1 to convince GCC to remove the redundant initialization.
6:19:35
no-defun-allowed
Yeah, arrays and objects are where that is less obviously true, but from memory, allocating arrays of objects on the stack would still call the default constructor in C++.
6:19:58
MichaelRaskin
Then in many cases asking for an array of size where this matters might include getting more pages from OS, which come pre-zeroed for security reasons
6:21:51
no-defun-allowed
I hear the curriculum plan that started this year is less FUBAR, fortunately.
6:23:46
no-defun-allowed
Or was that the textbook? I remember the teacher and I looked at the draft of something to do with this year's curriculum and we were both very relieved to read it.
6:25:47
no-defun-allowed
(Either way, that's not my problem now, but 1972 is about where it is. You can stick data together with records and one-dimensional arrays, and if you go to a good school, you even get some objects.)
6:28:59
no-defun-allowed
Anyways, what's the most straightforward way to define a method that has a specializer that's only available when the defining form is evaluated? Something like (let ((value ...)) (defmethod foo ((bar <value goes here>)) ...))
6:29:46
no-defun-allowed
ENSURE-METHOD doesn't know anything about the lexical environment, which is less than ideal. Do I go about reimplementing that?
6:34:44
no-defun-allowed
Er, but then you can't compile the lambda form in the appropriate lexical environment. /me sighs and sticks to EVAL.
6:35:45
beach
no-defun-allowed: Normally, the method function should be evaluated in the scope of the DEFMETHOD form.
6:38:29
no-defun-allowed
I've never really messed with specializers, but can I do (let ((x ...)) (defmethod foo ((bar (eql x))) ...))? CLHS on DEFMETHOD suggests I can.
6:38:38
beach
aeth: That's right, and I often repeat that fact. Affirmations like that, when examined, really turn out to mean only "every object is an object".
6:41:00
aeth
I can't deny that a comment is not an object. Does this mean that "everything is an object", which is very frequently published, is false?
6:41:49
MichaelRaskin
A comment doesn't even exist from code point of view, though. In the AST where comment is representable, the comment is typically represented by an object
6:43:05
beach
aeth: It is described by a type specifier, but that type specifier is not the type. But it doesn't matter. I have already found two counterexamples.
6:45:05
MichaelRaskin
It's arguable how different is from saying a physical neutron is not a Common Lisp object
6:45:58
beach
MichaelRaskin: "neutron" is not mentioned in the Common Lisp standard, or at least not in the normative part.
6:47:51
MichaelRaskin
I am pretty sure «everything is an object» is limited to «everything fully representable»
6:48:41
aeth
everything "first class", perhaps, but there might be some things that aren't "first class" that are objects
6:50:41
no-defun-allowed
What do you think of the return value of BYTE? That's an object, but one of implementation-dependent representation, which frequently borrows some other type.
6:52:27
no-defun-allowed
I guess I just stated that it's an object. Oh well. Would be nice if it wasn't frequently a cons or an integer or something that didn't really tell you if it is in fact a byte specifier.
6:56:48
ldbeth
you can try to describe everything as an abstract object specified by their behavior though
6:57:26
markasoftware
if i want to support declarations in the `body` of my macro, is there a better alternative to wrapping it in an unnecessary `(let () ,@body)` ?
6:57:45
markasoftware
if the immediately surrounding form otherwise is not one that supports declarations (in this case, progn)
7:03:16
MichaelRaskin
Everything assignable to a variable, sure, but _that_ clarification is _really_ not news to me
7:04:16
White_Flame
I think that places & types are probably the most interesting, directly representable, non-objects
7:05:16
MichaelRaskin
In-model and external-view notions being different is a distinction too trivial to discuss
7:05:20
White_Flame
right, there's a direct source code representation which implies the thing, but is not the thing
7:21:08
aeth
beach: should that be the concise response next time someone says "everything is an object"?
7:22:00
beach
I basically already responded that. From the vocabulary: "object n. 1. any Lisp datum.", so we have now reached "every object is an object".
7:24:14
MichaelRaskin
Note that «everything one can assign to a variable is an object in Common Lisp OOP system» is the same claim and holds even without lisp isolationism
8:22:53
no-defun-allowed
Today I was greeted by "The value #<unbound> is not of type FIXNUM" in my test suite.
9:06:02
edgar-rft
Re: CLHS Glossary "object n. 1. any Lisp datum." - The Oxford Dictionary defines "datum" as "fact or piece of information" what means that Lisp objects are not restricted to Lisp data types.