Aren't we always striving towards 'Keep it simple stupid' (https://en.wikipedia.org/wiki/KISS_principle) principle? What was simple before isn't now and it's time to redefine it. Isn't it?
Back when dinosaurs ruled, *nix systems had many small utilities where inputs could be piped to the next, in effect composing more complex utilities.
MS Windows has variants of text processing from the simplest - Notepad (all text is the same font), Wordpad (text can have different fonts), and Word (full text publishing). But remember, before Word could do desktop publishing, one needed different software to take the Word document and create the publishable version. It was obvious that the 2 should merge, and MS did that.
MS Excel is still the best spreadsheet, but Google Sheets works well for smaller applications and is my go-to for most applications.
One trend in web-based software is microservices. Back to the idea that you compose through the use of discrete, 3rd party services, reducing the difficulties of building a big site, but with other tradeoffs.
AIs to build code could perhaps make building simpler applications easier, but at this time, even Google Firebase is only a weak answer. It does make the boilerplate of building HTML a lot faster.
There have been design tools to help build architecture (IIRC, IBM had an offering that was a visual designer, where the code included stubs for the programmer to complete).
"It’s very easy as an engineer to waste time and energy making something complete, correct…and irrelevant." For some applications, absolute correctness is very important. Completeness is less so. Whatever "completeness" is, software has suffered from task creep, as the marginal cost of copying is nearly zero, and CPU cycles allow for bloat, and indeed, bloated software drives the purchase of more CPU cycles! Remember when Borland's ex-CEO started Starfish, whose mission was to make all applications fit on a 1.44MB floppy disk. Where did that idea go? Nowhere.
I recall attending a talk by IBM, back in the 1990s, with the topic that software needed to be built with "industrial-strength" tools rather than artisanal software development. IDK if that led anywhere, but we seem to be heading back in that direction (again!) with the idea that AIs can build software. Simple prompts won't be enough, but a document with specifications and drawings of UIs (if needed), as inputs, might be a way to go.
Aren't we always striving towards 'Keep it simple stupid' (https://en.wikipedia.org/wiki/KISS_principle) principle? What was simple before isn't now and it's time to redefine it. Isn't it?
Back when dinosaurs ruled, *nix systems had many small utilities where inputs could be piped to the next, in effect composing more complex utilities.
MS Windows has variants of text processing from the simplest - Notepad (all text is the same font), Wordpad (text can have different fonts), and Word (full text publishing). But remember, before Word could do desktop publishing, one needed different software to take the Word document and create the publishable version. It was obvious that the 2 should merge, and MS did that.
MS Excel is still the best spreadsheet, but Google Sheets works well for smaller applications and is my go-to for most applications.
One trend in web-based software is microservices. Back to the idea that you compose through the use of discrete, 3rd party services, reducing the difficulties of building a big site, but with other tradeoffs.
AIs to build code could perhaps make building simpler applications easier, but at this time, even Google Firebase is only a weak answer. It does make the boilerplate of building HTML a lot faster.
There have been design tools to help build architecture (IIRC, IBM had an offering that was a visual designer, where the code included stubs for the programmer to complete).
"It’s very easy as an engineer to waste time and energy making something complete, correct…and irrelevant." For some applications, absolute correctness is very important. Completeness is less so. Whatever "completeness" is, software has suffered from task creep, as the marginal cost of copying is nearly zero, and CPU cycles allow for bloat, and indeed, bloated software drives the purchase of more CPU cycles! Remember when Borland's ex-CEO started Starfish, whose mission was to make all applications fit on a 1.44MB floppy disk. Where did that idea go? Nowhere.
I recall attending a talk by IBM, back in the 1990s, with the topic that software needed to be built with "industrial-strength" tools rather than artisanal software development. IDK if that led anywhere, but we seem to be heading back in that direction (again!) with the idea that AIs can build software. Simple prompts won't be enough, but a document with specifications and drawings of UIs (if needed), as inputs, might be a way to go.