Hello, lispers!

47 minutes till the 6th online-lisp-meet with:

⭐️Jan Moringen about the new McCLIM inspector
⭐️ Hayley Patton about Netfarm, a distributed trustless object system

All the details:
reddit.com/r/lisp/comments/i05

Thanks to @phoe for organising! 🎉​🦎​

@lisp @commonlisp

ioanna boosted

Earth has blue skies and red sunsets. Mars has red skies and blue sunsets.

The sky on Earth is blue because gas molecules reflect blue light. Earth sunsets look red because all the blue light has already been filtered out.

The sky on Mars is red because dust particles reflect red light. Martian sunsets look blue because all the red light has already been filtered out.

Two planets. Opposite skies.

ioanna boosted

Currently upgrading my GUIX System—-adding in a new hard drive, and getting the printer working!

It’s as simple as adding in a few lines into your /etc/config.scm!

Also it’s LISP configuration, so it’s beautiful to look at uwu

ioanna boosted

Playing with MCM/70 emulator from cs.yorku.ca/museum/collections

Just wondering how many people would like to watch a stream with someone taking baby stems in #APL on that amazing machine

@acw

ioanna boosted

Inner join now implemented in KAP

This means that I can now run Game of Life in my implementation:

∇ iter (x) { ↑1 x∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂x }
ioanna boosted

Next Tuesday at 13:00 CEST online-lisp-meets with

⭐️ Jan Moringen about the new and improved version of Clouseau, the McCLIM inspector facility
⭐️ Hayley Patton about ideas from developing the Netfarm distributed object system in common-lisp (concurrency)

links, titles, and abstracts: reddit.com/r/lisp/comments/i05

Thanks to @phoe for organising this wonderful series!
🥳

@lisp@gup.pe @commonlisp@gup.pe

ioanna boosted

comp.lang.lisp has been banned from Google Groups, reports lwn: Historical programming-language groups disappearing from Google lwn.net/Articles/827233/

@lisp@gup.pe

ioanna boosted

@enkiv2 I don't think so. The condition system has nothing to do with backtracking, I guess, aside from the fact that it can be used to implement an inefficient form of backtracking - see gist.github.com/nikodemus/b461

@technomancy @ioa

ioanna boosted

@ioa Seems like a lot of inertia. The throw-and-destroy-the-stack approach is prominent almost everywhere in the programming world.

I don't know much about Dylan, but Smalltalk and CL are image-based programming languages that simply bundle everything required to debug on the spot - the debugger, inspector, compiler et al. Some other languages don't have these facilities in the output binaries.

There'll be a free supplement to my upcoming book that touches this topic a little bit.

ioanna boosted

Showing why conditions are a bad match for doing backtracking -- all you need is CATCH/THROW and a special variable. · GitHub gist.github.com/nikodemus/b461

ioanna boosted

When writing software, I strive to write a series of extremely practical jokes

(cf. Alan Kay, _The Early History of Smalltalk_)

ioanna boosted

being a senior software engineer means being able to architect an entire end-to-end application in your head but having to Google how to check if a JS array contains an element because you can only remember how to do it in three other languages

Why don't more languages implement a condition system like common-lisp's, or dylan's, or smalltalk's?

Follow up question:
How essential is it to you to program in the debugger?

cc. @phoe

ioanna boosted

“Packaging #GTK Apps in #Guix”: talk & hands-on session today by Ryan Prior at #GUADEC:
events.gnome.org/event/12/

Join Track 2, starting at 7PM UTC (9PM CEST)!
meet.gnome.org/b/gua-ioj-c3s

ioanna boosted

"Why companies struggle with recalcitrant IT" economist.com/business/2020/07

"Airlines are […] now advised to turn the plane off and on again every 51 days, to stop its computers displaying false data in mid-flight."

Love our glorious computerized future

ioanna boosted

@phoe @lisp@gup.pe One interesting thing when reading comments from non-Lispers when they hear about how the condition system works.

In almost all cases, it boils down to some variation of "I can do that in X as well, just use facility Y to emulate it".

For some reason they are perfectly happy to apply this "because of Turing-completeness, all programming languages are equivalent" to this topic, while at the same time explain how superior some specific language is just because it allows you to type one word less than some other language.

ioanna boosted

@loke @lisp@gup.pe I've finally found good words for explaining this sort of approach. See my answer at news.ycombinator.com/item?id=2 - in particular, this part I've added in later:

The main issue that makes writing examples for this troublesome is the curse of knowledge. If I write that a condition system allows to recover from a type error, it's trivial to say, "just add a typecheck for that with a conversion routine"; if I write that a condition system allows you to recover from the format mismatch, it's trivial to say "but you can just stick an ifIsOldFormat(...) in the code to solve it". These solutions are no longer about exception handling; they are modifications to the standard control flow of the program. They aren't trying to fix the situation from outside; they are trying to fix the situation from the inside. And fixing it from inside isn't always viable or even possible at all.

While control flow deals with known knowns and known unknowns, exception handling is much more about situations where we deal with unknown unknowns: something explodes, we don't know what it is, none of our programmed recovery mechanisms have taken care of that situation, and we need means of gracefully recovering.

This is achieved first and foremost by allowing human intervention: the debugger is started, the stack information is preserved, so a programmer has all the information to try and debug the situation to let the program continue execution. Some of these fixes can then be easily added to code in by means of defining new programmatic condition handlers (hooks) and restarts (choices) in code.

ioanna boosted

@fnark @lisp@gup.pe Two reasons.

If one is a Lisp programmer, then it's fundamental to understand the functioning and use cases of the standard language facilities, such as the condition system in this case, in order to understand code written by other people and to know when and how to use the condition system in one's own code.

If one isn't a Lisp programmer, then I think it would be worth to give this book a read in order to understand an approach to handling exceptional (and not only exceptional) situations that does not require immediate stack unwinding on each erroring point in code, offers a possibility to dynamically add condition handling and recovery logic completely from outside a given program, and finally presents a combination of debugger-inspector-compiler built into the language to help fix issues on the spot in an interactive maner.

ioanna boosted
@phoe

> @ioa [1] @jakob [2] as
> @ioa [3] said, it's open, and online Lisp meetings
> happen regularly every two-three weeks. /r/lisp and the mailing list
> have updates about those.

I would like to thank all the people thet donates their time and
efforts to make this meetings possible and highlight the talks from
Robert Strandh about how to build a CL implementation:

part 1

https://www.youtube.com/watch?v=Wa81OJnlsoI

part 2

https://www.youtube.com/watch?v=KaUkiLVSObw

(and part 3 to come, i hope! :-) )

I found very interesting these talks because, in my opinion, not only
explain a lot of concept about a common lisp implementation's internal
(and some that CL developers faces often, like environments)
but address some concepts that are of more general interest in
computer science (virtual machine, functions stack etc.).

As i had not a formal CS education, I especially enjoyed these ones. :)

Bye!
C.

#lisp #compiler
Show more
Functional Café

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!