I use it like a search engine (or rubber duck) too. I like to test ideas and form hypotheses, but I don't really like to code with an LLM. Occasionally it's helpful to template something but it's rare that I want to iterate on the foundation an LLM created.
I suppose the main reasons are that 1) the code convention likely doesn't mesh with what I'm working on, 2) the lack of context awareness, 3) common performance concerns and 4) potential IP issues which admittedly seems like a rare issue yet I'd rather not contend with it.
There is an exception though. When I'm trying to prototype firmware quickly, I like to use it to generate code for components I haven't used before or recently, and I'm content to rely on it until I've proven out an idea. Past that point though I will almost certainly rip out that code and start fresh using the conventions and patterns I prefer.
I think they meant that hypothetically, presuming a case where we didn’t have access to better methods. The question might be rephrased as “would this be accurate and reliable enough to calibrate a thermometer if someone cared to try?”. I might be wrong, but it’s how I interpreted it.
It just occurred to me that if dinosaurs never existed here and we found them somewhere else, they’d be such an incredible discovery. We’re lucky to have such an awesome history of life on this planet.
Humans are probably unique. Intelligent life probably not and life at all is likely commonplace. It would be quite a miracle if given the size and scale of the universe Earth is the only place where life arose and also managed to evolve multiple intelligent species also emerged (cephalopods, dolphins, elephants, and primates at least)
There is a theory that humanoids aren't actually unique, if there's large animals on other planets in the universe. Our body plan has several survival advantages so it's quite possible evolution could have had similar results elsewhere. Bipedalism is really great for efficiency of locomotion (humans can walk really really far), and having two limbs with opposable thumbs is really useful for grasping and manipulating, which makes it much more likely that species will invent tools and technology.
Note I'm not claiming humanoids are all over the place, but with 400B stars in our galaxy, 1T stars in Andromeda next door, and other galaxies with similarly huge numbers of stars, multiplied by all the number of galaxies in the observable universe, multiplied by the number of exoplanets in the "Goldilocks zone", it's quite possible intelligent, humanoid life has evolved somewhere out there.
That would be a stronger claim than the one I made which is just that life exists in some form somewhere else in the universe with a relatively high abundance and it’s highly likely intelligent life exists somewhere as well.
It becomes harder to reason that humanoid life and even intelligent humanoid life must exist somewhere else without any actual data points.
>That would be a stronger claim than the one I made which is just that life exists in some form somewhere else in the universe with a relatively high abundance and it’s highly likely intelligent life exists somewhere as well.
Sure, but we're probably thinking of "intelligent life that can build a civilization", right? In that case, highly-intelligent alien orcas aren't going to meet the requirement. They just don't have a body type that allows them to change their environment and build technology. If there really are alien civilizations out there, like in Star Trek, that show might not actually be that far off with its assumption that 95% of them are humanoid. And in this case, there could very well be lots of other intelligent life, but which never managed to build a civilization.
If we’re bringing up fiction, why are we assuming Star Trek and not Cephalopods like in Arrival or completely alien morphologies like in Scavenger’s Reign. Even if there is a humanoid involved it could be as a host or slave for the intelligent life that controls it (eg dominion in Star Trek). With a sample size of n=1 of our planet (with no quantifiable way to even measure and compare intelligence), I think we’d be assuming a lot to make the conclusions you are making even if we restrict ourselves to those that can build up industry or even leave their planet. I’m also not sure why we’d care so much about leaving a planet - we’re desperately looking for any sign of life which would be a momentous discovery in and of itself. As for Orcas, don’t underestimate just how deadly humans are - we outcompeted concurrent competing intelligent hominids by killing or mating with them and regularly decimate wildlife and consume resources at a rapid pace. No reason to believe that an alien Orca with thumbs couldn’t eventually accomplish the things we did without ever leaving the water.
Star Trek used humanoids because of practical special effects at the time and because it would be easier for the audience to identify with the aliens and make the show more accessible, not because there’s some underlying scientific reasoning going on.
To make any predictions about the shape that intelligent aliens would take would require some probabilistic falsifiable model that would tell us where to look and what we’d find. Anything other than that would rely on very shaky first order reasoning which is what we’re doing to guess that there is likely intelligent life somewhere.
>I’m also not sure why we’d care so much about leaving a planet - we’re desperately looking for any sign of life which would be a momentous discovery in and of itself.
Just finding alien plant life somewhere would be a momentous discovery, but that's still nothing like finding an alien civilization that we can communicate with, trade with, etc. One doesn't diminish the other.
Alien orcas (probably) can't leave their planet, or really establish much of a technological civilization. So they'd be interesting to observe, just like alien plants or alien mice, but that just isn't the same kind of thing as interacting with an alien civilization.
>No reason to believe that an alien Orca with thumbs couldn’t eventually accomplish the things we did without ever leaving the water.
How so? How exactly are the alien orcas going to get out of the water to outcompete intelligent creatures on the land? Building any kind of technology in an aquatic environment would be incredibly difficult, if it's possible at all; if there's intelligent creatures on dry land, they'll have an automatic advantage. Sure, the alien orcas with hands and thumbs would have a much better chance than Earthly orcas that don't, but still, how do you, for instance, build a gun when you're an aquatic species? On dry land, it's really not that hard. Even smelting metals seems rather impossible underwater.
> not because there’s some underlying scientific reasoning going on.
Scientific reasoning wasn't the intention, but the idea that aquatic aliens have as much ability to build rockets and spaceships as land-based aliens is pure fantasy. The laws of physics don't change on other planets.
It depends. If simple life is common, how rare is GOE or a similar event? If GOE is not that rare, it feels like intelligent life is just a matter of time, ice ages and enough branches to grab on. Otoh if we are the result of a long domino chain, the universe life is screwed.
I have no idea what GOE is, but everything we learn about astronomy indicates that neither Earth nor our solar system is particularly unique, so “long sequence of dominoes” would be a very unlikely situation in something as large as the know universe, even ignoring the parts we could never observe.
Reminds me of "Carl's Doomsday Scenario" where they pick up a pet that happens to be an "a species seeded on all life-supporting planets, but a nasty asteroid caused them to go extinct here. I believe they are called 'Velociraptors' here."
The only place I find the complexity of message queues worth the trouble is in the embedded world. The limited resources make messaging a sensible way to communicate across devices with a fairly agnostic perspective on what runs on the devices apart from the message queue.
Most of us in the desktop computing world don't actually need the distribution, reliability features, implementation-agnostic benefits of a queue. We can integrate our code very directly if we choose to. It seems to me that many of us didn't for a while because it was an exciting paradigm, but it rarely made sense in the places I encountered it.
There are certainly cases where they're extremely useful and I wouldn't want anything else, but again, this is typically in settings where I'm very constrained and need to talk to a lot of devices rather than when writing software for the web or desktop computers.
As for your last point, the Internet of Things is driven by message queues (like MQTT), so depending on the type of work you're doing, message queues are all over the place but certainly not exciting to write about. It's day-to-day stuff that isn't rapidly evolving or requiring new exciting insights. It just works.
People who love Angular really love it, so I trust that there's a legitimate place for it. I think one of the main things people love is that the convention and tooling eliminates a ton of the noise and redundancy that the other tools tend to lead to as teams slap applications together without sufficient guard rails.
Essentially a lot of the tools we use are only meant to be view layers, and we constantly cobble together supporting layers (models and controllers for example) ad-hoc. Angular handles that off the shelf. I suspect a lot of people are put off by this because it feels imposing and they might not realize they're implementing the same stuff manually, and likely doing it worse.
I used to think it's plain old garbage but realized that's ridiculous. There are reasons people prefer it in some scenarios.
SolidJS is my favourite by a long shot, but I find myself using React because I know so many people I write for and work with are more comfortable with it. I'd be glad to use it more often if it made sense.
I'm currently learning Angular and it's an absolute dumpster fire of a framework in the sense that it offers no clear philosophy. It's just a jumbled mess of concepts and syntax.
I think where it shines though is that it's completely batteries included, which I can see being useful for large enterprises where it's near impossible to change things.
Having recently worked on a very legacy React app, it became apparent to me the value of frameworks like Angular. If you can maintain it and upgrade it gradually, React is arguably the better choice. But if you're leaving it to stagnate, Angular is a far better proposition.
I think we're on the same page here. I've also found that a non-trivial number of teams actively maintaining React apps are still totally capable of rendering them into a state of dysfunction and paralysis in the same way that stagnating apps can devolve.
They think they don't need batteries included because it's 'bloat' or the opinionated patterns are inferior, but after a couple years they've got a couple dozen seriously bad patterns and a 400kb application that could easily be pared down to 100 or so.
This isn't so much a virtue of Angular or React specifically, but a reality of the deficiencies in our industry when it comes to the human side of the equation. These people would be better off following Angular's general conventions whether they realize it or not.
So much of Angular versus React is "No one got fired for picking Google tech" versus "No one got fired for picking Meta tech" with some of the obvious problems of their "parent" organizations' approaches visible in the maintenance efforts.
Maybe, but maybe not. I had someone follow me around on HN relentlessly trolling for a couple weeks years ago. It was surreal. I had to stop commenting for a long time to lose their attention. It was over something incredibly trivial.
Those ideas might be missing the networking part. I’m not sure if their people know the right people. I’m also not confident their track record would inspire confidence in their ability to execute on that type of service. It doesn’t seem well aligned. Ads on the other hand aren’t so far fetched.
Something which gets me about these Effect methods is that very similar things can be accomplished with generators. I assume this is all generators under the hood. I personally would rather just write that code because once you’re familiar with it, it’s really not that difficult to work with.
I agree that a wrapper around generators is nice if it suits the situation (like async/await), and abstracting them is useful at times, but I’m not sure I’d want to pull in an entire library for it.
One thing, the Effect.runPromise and similar methods which seem like overkill are probably providing quite a bit more utility and reliability than it appears. It might offer good cleanup guarantees as well.
I should add that this is the equivalent of a hot take. If I looked closer I’m sure I’d change my mind, but I’m old and crotchety like you.
It reads a bit backwards indeed. Effect.Http.request.get().pipe(Http.response.json, Effect.Retry)? Why not Retry(get())?
This doesn't feel like a pipe, the pipe is mixing data pipeline operations with declarative configuration reusing the original operation, almost like the Config Builder pattern. Nothing wrong with that in itself, except it's obscured by calling it a pipe.
What will be retried anyway? The last step in the pipeline or the whole pipeline? Do you really want to retry a json decode or 4xx client side error? Ignoring this makes for a nice front page demo of short code, but when you start considering real scenarios, some of the same complexities of the vanilla ts version eventually creep up. The question is, do you want to solve those with straightforward, yet slightly more verbose, ts code, or by learning all the edge cases of the library.
If you are looking for something similar to only handle the difficulty of error and retry handling related to fetch, and are ok with being tied to React concepts, i can recommend TanStack Query instead. Thanks to the reactive nature, you just need to configure a query object, which then only returns data to you and re-renders when it is valid. Good stuff.
I love the tiny RP2040 boards. I’ve got a few little projects based on the adafruit QT Py. I do wish there was a wireless version. There is if you use the ESP32 QT, but not RP2040 as far as I can see.
I suppose the main reasons are that 1) the code convention likely doesn't mesh with what I'm working on, 2) the lack of context awareness, 3) common performance concerns and 4) potential IP issues which admittedly seems like a rare issue yet I'd rather not contend with it.
There is an exception though. When I'm trying to prototype firmware quickly, I like to use it to generate code for components I haven't used before or recently, and I'm content to rely on it until I've proven out an idea. Past that point though I will almost certainly rip out that code and start fresh using the conventions and patterns I prefer.
reply