- blauditoreI agree, but reality is often different, even for cars. Sometimes because of incompetence, sometimes because of dark patterns. Many newer cars do have space for putting your phone somewhere on the middle console, but it's arranged in ways to make it impossible to place your phone in a way that would make it usable for navigation. Why? Because they desparately want you to use their own navigation setup (which probably costs extra too).
- Which languages are you talking about? It looks unfamiliar to me.
- Have you ever noticed some people can't even use basic punctuation like question marks.
- In terms of hardware, there shouldn't be too many surprises. People have been doing this with desktop computers for ages, so it's known what it means to maintain and upgrade 10+ years old computers. I have one (desktop) that I'm using regularly, and did a few minor upgrades over the years.
Of course, warranty and support quality is a different question.
- Such details also annoy me, but this one would be very easy to fix with a semi-transparent sticker, or a marker.
- To my surprise, I recently found a typo in AI-generated code. It's rare though
- Is it really a script though? IIUC it's more like contextual declaration (e.g. of previous char is X, then use style Y), no?
- It's like people are rediscovering the most basic principles: E.g. that documentation ("prompt library") is usecho, or that well-organized code leads to higher velocity in development.
- Just like Apple with their pentagonal screws, or whatever it was. I'm sure there's even some twisted argument along the lines of "we're just doing it for user safety".
- Yes, that's why I love AliExpress. It evens the playing fieldin such cases, to some degree.
- Actual complexity depends is not imposed by the framework, but by the application itself, and the amount of front-end logic tends to be lower. Yes, there is more complexity in the setup of front end code (now there are dependencies and build pipelines), but ultimately they should simplofy things especially for slighly more complex websites.
Testing is one of the things that's generally tedious in front end applications, but not inherently complex. There may be lots of config needed (e.g. for setting up and controlling a headless browser), and long turnarounds because tests are slow and shaky. But they are also boilerplatey.
- The "Quora Digest" email killed me.
Most of the mails read like fake ones from a video game. Maybe it's because most of them were written by an older generation who uses more classic letter-style writing.
- It's about the complexity of the task. Front end apps tend do be much less complex and boilerplate-y than backends, hence AI tends to work better.
- Dynamic inspection of an object's API? I think it's a very common thing for programmers to explore a type's API on-the-go (as we can't memorize every function name). With static typing, that information is known before run time and can be immediately displayed by the IDE in the form of auto-complete. In dynamically typed languages, the most reliable way to achieve the same is by running and inspecting it, which is basically how people work in Smalltalk from what I've seen.
- That sounds kinda stupid, it would completely destroy the original space savings. Unless the sharding makes it fit within compiler limits.
- I could never make myself like Pharo (or Smalltalk). Yes, it's interesting and exotic, but it never seemed really practical. Maybe what I was missing the most was static/explicit typing, which replaces the need for many of Smalltalk's features. I also never liked working with Python or JS for that reason.
It's amusing that in the mid-2010 with the raise of Node, web (turned "full stack") devs advocated for JS and how static typing was really not that relevant. Then TS came and suddenly the same folks considered it an absolut game changer.
- This could be obviously done with much less code: Just add "if"s for all even number, and at the end just return "odd" if none of the evens matched. 50% less code!
Or even simpler: If it's 0, return "even". If not, do a recursive call to n-1, if that equals "even", return "odd", otherwise return "even".
But the best way is probably to just use a library. Yes, 500MB of additional dependencies, but then it's a one-liner.
- These kind of future prediction posts keep coming, and I'm tired of them. Reality is always more boring, less extreme, and slower at changing, because there are too many factors involved, and the authors never account for everything.
Maybe we should collect all of these predictions, then go back in 5-10 years and see if anyone was actually right.
- All these engineers who claim to write most code through AI - I wonder what kind of codebase that is. I keep on trying, but it always ends up producing superficially okay-looking code, but getting nuances wrong. Also fails to fix them (just changes random stuff) if pointed to said nuances.
I work on a large product with two decades of accumulated legacy, maybe that's the problem. I can see though how generating and editing a simple greenfield web frontend project could work much better, as long as actual complexity is low.