90% of my my experience has always been dealing with large-ish corporate systems.
I am in Europe, so YMMV even when talking about corporate instead of smaller scale projects.
In my experience stuff like RAILS had negligible impact in my field because companies would always require solid backup from some big name vendor (MS, Oracle, IBM, Sun - back in the day, or even SAP).
So most if not all the smaller silver bullets did not even make a blimp on the radar... and stuff like Java or .NET, while definitely better than C or COBOL... did not really deliver in terms of productivity boost (in part because, as noted in the message I am answering to, expectations kept growing at the same pace)
Well... the actual problem is, imho, that it looks like the LLMs seem to have reached (or are close to reaching) a plateau.
You might be right about the "three months ago it could not produce a working implementation of a DBMS... but what if in 3 months (or 3 years) it stays stuck at the 20K slower threshold?
Everybody already has local regional tickets anyway. And most people can't be in more then one place at the time anyway. And most people stay in the same region most of the time anyway.
I live in Rostock. So if I want to go to Berlin or Hamburg (you know, where stuff like actual airports are) I am crossing "regional borders" even if it is a 200-250 km trip to each city
About non-replaceable batteries: from what I understand, if a battery can be replaced by any random device owner you must design it with a robust cell to avoid risk of it being punctured, breaking, being crushed.
And therefore you have more shell, less actual battery and therefore it lasts less.
This does not mean that I believe this was done exclusively for altruistic reasons. More like: this will result in a slightly better experience for the user... and more revenue for Apple. So let's do it.
I think that what erased "programmer vs computer illiterate" dichotomy was BASIC in the 80s.
I've met lots of "digital natives" and they seem to use technology as a black box and click/touch stuff at random until it sorta works but they do not very good at creating at mental model of why something is behaving in a way which is not what was expected and verify their own hypothesis (i.e. "debugging").
I am from that era, so I might add something that perhaps is not obvious at all nowadays.
The microcomputer explosion gave birth to an large number of actual paper magazines and at least 50% of their content were... actual source listing you had to manually retype.
Basic was already fragmented in a billion different flavors and dialects (especially if your program had any kind of graphics) so the more ambitious user could also try their hand at translating a listing from - say - TSR-80 to Apple Basic.
In any case you were directly exposed to the actual source code, and tweaking or experimenting with it felt very natural.
This are just the last three Social Media I subscribed in the past and range from Stagnant to Pretty Much Dead.
I suppose that the problem is that if you already have 1000+ followers on, say, Twitter or IG you try posting the same stuff in parallel on both... after 1 month of doubled effort you notice that your followers on the new platform is an order of magnitude smaller... you want to stop double posting because it is too time consuming. Guess which one you will opt out of?
Personally I am trying to see if we can leverage AI to help write design documents instead of code, based on a fairly large library of human (poorly) written design documents and bug reports.
But then the post claims that "everything is a synchronization problem" seems should be qualified better.
Also, most of the comments before mine seemed to be in full agreement that yeah, full synchronization would be a silver bullet, even for cache invalidation
Maybe I am just dumb but I really cannot see how data synch could solve what (in my kind of business) is a real problem.
Example: you develop a web app to book for flights online.
My browser points to it and I login.
Should synchronization start right now? Before I even input my departure point and date?
Ok, no. I write NYC -> BER, and a dep date.
Should I start synching now?
Let's say I do. Is this really more efficient than querying a webservice?
Ok, now all data are synched. Even potentially the ones for business class, even if I just need economy.
You kniw, I could always change my mind later. Or find out that on the day I need to travel no economy seats are available anymore.
Whatever. I have all the inventory data that I need. Raw.
Guess what? As a LH frequent flyer I get special treatment in terms of price. Not just for LH, but most Business Alliance airlines.
This logic is usually on the server, because airlines want maximum creativity and flexibility in handling inventory.
Should we just synch data and make the offer selection algorithm run on the webserver instead?
Let's say it does not matter... I have somehow in front of me all the options for my trip. So I call my wife to confirm she agrees with my choice. I explain her the alternatives... this takes 5 minutes.
In this period, 367 other people are buying/cancelling trips to Europe. So I either see my selection constantly change (yay! Synchronization!!!) or I press confirm, and if my choice is gine I get a warning message and I repeat my query.
Now add two elements:
- airlines prefer not to show real numbers of available seats - they will usually send you a single digit from 1 to 9 or a "*" to mean "10 or more".
So just symching raw data and let the combinatorial engine work in the browser is not a very good idea.
Also, I see the pontential to easily mount DDOS attacks if every client is constantly being synchronized by copying high contention tables in RT.
Well, yes - this is a somewhat extreme case but the problem is the same even for internal-use-only corporate systems.
And it becomes even more acute when (as it is my case) your first language is not the same originally used to develop the first version of the system.
(Imagine an ERP system built in UK and adopted and customized by a French company, for example: IT would probably use 20% of French terms/names, the rest will be in English... Business will do the opposite).
I don't think much of this article.
The Brown M&M example seems a bit convoluted and anyway "what to do instead" is just a bunch of platitutes.
"Write doc to make it searchable" ... ¯\_(ツ)_/¯
In my experience one of the big problems (I just had a call from one of my users demonstrating exactly this point) is that often there is a disconnect in terms of vocabulary.
What the business calls a "refresh" of System X123 could be any of "full copy from prod of the whole X123 data", "can we please just import the subset of data I created in X123 Test?", "X123 provides a sort of materialized view of the sale prices to Z567, but it seems that the view is outdated, can we please refresh that"?
This happens (albeit less severely ... "usually") inside IT itself at least when the organization gets over a certain size. So dataset are named with their content, but the actual content might change scope or the part which is more relevant varies for each consumer, therefore both the provider and the N consumers tend to refer to the same thing with slightly different names while the "correct" name is already used for something else in different context (e.g.: "Sale prices" - is it now? future? historical? only for agents? only for a specific country/market...?).
Even just having a single, unambiguous lexicon would help a lot (and would make the "searchabilitly" a bit less mythical) but I don't see this or similar points addressed, while apparently the detail of the sound and light equipment deployed by Van Halen seems to definitely require some space.
I did a quick google search and ISO 31320-02 seems to be available only by paying ~170 CHF.
Is there any text which explains how it is used? Even if I wanted to pay the aforementioned price I am afraid that I would get just a standard reference text with little or nothing in terms of actual teaching how is should be used and what the benefits are.
[ my public key: https://keybase.io/pamar; my proof: https://keybase.io/pamar/sigs/C2832FEsxtRdIvojiTUYs6V3pFvcW-ruh1CByYD47iM ]