ff_

Those projects are in good hands!

There are a few of us still at it :)

Though with the advent of LLMs it became very easy to spin up alternate backends for it, so it's very much alive outside of JS as well.

second paragraph of the article starts with:

> The sector contributed 0.25% to GDP and enabled savings on consumers' electricity bills of more than 4.6 billion euros in 2024, with an average reduction in the wholesale price of close to 20 euros per MWh.

(in mice)

To yourself - the code you just merged is now yours to maintain

Fresh pasta is an entirely different beast from dried pasta, so the two are hard to compare. I never made dried pasta at home, but I find it impossible (even in Italy) to buy fresh gnocchi that are as good as the ones that you can make at home.

I am all for improving the conditions so that signs can be removed (and this is valid with code too, e.g. a strong type system removes the need for a lot of documentation), but again we should not advocate for not documenting things, that's just asking for trouble.

And speaking of signs, we definitely don't have a good balance there either - in some places I experienced confusing situations where adding a few more signs could have helped.

Sure, but then the advice we should give is "please please document the WHY", rather than "stop commenting"

In any case, I personally find it very useful when I come to a new piece of code to find comments that summarise what it's happening in a few words without having to parse 10-100 lines of dense implementation - I have so much cognitive ability I can apply in one day, and any effort to optimise its usage should be welcome

"Remove half of the signs, they become outdated whenever we change the roads"

Software is written by humans for humans, and documentation is a fundamental part of it, and needs maintenance just like the rest. It is beyond me why one would want to maintain only half of the thing and say "discard the rest"

In all the Haskell teams I worked in, the candidate knowing Haskell was rarely a significant advantage (except for cases where the most experienced Haskeller leaves, and then you need to hire someone to direct your GHC-internals questions to).

If you are interested in a job using a functional language you can pick basically any of them and then jump ship to a different one. I wrote Clojure for many years before switching to Haskell.

> As for myself, I think what foods I choose to consume are none of the government's business

There is a difference though: it's not about choice as much as it is about "good defaults". As a state you should want your folk to have better food, but if some person wants the choice of micromanaging their diet then sure, go ahead.

I shouldn't be struggling to find non-processed food in a supermarket. This is often the case right now, which is why I would very much welcome some more regulation on this.

This game is very good, congrats!

I would like to play more, but the games seem to be unreliable - the moves from my opponents stop getting through at some point, typically after a few moves.

I've been fighting with the automatic accumulation of downloads for years now - it really makes it impossible to figure out if whatever I downloaded can safely be deleted - so my current system is similar to the OP's one, but a little gentler: I have a launchd task that runs every day and warns "I'm about to delete these things that are older than two weeks", which lets me salvage anything I might have forgotten to archive.

Source here in case it's useful for anyone: https://github.com/f-f/home/blob/ee0ae5dd201ac6e8ffa60fff71b...

I've been looking into this (thanks for the pointer to Sensitronics!), do you have any pointers to a manufacturer of squishy material pads? (silicone I guess)

There's also the thing that while modern keeled sailboats are able to sail well upwind, that is not the case for these classic vessels which have a much smaller/shallower keel, and have a lot of trouble upwind. So if the wind is not right and you're on a schedule then motoring is the only option.

Sailor here - an 8 meters boat is in that awkward spot where it's big/heavy enough that it can do damage if incontrollably drifting against something (e.g. the wooden vessel itself) but light enough that you can literally just push it with the strength of two people if that happens.

So I'd argue it's more safe to have some crew on it in case you need to be hands-on, and just talk over radio while being towed.

Be very careful, it's surprisingly hard to eventually get out of it

The most impressive thing about this is not the overtone singing - one can learn that given some practice time - but to me it's how LOUD the quartet sounds.

I'd recommend being in the same room with them if you can, the feeling is just incredible, and videos and recordings absolutely do not render how powerful this kind of singing can get with the years of practice that they put in.

How is the working environment in PA tech? Would you recommend working there?

Sorry, I meant Duna Jam.

Do you know anything about what happened to Duna Rock?

Companies don't do this because they can get away with it.

Unions are usually the most effective countermeasure to these kind of things.

Here in Finland the tech-sector union just agreed to a 2% salary increase (inflation is at 2.5% this year [1]) after having threatened strikes if the conditions of the agreement were not good enough [2]

[1]: https://yle.fi/news/3-12143521 [2]: https://yle.fi/news/3-12262577

I'll give this a try, thank you!

I 100% relate to this, so the smartwatch bit is very interesting as I didn't think of using it for this - what's your workflow like? Do you just have calendar events on your wrist, or a more custom solution?

Are you aware of PureScript on Erlang?

https://github.com/purerl/purerl