poorlyknit

This is a cheap overgeneralization.

What can we do to make rent-seeking hurt society less? Imo we should start by decoupling money from power. Right now, people are forced to participate in the rent-seekers game because his wealth implies power over them.

A zipcode should be plenty and grocery websites do that already.

Very cool :) I got a good enough score in the basic scenario by playing around a bit but it would be cool if you could link some kind of tutorial (e.g. to a digital PID video or something like that).

The fact that it happens

    1) at/around powers of two
    2) regardless whether using GC or preallocating

makes me think its got to do with cache sizes. For example, the M2 macbook has around 16MiB of cache, which gives you approximately 2 million ~ 2^20 nodes where each node has a 64 bit number and a 64 bit pointer.

The jumps in your measurements could be related to the cache hierarchy. On Linux (probably macOS too) you should be able to run "perf stat ./mergesort" to show you the hitrate of your CPU's caches.

I'd be interested in a follow-up post :)

Elm comes to mind. Mentioned a bunch on HN but you probably wouldn't call it widely used...

Well no, obviously. Nix has not solved the rice theorem. But you'll have this problem whether you're using BuildKit or Nix. Difference is with Nix the final image only contains your explicitly stated dependencies. I.e. no apt, no Python, no Perl, no cacerts unless you explicitly include them.

Like it or not, team dynamics are a part of engineering.

Not OP, but I think it's a valid approach.

You gain: Model consistency guaranteed by the database, your backend basically only acts as an external API for the database.

You lose: Modularity, makes it harder to swap out databases. Also, you have to write SQL for business logic which many developers are bad at or dislike or both.

I've seen a system running on this approach for ten years and it survived three generations of developers programming against this API. There's Python wx frontends, web frontends, Rust software, Java software, C software, etc. They all use the same database procedures for manipulating the model so it stays consistent. Postgres is (kinda, not very) heavy for small projects but it scales for medium up to large-ish projects (where it still scales but not as trivially). One downside I've seen in this project is that some developers were afraid to change the SQL procedures so they started to work around them instead of adding new ones or changing the existing ones. So in addition to your regular work horse programming language you also have to be pretty good at SQL.

IMO the Python version provides more information about the final state of res than the Go version at a glance: It's a list, len(res) <= len(foo), every element is an element of foo and they appear in the same order.

The Go version may contain some typo or other that simply sets result to the empty list.

I'd argue that having idioms like list comprehension allows you to skim code faster, because you can skip over them (ah! we're simply shrinking foo a bit) instead of having to make sure that the loop doesn't do anything but append.

This even goes both ways: do-notation in Haskell can make code harder to skim because you have to consider what monad you're currently in as it reassigns the meaning of "<-" (I say this as a big Haskell fan).

At the same time I've seen too much Go code that does err != nil style checking and misses a break or return statement afterwards :(

Effect systems spring to mind but they're rather esoteric (in the Java world).

Try using it for concrete problems you have today, start small. I used it to write a small calorie counting web app and some other tiny projects and picked it up that way.

There's no null in Haskell to check for. Go check it out!

This would be even more palatable if it involved some more design patterns.

Does that change anything though?

If you haven't already, read "Gödel, Escher, Bach". It sounds like you would enjoy it. For me its more of a "pick it up somewhere in the middle and get inspired" than "front-to-back" title but iirc it considers the halting problem and the incompleteness theorem to be two sides of the same coin.

ISBN is 3423300175.

Would you mind expanding that? I always assumed that renting, lending or buying anything constitutes a contract technically.

Except that you're not allowed to take out a mortgage and denied credit if you're poor, which means you're stuck spending your money for necessities and therefore being poor. The system works great for people who (or whose family, circle, etc.) are already not poor.

This attitude is how we get stuff like the GTA V O(n^2) JSON deserialization bug. I get it, nobody is implementing quicksort on a day-to-day basis, but being taught the ideas behind these algorithms is important for building mental models.

They have an interesting idea of "achieved":

> Currently, only NVIDIA v100 GPU simulation is supported, and all GPUs mentioned later in this post are simulated v100s.

So unless they can reproduce this on a real cluster cluster of V100s, it should probably be taken with a grain of salt. What I'm missing in the simulation is an accurate account of how the host-device barrier is sped up using this system. Reading the headline I was hoping they'd be using NVIDIA GPUDirect for accessing the storage directly from the devices but I believe you'd need very custom CUDA for that...

> us-vs-them mentality is very popular in radicalizing say well-meaning patriots or heavily left-leaning folks into properly stupid irrational positions, siloing them into self-feeding echo chambers

> part of population with lower than average IQ (which by definition is half of mankind)

Sounds like us-vs-them mentality to me honestly.

In Haskell you have a lot of options to type your functions in a more granular way. Consider the type class MonadIO, which lets you specify that your function works on any monad that can do side effects, not just IO specifically:

    -- Before
    captureAudioDuration :: DeviceID -> DiffTime -> IO WaveData
    -- After
    captureAudioDuration' :: MonadIO m => DeviceID -> DiffTime -> m WaveData

You can build the same thing, but for logging!

    class Monad m => MonadLog m where
        log :: String -> m ()
    -- In IO, just log to stdout.
    -- Other implementations might be a state/writer monad
    -- or a library/application-specific monad for business logic.
    instance MonadLog IO where
        log msg = putStrLn ("log: " ++ msg)
    -- Before: Bad, doesn't actually do any IO but logging
    findShortestPath :: Node -> Node -> Graph -> IO [Node]
    -- After: Better, type signature gives us more details on what's happening.
    -- We can still use this in an IO context because IO has a MonadLog instance.
    -- However, trying to capture audio in this function using either
    -- of the functions above will lead to a type error.
    findShortestPath' :: MonadLog m => Node -> Node -> Graph -> m [Node]

As you can imagine this can get quite verbose and there's other patterns one can use. Feel free to ask any follow-up questions :)

> am I required to forget that you came into my store?

No. Your head is not covered by the GDPR. It requires you to not keep a record of all your clients' personal info without a legitimate interest.

There's a Seinfeld episode where Elaine goes to buy a fancy pen at a stationery store which isn't available atm. The clerk asks for her full name and number to notify her (that's a legitimate interest) but then uses it to hit on/stalk her (that would be a GDPR violation). Presumably he also doesn't get rid of the number after their business transaction.

Just store it by selling it to your neighbor state or country and buying it back when their renewables are at peak :)

I think you're conflating the terms capacity and peak production here.

As mentioned elsewhere in this thread, the peak production makes German electricity cheap enough to make everyone around them use it when it's available. If all the neighbors used this approach too, over the course of a day it would be everybody's turn to provide energy for the neighbors as renewables production will never be zero globally.

Solar does not drop to zero every night if you connect enough countries to the west and the east or your country is big enough. And there's literally always wind because the ground heats up as the sun moves, creating imbalance in temperature and therefore air pressure.

There's enough countries out there that have been using renewables consistently for years (esp. EU countries). I don't understand how this is still a talking point. Daily variance in supply is equalized by trading energy with your neighbors which uses the phenomenon described above: The sun is always shining somewhere.

For Germany in particular it was a mistake to move away from nuclear before coal (imo lobbying is mostly at fault here) but they've been building renewables since the late nineties. It took them the time it takes to build a single nuclear reactor to move to more than 50% renewables and those are much easier (= cheaper) to maintain for the years to come.

To be pedantic, that's mixing latin (felis) with greek (philia). Not sure if there's a word already but you could do ailourophilia.

Isn't that just a private school where the parents are the teachers?

I recently visited Dublin from Germany and was positively surprised that they also still use cash in a lot of places. I even saw two pro-cash posters that read something like

    Using cash, we only spend 70% of what we spend using electronic payments

and the other one was privacy-related. I agree with both of them and your comment that it's easier to keep track of your expenses with cash.

Honest question (I don't know much about about EXIF), but wouldn't the metadata be peanuts compared to the actual image data?