libera/#lisp - IRC Chatlog

14:56:48 kiliro74 ** NICK kiliro0

14:59:32 kiliro36 ** NICK kiliro

19:07:28 wasamasa have you considered to just learn bits and pieces of the language as you work on a project?

19:07:53 wasamasa if you want a language to be simple enough to be comprehended by going through its manual, you end up with something like lua or python

19:08:34 wasamasa and even then the bunch of advanced concept will be very nebulous until you spent serious time trying to use them

19:24:25 kiliro thank you for your comment, wasamasa

19:24:53 kiliro It sounds reasonable.  I will follow your suggestion.

19:25:19 wasamasa the practical common lisp book does follow a moderately complex project exercising most parts of the language

19:25:24 kiliro Sometimes, I feel insecure and just some comment is good enough to go on.

19:25:38 kiliro Most of the time I follow suggestions.

19:26:13 kiliro But motivation is necessary

19:26:28 wasamasa but with projects, it's most important that the topic motivates the student, so highly dependent on the person what topic that would be

19:26:48 kiliro yes

19:27:49 kiliro you mean this book, wasamasa? https://gigamonkeys.com/book/

19:27:54 wasamasa yes

19:30:03 kchanqvq wasamasa: did u teach common lisp?

19:30:35 wasamasa no, I teach people pentesting :)

19:34:25 kiliro wasamasa:  (cause_laughing "Does pentesting require white papers?")

19:34:59 kiliro I guess I should have defined the function first!

19:37:39 kiliro (defun cause_laughing commentary (interactive) "Surprizes the peer with something happily unexpected." (msg %s%))

19:37:50 kiliro does that sound correct?

19:40:05 kiliro I guess my grammar is wrong

19:41:02 kiliro and my algorithm seems superficial, instead of specific

19:41:32 kiliro plus I bet I have a lot of typos

19:44:06 kiliro (defun cause_laughing (commentary) "Surprizes the peer with something happily unexpected." (interactive) (msg %s))

19:56:29 jcowan kiliro: the fact that PRINT prints something is a side effect, but it is what you want.

19:57:45 jcowan wasamasa: I just spent *hours* wrestling with a Python issue: Python is no Lua.

19:59:09 Lord_of_Life_ ** NICK Lord_of_Life

19:59:43 wasamasa given the hours saved by existing libraries, still quite the win overall

20:00:32 jcowan Oh yes, although in this project I don't expect to use any (except stdlib)

20:01:14 jcowan https://gist.github.com/johnwcowan/98f5b500759a72863c1b103db9f6d0ef shows the problem,

20:01:41 jcowan and the answer turns out to be that when you run a module from the shell, its name is __main__, not the name of whatever file you are running.

20:05:02 wasamasa pretty sure if I were to apply that to 7 schemes, I'd get 3 different answers

20:05:11 wasamasa and 2 not-working ones

20:36:12 kiliro Did you receive my message regarding Common LisP's flexibility?

20:36:56 kiliro I can see the message in the webchat

20:37:12 kiliro but I am not sure if it reached the other users

20:43:57 kiliro Did you receive my message regarding Common LisP's flexibility?

20:44:02 kiliro I can see the message in the webchat

20:44:06 kiliro but I am not sure if it reached the other users

20:44:26 kiliro besides me

20:46:10 kiliro I will repeat it.

20:46:15 kiliro Does this still hold true in 2026?  "Common Lisp sports as fine an array of modern data types as you can ask for: a condition system that, as you'll see in Chapter 19, provides a whole level of flexibility missing from the exception systems of languages such as Java, Python, and C++; powerful facilities for doing object-oriented programming; and

20:46:15 kiliro several language facilities that just don't exist in other programming languages."

21:09:06 jcowan Yes. In the case of the condition system, the C++ community (mostly Stroustrup personally) rejected it, so C++ exceptions are much weaker than CLs

21:23:47 aeth The general trend in languages is towards less flexibility. See e.g. the decline of Perl, the failure of Perl 6 (now Raku) to find an audience, the popularity of languages such as Haskell and (especially) Rust, etc.

21:27:07 jcowan Yes. That's a defense against the danger of good programmers to their employers, namely that they become less replaceable.

21:27:31 jcowan It's a kind of deskilling.

21:31:22 aeth Well, my particular chosen examples of Haskell and Rust aren't deskilling (except when they're advertised as having LLM-friendly type systems so you can take a more hands-off approach) as opposed to some languages (Java, Go) that do seem more directly designed at deskilling

21:31:45 aeth But what they do represent is being restrictive relative to their competition.

21:32:09 jcowan +1 on all points

21:32:14 aeth Haskell kind of comes at it from two sides, being statically typed, but also not having a more flexible static type system like e.g. the dependently typed ones.

21:32:49 aeth So you can see it as more restrictive than Scheme, or more restrictive than the four or so dependently typed competitors of which there is no real one clear leader.

21:35:12 aeth Meaning that there are things easily expressible either with dynamic types or with a more powerful type system.

22:55:21 jcowan Which depends on whether you think of static types as powerful, or a powerful restriction.

22:56:27 aeth Yes, everything is a tradeoff and a more powerful type system prevents you from doing things. This is why subtypes have fallen out of favor.