freenode/#lisp - IRC Chatlog
Search
5:03:44
aeth
beach: you aren't in #lispcafe so you didn't see the conversation, but can you elaborate on this? https://irclog.tymoon.eu/freenode/%23lisp?around=1598677456#1598677456
5:04:15
aeth
In particular "But maybe this minimalism trend is due tot he fact that their tools are so complex that they can't do otherwise. ... 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:20:43
beach
aeth: Today is Monday morning, and Monday mornings are chaotic around here. It may take some time.
5:22:26
beach
aeth: For the minimalist trend, I was just guessing. I don't know what is really going on.
5:23:39
beach
As for the last quote, The guy was just enumerating things that were surprising to him. He didn't have the words to express them necessarily, but one was what I call "uniform reference semantics". To him, it seemed like Python invented that idea, but Lisp had it in 1960.
5:25:07
beach
As for the "better" part, it is just about things that I repeat fairly frequently, namely that Common Lisp was designed by people who know about language design and compiler technology. Some quotations I have seen from the creator of Python seems to suggest that such knowledge is quite limited there.
5:27:38
aeth
beach: I guess it was almost more of a request for comment than a real conversation because we don't know what features you think Common Lisp has that other languages lack.
5:29:58
beach
Again, the guy was lamenting the complexity of C and C++ because they distinguish what he calls "values" from what he calls "pointers", and he seemed to think that Python invented what I call "uniform reference semantics".
5:30:43
beach
He was also talking about things like operator priority in C and C++, and claimed that Python has a much better solution. I claim that Lisp has had the best solution for 60 years.
5:32:07
beach
I wasn't so much comparing Common Lisp to other languages as I was comparing this person's idea about what Python supposedly invented, to what Lisp has had for a long time.
5:33:43
beach
Also, this guy seemed convinced that there must be a distinction between a general-purpose language and a scripting language. Again, he seemed totally ignorant of the fact that you can have the features of something like Python with the power of something like Common Lisp and the speed of a good Common Lisp implementation.
5:34:47
beach
I personally find it unacceptable to have people like that invited to a conference, or to have their papers accepted at one, if they are unaware of Common Lisp.
5:36:32
beach
I also don't see much mention of the main problem with this distinction between general-purpose and scripting, namely that it can be a nightmare to debug and maintain, especially if the semantics are different, and also the problem that users start writing complex code in the scripting language, thereby making the combination slower than if the entire applicatio had been written in Common Lisp.
5:38:14
beach
I am reminded of how a colleague of mine cleaned up the ICMC, the International Computer Music Conference, by taking on the chairmanship and rejecting all papers that didn't make a scientific argument. Maybe a Lisper should take on the chairmanship of a Python conference and do the same.
5:39:23
beach
I am saying that it is easier to maintain an application written in one language with sane and consistent semantics, than to maintain a mixture between a traditional static general-purpose language and a dynamic scripting language.
5:41:06
beach
But the guy was right that the semantics of C and C++, with the distinction between "values" and "pointers" is a horrible idea. And, as I often point out (and as Paul Wilson says), liveness is a global property, so if you don't have automatic memory management, you already either have a maintenance nightmare, or you have a slow application.
5:43:18
beach
I have explained the reason why several times. But basically, either you break the modularity so that you know what the module does with your objects (and you have a maintenance nightmare), or you copy objects, use smart pointers, or use reference counting (and you have a slow application).
5:46:29
beach
So, instead of taking a general-purpose dynamic language with sane semantics and good implementations, like Common Lisp, they combine a static language with horrible semantics that can't be made both fast and modular with a dynamic language with a slow implementation and totally different semantics. And they are proud of themselves, to the degree that they get to speak at conferences.
10:33:03
pve
so basically, anytime I use ensure-class I'm going to have to check that the symbol is not in CL?
10:34:57
phoe
in particular, (sb-mop:ensure-class 'let) should signal the same error that (defclass let () ()) does
13:32:56
pve
I wrote it down, hopefully I won't forget.. I don't think I've ever reported something to SBCL, so I need to familiarize myself with their process
14:31:35
Krystof
pve: either create a launchpad account and open a ticket there, or send mail to sbcl-bugs@lists.sourceforge.net (the list is moderated, so it might take a while for your mail to show up)
14:31:55
Krystof
(I'm not sure how an implementation defect shows that the concept of package locks is screwy)
14:33:35
beach
In my opinion, since it is not about locking a package, but about locking certain aspects of the environment, then if it were implemented like that, any attempt to define a class with that name would fail, no matter which other module made that attempt.
14:34:50
beach
(defmethod (setf clostrum:find-package) :before (client environment name) (when <name is a Common Lisp standard symbol> (error ...)))
14:37:42
Krystof
I think that the desire to keep packages safe from accidental name collision is more general, although I grant that modern style is to :use CL and nothing else
14:38:53
beach
(defmethod (setf clostrum:find-class) :before (client environment name) (when <name is a Common Lisp standard symbol> (error ...)))
14:38:59
Krystof
for me the use of package locks is to say that just because we are using CL, which has the symbol CAR in it, doesn't mean that we should be able to accidentally make a CL:CAR class that all other users of the CL package would be able to see
14:39:17
Krystof
and this generalizes to "just because we are using VEHICLES, which has the symbol BUS in it..."
14:40:08
Krystof
so it is in my mind about keeping the set of definitions accessible through collection-of-symbols (package) static
14:41:56
_death
that prevents them from making a cl:car class using CLOS, but not from making a cl:car class using MYOS ;)
14:42:28
Krystof
it's true that we don't have a good story for allowing new namespaces to be protected in the same way
14:43:33
Krystof
we do export PACKAGE-LOCKED-P so users can if they choose implement lock semantics for their defining / binding forms
14:45:30
beach
Krystof: If it is a package lock as you describe it, how come it is allowed to define lexical variables with the same names as in the package, but not lexical functions? Would that be the same for the vehicle/bus example?
14:46:15
Krystof
a lexical variable with the same name as a function in the package is allowed, because its effect is completely local
14:46:49
_death
Krystof: maybe it could have a purpose argument (and symbol-locked-p or even name-locked-p for more granular control)
14:46:53
Krystof
a lexical function with the same name as a function in the package is not allowed, because it might interfere in surprising ways with macros expanding to calls to that function
14:47:54
Krystof
similarly, a lexical function with the same name as a constant in the package is allowed, because it can't interfere in surprising ways
14:48:04
beach
Krystof: I know that to be the case for the Common Lisp package, but is it really that general a rule that it must apply to user-defined packages as well?
14:49:19
beach
That's an interesting point of view, since I am of the opinion that only the CL package should ever be :USEd.
14:49:21
Krystof
if you make sure that you don't break the rules, you can combine :USEd code arbitrarily
14:49:50
Krystof
right, we implemented package locks a while ago (2004? 2005?) when the style was to :USE more stuff than just CL
14:50:24
phoe
beach: unless you're writing code that, for whatever reason, provides its own package to be used over the CL package
14:50:50
phoe
for instance, Qtools does that to introduce its own SETF stuff that integrates with dynamically created Qt functions.
14:51:22
phoe
but that's an edge case of a framework that bends standard CL to some of its portable limits
14:52:01
jackdaniel
there is a question of a good style and a question of what the language allows; the language "doesn't care" what the programmer assumes to be a good style
14:55:59
_death
I guess in some settings it's possible to lose control of a package at some point, or lose track of the :use-ing package.. then the more conservative CL-only rule would make sense..
14:57:58
jackdaniel
I like the rule and use it myself (especially that we have package-local nicknames); the point being made is that imo language extensions (like package locks) should not have opinions about the style
15:00:31
phoe
package locks are completely style-agnostic though, all they do is protect symbols inside a pacakge from having their definitions changed
15:00:36
_death
if I qualify all non-CL symbols or make myself well aware that I import them, then package locks become less useful
15:00:53
jackdaniel
there was an interesting piece comparing clojure and cl about that "cl is an unopinionated language", but I don't remember where I've read it
15:01:13
phoe
it's purely accidental that :USEing packages makes it easier for people to accidentally define stuff on top of symbols that they don't really want to define them on.
15:01:18
scymtym
even when only CL is :USEd, bad things can happen easily in some cases. a problem i have seen in practice is multiple libraries defining (esrap:defrule string …)
15:02:51
scymtym
_death: sure, i'm just mentioning this case as an example of the extensibility requirement Krystof mentioned earlier
15:04:06
phoe
and the point that beach made earlier, that such a thing can be done on top of CL, is defeated easily by just one library deciding to *not* use package locks inside its DEFINE-FOO macros
15:04:56
phoe
and esrap adding package locks atop CL symbols would now likely break tons of code, too
15:07:52
phoe
jackdaniel: that would work in most cases, unless someone explicitly decides to go (esrap:defrule my-system.esrap-rules:foo ...) for whatever reason
15:12:43
phoe
stuffing (eval-when (:compile-toplevel :load-toplevel :execute) (warn "haha")) into phoe-toolbox.lisp and then (asdf:load-system :phoe-toolbox :force t) causes an error, but quickloading phoe-toolbox doesn't