heisig

Oh, it very much is a big deal. In a setting where users can switch models easily and with no downsides, market forces will give us better and cheaper AI over time. If switching models is painful (as in, losing part of your context), the providers can create vendor lock-in, enshittify the user experience, and drive up cost. Even if there are workarounds right now, those AI providers have every incentive to make freedom-seekers more miserable over time.

It is disheartening that some AI companies are now setting the stage for enshittification. I hope we can collectively dodge that bullet.

Let me re-iterate the main lesson of decades of FOSS work: the advantages of open collaboration and knowledge-sharing are so enormous that FOSS software wins out eventually even if financial interest are stacked against it.

I fully agree with this article - please let's skip the chapter of closed and enshittified AI and go for the good stuff directly!

Really good timing for Jolla to produce a new phone :)

I still have fond memories of my 2013 Jolla, and I'm hoping that the 2026 Jolla will be just as lovingly crafted. Most importantly, Jolla is a company that seems to care about me, the user, whereas Apple and Google constantly treat me like a peasant that needs to be governed.

Says the bag of lipids and proteins :)

Unfortunately I would not be surprised if the real death toll is even higher. I have first-hand information. We are talking about indiscriminate shooting with heavy machine guns into peaceful protests, happening in every city of the country. The rule of law has completely broken down. The wounded avoid hospitals because they are afraid of getting killed there.

Unfortunately those videos exist. There are videos of relatives walking for hours from body bag to body bag to find the remains of their lost ones. There are videos of people with heavy machine guns shooting indiscriminately into peaceful protests. There are videos of executions. Everything has been recorded.

There is a reason why the Iranian government cannot activate internet and phones anymore. Once people can communicate again, they will count and document the true scale of events. Right now, it seems the Iranian government would rather give up on internet and telephones altogether than having anyone find out, which tells you just about how bad the situation is.

Let me comment as an SBCL user: This is outstanding work, and I can now remove a lot of performance hacks from my code because the default hash tables became equally fast!

Also, this technique eliminates a number of worst-case scenarios and inefficiencies, which is a boon for any hash table user.

I recently switched to uv, and I cannot praise it enough. With uv, the Python ecosystem finally feels mature and polished rather than like a collection of brittle hacks.

Kudos to the uv developers for creating such an amazing piece of software!

I fully agree. Limiting the amount of copies of software to sell them like a finite good has so many downsides:

1. There may be people who cannot use/afford some software, although there is technically an infinite supply.

2. Collaboration becomes awkward. Either all contributors give up their rights (Open Source), or one contributor holds all the rights and the rest is being treated unfairly. The latter decreases the incentives to make software modular and reusable.

3. The resulting software typically gets worse due to some copyright enforcement mechanisms. For example, no closed source software will ever have a good debugger, because that would allow viewing and changing the source code.

4. It creates a power imbalance between software owners and software users. Nearly all software has to be adapted over time, but the software owner has a monopoly on performing such adaptations. The result is enshittification, surveillance, and basically a return to feudalism where daily life is governed by a small number of overlords.

5. It is not clear how to price software fairly, and there is also little incentive to do so.

6. My impression is that high-quality software converges to formal proof, which is AFAIK not copyrightable.

For all these reasons, I think it is time to consider a world without copyright on software.

To those that worry about salaries in such a world: Negotiate payment in advance (contracts, crowdfunding, bounties, ...), or get a job where software is created as a byproduct (consultant, researcher, tester, ...).

Now Microsoft just sounds like pre-Brexit Britain. Why reflect on your own shortcomings when you can blame the EU instead :)

I suggest Microsoft follows Britain's example and leaves. The main difference is that we Europeans actually miss the Brits, whereas nobody would miss Microsoft and its shoddy products and business practices.

On a more serious note, I fully understand that the Digital Markets Act is causing Microsoft headaches. But I think this headache is well deserved. Big Tech has been building moats where they should have built bridges, and now our computing landscape resembles medieval Germany where everything was at the mercy of a few feudal lords. It is time to drive out those lords and reshape software in a way that empowers, not enslaves.

Yes, the #. reader macro is one of the ways how you can achieve this in Common Lisp. Using the reader macro is also way more efficient because you don't awkwardly use your compiler as an interpreter for a weird subset of your actual language - you simply call to compiled code.

Seeing Greenspun's tenth rule [1] in action again and again is one of the weird things we Common Lisp programmers have to endure. I wish we would have more discussions on how to improve Lisp even further instead of trying to 'fix' C or C++ for the umpteenth time.

[1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

Implementing lazy arrays or xappings naively is easy - the Petalisp reference backend has just 94 lines of code [1]. The challenge is to implement them efficiently. With eager evaluation, the programmer describes more or less precisely what the computer should do. With lazy evaluation, you only get a description of what should be done, with almost no no restriction on how to do it. To make lazy evaluation of arrays as fast as eager evaluation, you have to automate many of the high-level reasoning steps of an expert programmer. Doing so is extremely tedious, but once you have it you can write really clean and simple programs and still get the performance of hand-crafted wizard codes.

[1] https://github.com/marcoheisig/Petalisp/blob/master/code/cor...

Connection Machine Lisp never made it into production, but this paper had a profound impact on my scientific career. In particular, it was the following comment in the paper that triggered me to develop the Petalisp programming language (https://github.com/marcoheisig/Petalisp):

> Nevertheless, we have implemented (on a single-processor system, the Symbolics 3600) an experimental version of Connection Machine Lisp with lazy xappings and have found it tremendously complicated to implement but useful in practice.

I think there is a moral here: Don't hesitate to experiment with crazy ideas (lazy xappings), and don't be afraid to openly talk about those experiments.

After eight years of development, I can definitely confirm that lazy arrays/xappings are tremendously complicated to implement but useful in practice :)

This paper is from last year, and a lot of interesting things have happened in the meantime:

- The parallel garbage collector is now part of SBCL, but not yet the default. Enabling it is attractive, though, because it has roughly twice the throughput.

- The SBCL maintainers used the parallel GC as reason to make SBCL's memory management overall more modular. This process is still ongoing, but experimenting with different GC strategies on SBCL has never been easier.

- Another GC is already in the works that has virtually zero pause times. Once this is merged, we can finally bury that old myth that Lisp systems stutter (if it hasn't already been buried by the presence of video games written in Lisp, like Kandria)

The parallel GC is an amazing achievement by Hayley Patton. We SBCL users cannot thank her enough for her outstanding work!

Heh, thanks :)

Petalisp author here - this ELS paper is just a preview. I'm also preparing a 160 page document (for my PhD) that will explain everything in more detail. I'll post on HN when it is available.

There is also a recording of my ELS talk on Twitch: https://www.twitch.tv/videos/2138821711?t=00h40m35s

Let me summarize the key points of this law:

- Starting from April 1, German adults can legally possess a certain amount of weed (25 grams on the move, 50 grams at home), and they may consume it unless they are within 100 meters of a school or kindergarten.

- This is just the first stage of that law, where the only way to actually obtain weed (other than for medical purposes) is to grow it yourself, or to form a collective of growers. Either way, the maximum number of plants per person is three. Commercially trade of weed is planned for later, as a second stage of the law.

- While this law legalizes weed for adults, it further prevents access for minors. The law raises the penalty for selling weed to minors to a minimum of two years in prison, and people that grow their own plants must ensure that minors cannot access them. People aged between 18 and 21 are only allowed access to weed with a THC content of less than 10%. The reasoning behind all this is that weed severely impairs the brain development of young people.

- Driving while under the influence is still a crime.

- The stated goal of this law is to eliminate the black market and to stop the growing trend of minors smoking weed. A review is scheduled in 18 months, determine whether the law in the current form achieves that goal or whether it has to be tweaked further.

This law is obviously a compromise between all the parties of the German government, EU law, scientific consensus, and practicability. What I like about the law is how carefully it weighs health issues and individual liberty. All the limits (legal age, grams of possession) have a solid scientific basis.

> I'm very curious why you've chosen to go down the route of special casing on parallelizing within one socket

This is no special casing. Most of that code will also be used for the distributed parallelization. I agree with your remarks on hybrid MPI+OpenMP, and, in fact, Petalisp doesn't use shared memory anywhere, but always generates ghost layers and explicit communication.

> I will also say that it feels a bit weird to call something "peta-" and "HPC" if using more than one socket is relatively far off into the future. For the randomly-wandering PhD students out there, it would be nice to tell them this up front in the Readme :)

I can do that. But let me explain the rationale for naming Petalisp this way: I wanted to create a programming language that is novel, and that has the potential to scale to petaflop systems. And I wanted to create a robust implementation of that language. I think I have achieved the former part, but the latter simply takes time.

Final remark: Good HPC practice is always to get single core performance right, then getting multicore performance right, and then scaling up to multiple nodes. Anything else is an enormous waste of electricity.

Thanks for clarifying. I will definitely write down the specifics of setting up distributed computing once it works. However, support for distributed computing will still take some time. The current step is to iron out all the remaining issues of parallelizing within one CPU socket.

I am not sure what you mean by "required infrastructure setup". Installing Petalisp is a single call to (ql:quickload :petalisp) - assuming you have Quicklisp installed. If you also have a C compiler available, and an executable named cc pointing to that compiler, Petalisp will use that to speed up your codes further.

About the required hardware - anything that runs SBCL or CCL can also run Petalisp.

Petalisp author here. I apologize that the README is somewhat lacking, but it wasn't me who posted this on HN.

As you may have seen on the commit history, a lot of exciting things have happened over the last few months. However, there are also a few stupid performance bugs left, so I am delaying the release of any performance numbers until those have been fixed. Otherwise, I fear that people will simply misinterpret the results.

Nevertheless, I can already state that the single-core performance of Petalisp programs is exactly like that of a C program - simply because Petalisp compiles its programs to C when possible. (Although I also have that long-term agenda of using sb-simd to reach that performance in pure CL some day.)

In addition, Petalisp is quite good at automatically parallelizing programs, and we already have most of the infrastructure for distributed and heterogeneous computing in place.

I will write a more detailed post for the HN crowd once I have reliable performance numbers and once I finished writing the documentation.

Feel free to ask me further questions.

Guy from Germany here: No, we didn't change our mind on combustion engines. They are getting less popular every month, and even the German car companies have roadmaps that phase out the combustion engine well before 2035.

Here is my take on the situation: The problem is that the current government consists of three very different parties (which was the only viable option for forming a government without the conservative climate disaster that is the CDU/CSU). One of these three parties, the FDP, is currently losing popularity because they essentially promised that fancy technology will solve all our problems (take note HN!), but that bluff got called now that they are part of the government. The FDP is quickly losing voter support, and entered panic mode. Unfortunately, the only voter base they can quickly tap into are petrolheads and people that don't like when things get "verboten". The FDP runs the ministry of transport, and used that influence to stall legislation for the entire EU. The other parties cannot really object, or our government would fall apart.

I can only personally apologize to all other EU nations. A party with about 5% popularity is holding our government hostage.

The only positive thing is that these people cannot really decide about the law in 2035, only about the law today. I hope the climate movement will grow stronger, and those people and their policies will be history much sooner.

Maxima is a surprisingly good alternative to SymPy. We had to learn that the hard way at my job. Both systems offer similar functionality, but it turns out Maxima is typically 50-200x as fast as SymPy for many tasks (I guess because it was written at a time when computers were slow and expensive). For our application, switching from SymPy to Maxima shortened the time-to-solution from hours to minutes.

Also, it shows that Maxima has been in use for a very long time, and maintained by very bright people. I have yet to encounter a bug in Maxima. And I have already encountered plenty of bugs and inconsistent behavior in SymPy.

Congratulations to the entire team from Shirakumo Games!

Developing and shipping a full-fledged video game requires a lot of hard work and dedication. And writing a custom game engine and tool chain at the same time is really a heroic feat. Hats off to everyone, especially to Shinmera!

Emotions certainly played a major role when Germany decided to phase out nuclear in 2011, and the execution and timeline of that phase-out were poor.

But that doesn't mean Germans haven't pondered seriously about this topic in the meantime. And the result is that, apart from this band-aid solution for the current winter, Germany will still phase out nuclear. Let me try to summarize the most important points I know of:

- Cost. Nuclear energy is expensive energy. It just happened to be cheaper than solar and wind energy a decade ago. But the cost of renewables went down spectacularly, and the cost of nuclear went up at the same time (https://en.wikipedia.org/wiki/Levelized_cost_of_electricity). So why invest in nuclear energy when we could have more low-carbon energy for the same price elsewhere?

- Subsidies. So far, all nuclear power plants have been heavily subsidized. There isn't a single country where the full cost of decommissioning and permanent storage of radioactive material is properly taken into account. And there is no power plant with a full insurance, so those risks are carried by the public. Once we eliminate these subsidies, the cost of nuclear grows even further.

- Reliability. Some people dislike renewables because there are times with no wind and no sunshine. But they forget that wind and sunshine are relatively predictable and have worst-case bounds. So investing into storage and the electricity grid makes renewables highly reliable. Now look at nuclear. The worst case scenario is roughly what just happened in France: you discover a problem that affects an entire generation of power plants, and all of them have to be taken offline until the problem is resolved (https://en.wikipedia.org/wiki/Nuclear_power_in_France#Crisis...). Without its European neighbors, France would be in deep trouble. If we take precautions against this risk, the cost of nuclear grows even further.

- Inflexibility. Nuclear power plants need a high uptime to amortize their construction cost. But once they operate in a grid with a substantial amount of renewables, they are displaced more and more and the cost per unit of energy grows even further.

- War. The Russian army has recently captured a Ukrainian nuclear power plant (https://en.wikipedia.org/wiki/Crisis_at_the_Zaporizhzhia_Nuc...). The plant is now used to store military equipment, the employees are bullied or even tortured, and all pillars of nuclear safety are being violated. There are credible approaches how we can build a power plant that resists human stupidity or a natural disaster, but there is no way we can build a power plant that is unconditionally safe in a war zone.

- Nuclear Proliferation. Once the know-how and the infrastructure for handling fissionable material is in place, even if only for civilian purposes, there is a much stronger incentive to also look into military use. And the last thing our planet needs is more nuclear weapons.

Given these points, the current German position seems quite sensible and I wonder why some other nations are suddenly so eager to build new nuclear power plants.

This is great news! This is a wonderful project, and the fact that it wasn't accessible from Germany made me profoundly sad and angry.

I hope the responsible copyright lawyers have a hard time sleeping because of this and consider changing their line of work. If you are blocking people from reading books in the public domain, it is a good indication that you are one of the bad guys.

Even worse, they only blocked people from Germany that didn't know how to use a VPN. German courts really don't get how the internet works.

Speaking of Common Lisp - the European Lisp Symposium starts tomorrow (May 3 and May 4, https://european-lisp-symposium.org/2021/index.html). The entire conference will be broadcast on Twitch. Python programmers are invited, too :)

> I wonder if there's a middle ground;

I hope that McCLIM (https://common-lisp.net/project/mcclim/) can some day fill that role, or a project that is similar to McCLIM.

I cannot imagine a better way of interacting with a computer than to have objects that can be manipulated both interactively and with Lisp code. Emacs is already close to that ideal, but I think we could do even better.

I work in academia. My research is about new concepts for parallel programming, especially via runtime optimization and JIT compilation. It was not hard to convince others to use Common Lisp for this - there aren't many languages that allow for metaprogramming at run time. And of these languages, Common Lisp is the only one with decent performance.

As for landing a job outside of academia - my advice would be to attend some of the regular Lisp meetings (See http://planet.lisp.org/, or https://european-lisp-symposium.org/). There is usually some recruiting going on at these meetings. And even if not, you might meet fellow hackers that know about job opportunities.

I use Common Lisp for most of my daily programming, and SBCL is a big reason why. Once you get over the initial hassle (getting used to the Emacs+SLIME tool chain and learning to read the compiler diagnostics) it really gives you the productivity of Python with the performance of C++. And a lot of that performance is thanks to the tireless effort of the SBCL developers, who have been churning out a new release every few months for the last decades.

Kudos to all SBCL contributors!

The Common Lisp Cookbook is an excellent starting point for learning more about the Lisp ecosystem: https://lispcookbook.github.io/cl-cookbook/

Another great introduction to Lisp is this blog post by Steve Losh: https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/