Readit News708145_ commented on What went wrong for Yahoo dfarq.homeip.net/what-wen... · Posted by u/giuliomagnifico
How about possibly also failing for being too US centered, basically being an "internet portal" but mainly for the US. Sure Yahoo where _huge_ 2000, but it was never the main goto portal in Scandinavia where I grew up using internet from the mid 90s.
Here Altavista was the defacto standard for search until Google replaced. For the portal aspect of Yahoo, there were local alternatives with more relevant material.
I don't see that Yahoo ever succeeded globally.
Stupid question: Why not provide a threadpool-like construct which may not necessarily keep threads around but limits their number?
Of course it possible to limit the number of virtual threads. A web server can have a limit on number of virtual threads too, and queue incoming request before dispatching to to workers (virtual threads).
As other have said, this can be achieved with a semaphore and the bulkhead pattern. You can also limit the number of number of connections.
I would expect any "production ready" web server using virtual threads having some sort of limiting. That must be the case right?
708145_ commented on Software development topics I've changed my mind on chriskiehl.com/article/th... · Posted by u/belter
> Most won't care about the craft. Cherish the ones that do, meet the rest where they are
> (…)
> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.
What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not necessarily the ground truth.
What you’re essentially saying is “cherish the people who care up to the level I personally and subjectively think is right, and dismiss everyone who cares more as insane weirdos who cannot prioritise”.
It is a fine balance, and everyone that doesn't "drive the same speed" as me, frustrates me.
708145_ commented on Haskell: A Great Procedural Language entropicthoughts.com/hask... · Posted by u/kqr
It is definitely not procedural.
"This seems rather … procedural. Even though we get all the nice guarantees of working with side effectful functions in Haskell, the code itself reads like any other procedural language would. With Haskell, we get the best of both worlds."
Working with the IO monad is much more complex, especially if you want to use other monadic types inside that code.
708145_ commented on Narcolepsy is weird but I didn't notice fortressofdoors.com/narco... · Posted by u/bfelbo
Your eye muscles maybe just tired from constant staring, or neck tension causes brain blood flow problems or something. I struggled with this all the time, but supplementation and exercise helps a lot.
Technical papers aren't THAT boring, after all!
For me it is if in a cosy position and doing something cognitively demanding. Fell asleep very often during my university studies reading literature. It can happen also if trying to learn something new technical at work, but only if I don't sit at a desk.
If normal or not I can't say...
> I've been thinking about the notion of "reasoning locally" recently. Enabling local reasoning is the only way to scale software development past some number of lines or complexity. When reasoning locally, one only needs to understand a small subset, hundreds of lines, to safely make changes in programs comprising millions.
That was supposedly the main trait of object-oriented programming. Personally that was how it was taught to me: the whole point of encapsulation and information hiding is to ensure developers can "reason locally", and thus be able to develop more complex projects by containing complexity to specific units of execution.
Half of SOLID principles also push for that. The main benefit of Liskov's substitution principle is ensure developers don't need to dig into each and every concrete implementation to be able to reason locally about the code.
On top of that, there are a multitude of principles and rules of thumb that also enforce that trait. For example, declaring variables right before they are used the first time. Don't Repeat Yourself to avoid parsing multiple implementations of the same routine. Write Everything Twice to avoid premature abstractions and tightly coupling units of execution that are actually completely independent, etc etc etc.
Heck, even modularity, layered software architectures, and even microservices are used to allow developers to reason locally.
In fact, is there any software engineering principle that isn't pushing for limiting complexity and allowing developers to reason locally?
> The main benefit of Liskov's substitution principle is ensure developers don't need to dig into each and every concrete implementation to be able to reason locally about the code.
Yeah, but doesn't help in this context (enable local reasoning) if the objects passed around have too much magic or are mutated all over the place. The enterprise OOP from 2010s was a clusterfuck full of unexpected side effects.
Easy to blame someone else. None of this is new, she's had more than enough time to compensate and Sweden is in the EU energy market by choice.
It is still true what she says. Having an interconnected electricity system is problematic when countries like Germany misbehave by having a horrible energy politics.
That said, it would had been better in Sweden if they hadn't phased out nuclear too! There is a electricity shortage in south of Sweden where industries are denied establishing new initiatives.
Sounds a lot like a language running on the BEAM (e.g. Elixir, Erlang, Gleam, etc): Distributed Computing built in; Durable State (e.g. ETS); Non-stop (i.e hot code upgrades); Actor model.
I read the main feature to be durable storage or in other words persistent actors. Erlang Term Storage (ETS) I thought was in-memory.
Isn't that precisely what an API is? Normal users do not use the API. Other programs written by developers use it to access Claude from their app. That's like asking why is an SDK phrased as a special kit for developers to build software that works with something they wish to integrate into their app