MZan @mzan@qoto.org

@SteelFolk @freemo

@freemo proposed the Neanderthal approach 🙂

I'm joking on this, because an apparently simple question about who can enter a female bathroom or not, in practice has no a real answer. It is nearly impossible to find a rule able to take in considerations all border-lines cases. You can partition the binary cases, but when you approach the border-line, the binary gender became a multi-factor, open-set of values. You can discuss forever.

I will end with a provocation: because there are no discussions about who can enter the male bathroom? :-)

@SteelFolk @freemo

> "what would the Nazis have done?"

Bingo! We are in democracy. Every bathroom needs an entrance podium. After a short public speaking where you introduce yourself, the others inside the bathroom can vote and decide if you can use the bathroom. :-)

@freemo a man dressed and acting like a woman, also if "suspecting masculine", his for sure more embarassing and awkward in a man bathroom. So I vote for "appearance" wins over "genitalia".

But, this is a purely binary related problem: if you go to the bathroom alone you are a man, if you go with your friend, you are a woman. :-)

@freemo I'm using it. From a technical point of view, it seems to me a very robust technology, but from a philosophical point of view, if you are serious at DevOps, probably there are better solutions.

If you have some legacy service that had to run inside a normal Linux distribution, then LXD allows to create a guest distro that is very light, because behind the hood it runs as a Linux container of the host distro. So you have a very cheap distro to use for: testing porpouses; local and disposable environments to give to students; legacy services administered in the old way.

Obviously if a service is important and it requires some resources, it is better to install on a distinct VM, instead of using LXD.

A modern DevOp environment, built from scratch, I doubt that it should follow the LXD approach. It is mainly for services that for some reasons are managed in the old way, and it does not make sense to host on distinct VMs. So a very narrow use case.

@rml at best of my (limited) knowledge, I think that after some time you understand if you prefer Scheme or CL. CL is a little more on the "hacking side", while Scheme is a little more on the computer-science/elegant side.

The most advanced thing I tried with Racket is some code using the Nanopass compilation framework. I were impressed. Also Typed Racket is very good and readable.

But for some inexplicable reason, I feel more productive and happy using CL. It is less elegant, but it is so much powerful and production-oriented.

So, I will not read your book, because time is limited and I had yet dedicated some time to Scheme.

@rml regarding `nil`: in CL it stays for the empty list and for the false value. There is no false value in CL. There is no true value in CL. Everything that is not `nil` is considered a true value.

To be sincere, it is an hack respect the elegance of Haskell algebraic approach. But, it is a convention that fits very well in the CL code and its usual semantic. For example `(or (car some-list) 0)` return the first non-nil value. It seems an hack like 0 and 1 that in C is false and true, but instead it allows to write very composable code. So it is a powerful and elegant hack.

On all other points, or I agree with you, or I trust you, because you seems more knowledgeable than me.

@rml regarding exception handling, the correct name is "Condition System". It is an approach more similar to Erlang, where you have common code for intercepting and managing certain classes of errors in an uniform way.

I didn't understood if the limitation about Coalton are regarding run-time errors, or compile-time errors. The condition system is only about management of run-time errors or run-time exceptional conditions.

It can be used also for implementing effects, when it is sufficient a manipulation of the stack. Otherwise Scheme continuations are more powerful.

@rml I'm not an expert of CL, and I only played some weeks with Racket. So I'm not an expert of Scheme too.

BTW, my 2cents are that regarding CLOS, it is very complete and it is a standard of CL. So there are a lot of CL libraries using it, and it is fully integrated in the development experience.

If your OOP code is slow, you can optimize the way objects are managed, and slots are stored in RAM, using MOP. For example with MOP you can store the coordinates of point objects in a compact array (i.e. row-store), despite you access them like normal objects.

@Romaq @freemo many thanks: as a true procrastinator, I postponed the reading of these important toots about procrastination and I started instead to work! Someday I will read them, promised!

@rml CLOS and MOP are better respect many Scheme OOP libraries.

Generic functions are used also in contexts different from OOP.

CL macros are easier to write.

The error and exception handling of CL is very powerful and useful.

But the real answers for me are these:

1) CL live coding (i.e. interactive REPL) is very fun and addictive

2) there are many CL compilers with different characteristics at run-time accepting the same CL code, and that you are sure that you can use in production. For example with ECL you can produce C-friendly libraries.

3) a minor detail, but I like the fact that "nil" stays for false, and every other value for "true". The code become shorter.

@publicvoit if you speak about #YakShaving then this is epic and based on a true story: https://yakshav.es/the-patron-saint-of-yakshaves/

@alecui @nomemory@fosstodon.org

I reread now, and I admit that I didn't expressed in a clear way my message.

Emacs is a Lisp programming environment. You can navigate in all the code of Emacs using Emacs, change it, and see immediately the effects. In this regards it is similar to Smalltalk and old Lisp machines. In Smalltalk the IDE is also the programming environment. In Emacs the editor is also a programming envirnoment.

This was the meaning of my toot.

You can extend Vim and other editors too, obviously. But, there is still a separation between Vim scripts, and Vim C source code. In Emacs, it is all live Lisp code, from the bottom to top.

@nomemory@fosstodon.org

In Italy, this progressive song had a big commercial success, and it is still well known

https://music.youtube.com/watch?v=tpOybQsDzoM&feature=share

Impressioni di Settembre
Premiata Forneria Marconi
1972

@nomemory@fosstodon.org I'm using Doom Emacs because keybindings and commands are more discoverable respect plain Emacs.

Probably JetBrains IDE are more effective for programming in well supported languages. But, Emacs is the best or nearly the best for all other different usage scenarios. You feel always at home, because you can reuse all the tricks you learnt with time, between different languages and file formats.

Emacs is an interactive, Lisp-based environment, that is specialized for editing files. So you can extend and customize it endlessly. Also if you are not doing this directly, many other users of Emacs have done this. As consequences, it has a lot of functionalities, commands and packages.

In other words, there is no rigid distinction between an user and a contributor. The same cannot be said of Vim, JetBrains and other IDE.

@AnnieKenyon2 @MxAlba @SleepyCatten

If I can not point out that plastic acts like an estrogen in our body, it is not a discussion. And all hypothesis starts as unproven.

You are right saying that there are no proofs about big effects at current normal doses. But "no proofs" does not mean "they studied it in detail and they proved it is all ok". For sure there are no big effects, because otherwise they would find them. But there are still concerns, because there are visible effects in case of people and animals living near polluted zones. Moreover during prenatal phases also a little amount of estrogen can have visible effects. So they want to study better the effects also in case of low doses. Our exposure to plastic is increasing with time. So it is a problem that we must study better. Like any substance "the dose makes the poison".

Maybe I should rephrase in a better way my initial post, but there is still an informative part.

@AnnieKenyon2 @MxAlba @SleepyCatten

It has some effect also at current level of exposition. For example read the part "Although the researchers found no sign of frank genital malformations or disease, they did discover an association between elevated concentrations of four phthalate metabolites in the mothers and shorter-than-expected AGI in the infants, as reported in the August 2005 issue of EHP."

Up to date there are no proof that there are serious risks, but it must be investigated better.

@MxAlba @SleepyCatten

Your argument is for sure right, but there can be also environmental causes, linked to the exposure of plastic-derived estrogens. Up to date nothing is confirmed, but they are studying the effects. For example https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1281309/