A lot of the nuance is also one of threat assessment, and risk tolerance.

We can prepare for a situation where we’re attacked by the US, but given all probabilities is that worth it compared to preparing for a situation where we get attacked by China or Russia, or is that even worth considering vs preparing for a situation where we can ramp up industrial military production as fast as possible and become a resource rich manufacturing powerhouse?

There’s no way of knowing which path the world will go down, and preparing for everything simply isn’t possible, so every decision is going to be a matter of what risks to take for what potential benefits.

At the moment, no, probably not, and it’s not either / or. Drones were a surprise in Ukraine, but their effectiveness has somewhat diminished as new counter measures like jamming, and just basic stuff like netting, are starting to blunt their usefulness.

Meanwhile they’re still getting hammered by glide bombs, modified heavy bombs that can use GPS to find their targets and are launched by traditional aircraft, far away from the front line, and some of their most effective weapons have been the Storm Shadow / Scalp cruise missiles, which are also launched from traditional fighter jets (which effectively act as a first stage).

And again, it’s not one of the other. In an actual war, either aggressive or defensive, you’re going to want a mixture of capabilities… You can’t always zerg rush.

deleted by creator

deleted by creator

But the court rulings / precedence wouldn’t care about that distinction, it just covers learning from copyrighted material in general.

What if you read a copyrighted engineering textbook, and then build something for profit with that knowledge?

There’s no reason not to publish messy code. Most code ends up being messy.

It could be malware, OP is not sharing the source code.

It could be malware, OP is not sharing the source code.

Share the source code or this is DOA.

Exactly, Sci Fi writers almost never invent an entirely new technology for their books, they just look at current technology, think a bit about where it might head, think about how that could interact with broader societal forces, realize some flaw there-in, and write about it.

Technologists are doing basically the same thing, looking at current technology, thinking about where it might head and what might be useful and/or profitable, and then start trying to overcome current obstacles to develop and build it.

But one of them takes a single person a year or two to write a book, and the other has to start trying to do research and building things and testing them and breaking them and getting funding and overcoming the current obstacles etc. etc. If they start at the same time it will look like the technologist has just built what they were warned not to, when in reality they’ve been building it the whole time on a parallel path.

The SOLID principles are just that principles, not rules.

As someone else said, you should always write your code to be maintainable first and foremost, and extra code is extra maintenance work, so should only really be done when necessary. Don’t write an abstract interface unless multiple things actually need to implement it, and don’t refactor common logic until you’ve repeated it ~3 times.

The DRY principle is probably the most overused one because engineers default to thinking that less code = less work and it’s a fun logic puzzle to figure out common logic and abstract it, but the reality is that many of these abstractions in reality create more coupling and make your code less readable. Dan Abramov (creator of React) has a really good presentation on it that’s worth watching in its entirety.

But I will say that sometimes these irritations are truly just language issues at the end of the day. Java was written in an era where the object oriented paradigm was king, whereas these days functional programming is often described as what OO programming looks like if you actually follow all the SOLID principles and Java still isn’t a first class functional language and probably never will be because it has to maintain backwards compatibility. This is partly why more modern Java compatible languages like Kotlin were created.

A language like C# on the other hand is more flexible since it’s designed to be cross paradigm and support first class functions and objects, and a language like JavaScript is so flexible that it has evolved and changed to suit whatever is needed of it.

Flexibility comes with a bit of a cost, but I think a lot of corporate engineers are over fearful of new things and change and don’t properly value the hidden costs of rigidity. To give it a structural engineering analogy: a rigid tree will snap in the wind, a flexible tree will bend.

Honestly I haven’t seen a single article written by someone who actually understands the mathematics involved so I call a huge amount of HORSeSHIT on your headline.

Omg, a sustainable, repairable, and open source project costs the same as a closed source, non repairable, locked down option … Those are totally the same thing!

/S

There is an open source project to replace the innards:

https://sett.homes/

No it’s not.

It might be to you, but there are enormous numbers of elderly and disabled people who would benefit from more assistance.

I still wouldn’t trust a robot around them given how inherently dangerous a massive motorized contraption is, but we also shouldn’t be blind to accessibility and utility just because we don’t personally need it.

Honestly, Germany should be thanking this man for pushing their country forward.

Again, no, because that’s not a resolution, that’s a pixel density at a set distance.

While I get your point, this is an article, not a whitepaper.

If someone says something that is obviously not a thing, like ‘the perfect resolution of an analog painting’, then it means the author probably didn’t actually understand what they read and so you shouldn’t trust their interpretation of the underlying news.

That’s not a resolution, that’s a pixel density at a set distance. It’s also arbitrary on Apple’s end, not actually a meaningful universal measurement.