kamray23

That is exactly why I said that that only comes in once you publish something. The legal argument isn't as strong as the moral one is for me anyway, I never publish anything. I think making a PR isn't forcing code on someone, they're not obligated by anything to read and consider it, but if they do want to they can. I'll make one, and then I'll stop responding, because that's where my personal moral obligation ends. Whoever wants the code can now easily discover it, whoever doesn't can throw it away as they like. Including the upstream maintainer.

Eh, most of the time you do have to publish it. MIT/BSD/Apache allows you not to, but most big projects are using LGPL or another share-alike license. With those, if you're making a project that you do publish (e.g. a commercial product that uses that library/language/etc.) you do kinda legally have to share that modified source code. It's of course different if you're scripting for your own sake, but the moment you publish anything using them you also have to publish your modified versions of libraries and other stuff.

I do agree with the "fork and make it better for you", but I also think it's common courtesy to throw up issues for the bugs or missing features you encounter, as well as pull requests. If for no other reason then as "prototypes" or "quick fixes" that others can cherry-pick into their own forks. They may get rejected, they may get closed, but you still don't have to sit there arguing about it since you have your own version. From a slightly Kantian angle you have your working version and you've now fulfilled your social duty by offering solutions to problems. You've got no need to campaign for the solutions if they get rejected.

It's virtuous and you get to ignore the github flame wars. There's really no downside beyond taking 5 minutes to be nice and at least put your solution out there. Also fulfills your reciprocal legal duty under LGPL and such.

That'd be a nice way of looking at it, if serving content was cheap. It is not. I want to put my CV online, but I'm not willing to shill out tens of thousands every year to have it scraped for gigabytes per day. Doesn't happen, you say? Didn't before, definitely. Now there's so many scrapers building data sets that I've certainly had to block entire ranges of IPs due to repeated wasting of money.

It's like the classic "little lambda thing" that someone posts on HN and finds a $2 million invoice in their inbox a couple weeks later. Except instead of going viral your achievements get mulched by AI.

Putting stress on the concrete requires force, and causes the concrete to deflect. Force over displacement is work, and energy can't be lost to nothingness by just breaking the concrete. Thus, the concrete releases the stored up energy as kinetic energy of its fragments.

Stronger concrete requires more stress to cause it to fail, and as such it takes more force to break it. There is logically more energy because of the higher force, so more energy gets released.

more than 3 chips, basically

Yeah, C++ enums are just numbers that are really good at pretending to be types. And for that reason they're not actually objects that contain things like their name. And they probably shouldn't, in the vast majority of cases it would be an utter waste of space to store the names of enum members along with them. So you have compile-time reflection for those instead. And yeah, you could implement some kind of thing pretending to be a member but actually being a reflection thing but that's both horrifying and limited so C++ takes the reasonable approach of just adding general reflection in instead.

wow that's really evil of them i quite don't like them for this as i too played garrys mod back in the day and it pains me to see such a loss of community effort and beloved mods

It sort of isn't though. You put it there and you don't take it away. You don't put anything else in there to load it. It stops loading entirely if you take out the ethernet cable. That kind of seems like it's loading from the internet every single time. The setup function doesn't add anything to load it without the init script running. That's kind of weird, to me at least.

It's not really saying "only expert programmers" though, is it? It's people who know Haskell, which by coincidence happens to be overzealous undergraduates and a certain subset of experienced programmers. FP is a paradigm among many, its basics somewhat predate (or since it's so close, co-date?) more imperative descriptions of computation. That we mostly use and as such mostly teach beginners with procedural languages is a quirk of history. Nothing would prevent a change to that except historical inertia. Saying "more people should learn Haskell" is saying "I don't want to write code only for other expert programmers." It's just as natural if you know it, and even beginners could know it, they just don't.

However as I mentioned, since it is not true that most people can read FP code, I mostly avoid using it. The example comes from my solution to AoC2023's Day 3, "Gear Ratios", which is just about the only thing I use Haskell for.

That doesn't mean that using it doesn't have practical applications, since being used to multiple paradigms opens you up to unconventional solutions. I've recently sped up a MATLAB function ~100x through using a more functional style to manipulate memory more efficiently. Async/await, certain styles of modern iterator manipulation and generators escaped F#, CLU and others into C# and from there into the world at large specifically because Microsoft programmers saw a problem they had had a solution for in previous functional projects. So it's not all useless.

For the record, a more imperative version could be written as

    symbols = [ imagine there's stuff here ]
    gears = []

    for (symbol, coord) in symbols:
        if symbol == '*':
            ns = neighbouringNumbers(coord) 
            if len(ns) == 2:
                gears.append(ns)

or in Python's functional-inspired notation which directly mirrors what's happening in the Haskell code

    gears = [ neighbouringNumbers(coord) 
              for symbol,coord in symbols
              if symbol == '*' and len(neighbouringNumbers(coord)) == 2 ]

though that requires an unnecessary extra call to neighbouringNumbers, which you could solve with a walrus op but I can't remember how to do that. I also changed the entire pair being passed to neighbouringNumbers (which was convenient in Haskell) to only the coordinate that is required (which is convenient in Python).

Personally I just find nowadays that having to comprehend "it collects neighbour-pairs from '*' symbols" from the imperative code harder than having that be the thing that is actually written down.

Ah, sorry, one of those situations where you think about what you'll write and don't end up writing it down. I am of course referring to the inverse in the second sentence, moving data into a brain from a computer. Corrected in the original comment now, thanks!

Whatever Neuralink is missing, it's none of these things. They're certainly missing a lot, as is their owner, but it's absolutely none of these things. Like, we've been using brain electrodes to control devices for a very long time now. They know the issues. As they are originally a neuroprosthetics company whose whole goal was to develop means for paralyzed people to control limbs and devices, they're perfectly in their zone. That's not their issue.

As what their owner wants them to be, with data transmission into the brain and individually addressable neurons, they're leagues off from a functional product. Extracting and interpreting brain signals is, while not simple, well-known and well-practiced. The other direction is practically unexplored and the most we normally do is poke around with a bit of electricity and hope it makes the brain work better. To move data from a computer into the brain would be a total revolution. Needless to say, their current product does not do this, and they've shown zero development to this end. Which kind of makes it feel like they're hoodwinking Musk to develop actually useful medical devices instead of playing into his naive technocratic futurism. That just means they know what they're doing even more strongly than what their other actions have already shown.

I don't think currying happens without you asking to, though. It happens because it happens, it's part of the language, and it's something you implicitly keep in the back of your mind every time you see a function call. I don't program a lot in Haskell, only some maths things I sometimes might need since it is rather useful for that, but the concept of currying is so natural that it's constantly expressing itself in the code. Very rarely do you apply arguments and consider that to be a function call in itself instead of like, three function calls. And since partial application is so incredibly important to Haskell and other similar languages, without currying writing would be very difficult. Consider the actual simple example of

      gears = filter ((==2) . length)
            . map (neighbouringNumbers numbers)
            $ filter ((=='*') . fst) symbols

which without currying would have to look like

     gears = (\xs -> filter ((\x -> x == 2) . length) xs)
           . (\xs -> map (\x -> neighbouringNumbers numbers x) xs)
           $ filter (\(c,_) -> c == '*') symbols

It just makes partial application a lot easier, especially when this kind of code pops up all over the place.

It is in most places. At least in Europe where I live there's a limit of 12 years old for cycling on sidewalks and pedways marked with only a pedestrian sign, whereas sidewalks which are wide enough and marked with both a bicycle and pedestrian sign as well as paths marked with both a bicycle and pedestrian signs are for pedestrians and bicyclists equally. And of course this has its logical conclusion in bicycle-exclusive bike lanes and bike paths with no pedestrians at all on them. It's especially no issue if everyone gets the rules, generally on wide sidewalks where bikes are allowed the outer side with buildings is for pedestrians and the inner side near the road is for cars. Where no bicycle-OK sidewalk exists you just use the road or walk with the bike.

That's already an issue with cars. Most EVs beep or sing or hiss quite loudly when you put them in reverse gear and at low speeds where tyre noise is low they have to augment with ICE and/or whining sounds to not be so silent and deadly. Especially the last few decades from the walkman to ipods to modern bluetooth headphones it's already been really important that vehicles make noise to warn pedestrians of their presence. Suddenly getting reversed on in a parking garage makes nobody happy.

Sensors form a big issue, though. The newer Teslas especially are excellent at ruining safety sensors for the rest of the industry. Now instead of turning your head left to look left and see your blind spot out of what should be a far enough back window to see your blind spot, you can crouch over to press buttons and then look at the small circle on the big screen which shows your blind spot. Fine otherwise but it incentivises not even looking out of your left window as you begin turning, and takes your sight off the road in general, even if for just a look, and even when automatically activated by the blinker. It's a profoundly unsafe safety system because it acts to take your sight away from where it should go, even if it means you don't have to quickly turn your head, and it allows lazier and less safe vehicle design as you no longer have to make sure the driver has possible sightlines to blind spots.

Worse perhaps are all types of proximity sensors, because you can only trust them when they go off, and even then not always. Most cars get dirt on them, snow on them, rain on them and that tends to mess with proximity sensing enough to either disable the sensors or cause them to go off randomly. I don't think anyone has ever yet trusted the blind spot sensors on their mirrors to do a lane change, only aborted one because of them. Such non-camera sensors would fix almost nothing because at best they would sometimes cause people to reconsider swerving into a motorcyclist, and even then they usually go off way too late to prevent misfires while driving normally.

These are great features when they work but overengineering around fundamental design problems seems to me to only put people too much at ease in their cars and make bad driver behaviour worse, because why spin your head around to check when you can just not do that and stare at the little screen or trust your array of easily fooled sensors to do safety in your place. I think solutions like finding alternative pillar configurations, creating long or short enough front side windows for you to see back, harsher driver's license testing with longer required study periods and in cases where you can't do anything else such as some pickups just doing what semis do and having several well-aligned mirrors instead of one set of nice-looking ones would be a lot safer in the end.

As well as getting people who can't drive for shit off the road. That's sort of included in driver's license requirements but there's surely some other methods for it that I have not mentioned.