That's an interesting - and maybe correct - point. Looking at the examples, it seems very long winded and not something I would want to write myself - but maybe I don't need to care about that anymore, as you say!
This time around in the pre-covid days, F# had a surge of popularity, there was Fable and Giraffe and an elm-style set of frontends (the generic pattern is called MVU - Model View Update), it didn't take off because A) we are still a trend/fad-driven industry and B) there was no AI to help hold your hand in refactoring all of your apps.
These days? Doing this FE SPA framework for Effect/typescript familiarity or Fable for F# familiarity and a model-view update pattern can help one do CQRS better, force you to think about stronger Hexagonal Architecture patterns, and overall help your application care about long term correctness more without you having to hand code every discriminated union as such.
The LLM can't replace you, but it can be an enzyme that lowers the activation energy required to switch from bad old MVC mutable tag soup to MVU frontends with strong data interface designs held in sqlite-dbs-per-aggregate (if you are of a DDD or event sourcing taste, which this pattern does not require!)
I see people are doing scripts or other things to remove shorts from their feeds, but there is a simpler solution. Take your RSS URL of a channel, e.g.:
No one knows how many vulnerabilities there are in closed source medical record software - because we can't check. There are _probably_ loads though, because that medical software is super terrible in every way that we _can_ check.
Well the closed-source EHR applications that use NoSQL databases such as MUMPS (InterSystems Caché) probably don't have many SQL injection vulnerabilities.
Isn't anything closed-source by definition this? Why speak of the subset of closed-source medical record software when it's just the entire class of software?
I've tried to use state charts for frontend development a couple of times, but bounced off. IIRC, I was using xstate with vue, and I found that they were hard to retrofit to existing systems, and where I tried, I found that the boundary between the part of the system controlled by xstate and the rest of the system problematic. It felt like it would work better with everything "inside" the statechart, but that's a big lift for an existing codebase.
Recent Claude will just look at your code and copy what you've been doing, mostly, in an existing codebase - without being asked. In a new codebase, you can just ask it to "be conscice, keep it simple" or something.
I did try ruby-prolog. The deeper issue is that its just not prolog. Writing in actual prolog affords a lot of clarity and concision which would be quite noisy in ruby-prolog. To me, the difference was stark enough it wasn't worth any convenience already being in ruby was worth.
Interesting! There are ~2 starlink satellites re-entering the atmosphere _every day_ now - and this is only set to increase. I wonder if this was caused by starlink debris?
The starlink satellites are designed to burn up in the atmosphere. They do this pretty often. But there's plenty of other space junk that's not designed to burn up and should have shown up on radar.
1) if this was big enough to get picked up on a 737 radar I think we would be having a very different conversation...
2) even if it did... rentry velocity is like miles per second, that would give you on the order of single digit seconds to recognize something on an intersecting trajectory and take action...
3) even then, I would bet that an object on this trajectory and speed would get filtered out as noise by aircraft radar because it is so antithetical to the types of things an airliner needs to inform pilots of.
And the Titanic was designed to not sink, sometimes reality is harsh. What is the probability for any of the parts of a starlink satallite to survive a descent?
Way less likely than the non-burned up remainder of some item from decades ago that was never specifically designed to burn up because "that's hard and it'll probably hit the ocean anyway"
It's hard to overstate just how much random junk is up there.
I was excited to see some evidence, but if you actually read the article they're talking about flakes of silicon with less than one joule of energy reaching the surface. To break an airliner windscreen, you need an energy more like a big hammer.
> In one rare instance, the company also revealed that "a 2.5 kg piece of aluminum" found on farm grounds in Saskatchewan, Canada, was traced to a Starlink satellite.
A piece of debris of similar size to this is what I'd guess could cause the kind of damage we see in the incident involving the airliner.
So while most Starlink debris may be harmless by the time it reaches the surface, we know this doesn't always happen as expected.
And since the vast majority of reentering space debris is from Starlink satellites, that'd would be the first place I'd look.
To be totally clear, I am doubtful this is actually caused by space debris, but I don't think it's entirely unreasonable for it to be one of the most likely causes.
> The starlink satellites are designed to burn up in the atmosphere.
How high in the atmosphere, though? They're not likely to hit the ground, sure, but 36,000 feet isn't the ground. Second, designs fail. 432 Park was designed not to have cracking and spalling concrete, yet NYT has a story today about exactly those things. Third, people lie about designs and capabilities. Pretty sure anyone who has ever worked in computing (especially with VC involved) has seen that. Who made that claim, and did they ever back it up?
I'm not saying that Starlink is the culprit here. The evidence is thin. OTOH the possibility can't just be dismissed because of a claim about a design to prevent a similar (but not identical) thing.
I pressume its much easier to design something to burn than to do anything else. You are basically just restricting yourself on material selection. The goal isnt for something to not fail, the goal is to fail. Its like asking to build a lawnmower that doesnt have to cut grass, and can look however you want. If you produce a pebble, it fits those criteria.
The atmospheric entrance for these (starlink) sattelites is basically as shallow as possible, so the object spends the most time possible in high atmosphere (think 60-90 km, where the atmo is thick enough to engulf the object in plasma, yet extert low pressure to slow it down, prolonging the time its burning. In otherwords, you couldnt achieve better parameters to burn stuff on deorbit.
All of it will probably be fully burned way before 50km - planes fly at 8-12
"Probably"? Even in their defense you felt a need to hedge, and that should tell you something. As another commenter has pointed out, Starlink has admitted that some components might survive re-entry. Let's not fall all over ourselves trying to give Musk and Co. more benefit of the doubt than they even give themselves.
Im just a rando on the internet, Ive never inspected the sats to know if they are not using materials that just wont burn up, hence "probably".
Im just listing facts to help you make a picture, I am not trying to "defend" anyone/anything. Please try to free your political/corporate bias from ingesting new information.
I haven't read the latest version of their ODAR (orbital debris assessment), but earlier versions of the satellites had a couple pounds of material that wasn't expected to burn up
You can still do this, it all still works, technically. You will have a spam/malware/security issues that wouldn't have been an issue back in the day. You will also have discoverability issues - but that hasn't actually changed, if it's just for you or your friends.
