tabtab

Can you give an example? Some try to put too much detail into ER diagrams in my opinion. A Data Dictionary is usually a better place for such details. ERD's should mostly be to illustrate relationships.

One trend/fad was to put words describing links between tables, but I usually didn't find such helpful. Maybe if the wording was done well it would help, but most seem forced in practice. Good naming takes experience. Maybe let newbies draft the phrases, but have someone with experience review it. I.e, mentoring.

UML was yet another fad overdone. Many IT fads do produce useful niches or specific products, but the impression given at the time is they'll replace most of what came before. That's rarely the case. I can list about 25 "trends" like that since the late 80's. Chasing fads has gummed up too many stacks and standards.

> But this tells you next to nothing about which tool is more productive in the hands of a small team of people who know what they're doing.

This has been tried, usually driven by academics who try to start a business by hiring "elite" coders with the belief that you need many fewer elites to do the same work as "normal" coders. Sometimes they have short-term "hits", but it's usually not a sustainable business model. For one, it takes coders with some business sense and team skills, something the academic type tend to lack: they are idealists who get snagged up on arcane design philosophies. Imagine a room of Sheldon Coopers. I'm just the messenger.

I will agree it's about 30% less code on average, but whether it's "team friendly" or "debug friendly" is quite another matter. Debates over such often rage for months.

If it's truly superior, then form a company called Functional Magic or the like and out-compete OOP rivals and eat their lunch. Proof will then be in the pudding, no more talk. (Some co's have tried similar without long-term success, at least outside of niches, as it does well in finance.)

If FP is say 15% more productive, such a company would eventually just outcompete OOers by growing 15% a year. Even 5% a year would catch up in roughly a decade. If you truly believe in FP's superiority, do it! Unleash the FP Kraken! When you are golfing with Warren Buffett & Gates, you can say, "I toldja so, fore!..."

From a practical perspective, one should probably learn procedural/OOP first, it's the de-facto industry standard, and thus better for one's early career. Whether functional is "better" in the longer term, I won't get into here, only to say I have skepticism.

The CRUD IDE/Stacks of the late 90's were closer to the domain and that was a large reason for the productivity I used to see: more done with less key/mouse-strokes and less code. Web stacks make one waste time fiddling with janky stack parts & layers instead of domain logic, where it SHOULD be spent.

It's hard to match their productivity with current web stacks, often requiring specialists and/or big learning curves. (Sure, the 90's IDE's had their warts, but were getting better with time, until web murdered them. And I'll limit this to small-and-medium apps rather than enterprise/web-scale.)

It's usually assumed the features that made them productive are mutually exclusive with web-ness. I'm not convinced; the industry just stopped experimenting. What would help is a state-ful GUI markup standard so that GUI's don't have to be re-re-reinvented via HTML/DOM/JS, which is inherently ill-suited for rich CRUD GUIs.

Having your language/tools/standards being a close fit to the domain matters. It's why COBOL lives on despite being even older than me. I'm not saying we should mirror COBOL as-is, only that it still carries important lessons, including FDD: Fit the Damned Domain.

They have everything else in there, might as well add the kitchen sink. CSS is Swiss Army Rocket Surgery.

I'd like to see vector-driven challenges to web standards. For one, we could bring back WYSIWYG under vectors by having grids with "stretch zones" that allow for larger devices. Constraint and flow-based layouts often grow highly convoluted for those of us who need to be generalists (full stack devs). Not every project should have to hire a CSS Sheldon Cooper to get Hello World in the right spot. (SVG and Canvas lack most the Input elements.)

Several years ago I read about using genetic algorithms to "evolve" better mini-sorts. I wonder how the two compare.

Back then software copyrights and patents were even murkier than they are now.

Re: "And spreadsheets still basically behave the same today!"

Uh, not sure that's a good thing. For certain tasks, I've seen better UI models and sheet idioms. I agree it's flexible, just awkward for certain needs.

Replace them with corresponding emoji's, and reinvent hieroglyphics :-)

Re: "tax breaks are butts in seats tax breaks"

It kind of reminds me of schools who are afraid of kicking out disruptive students because they are funded based on student count. It's usually better for disruptive students to go to special schools, but the butt-based-funding mucks that up.

Where's GrammarGPT when you need?

Let's x-ray that apostrophe, it may be hiding something.

The whole classification system in current use is very lossy.

Most are probably still easier/saner to use & program with than the goddam DOM/HTML/CSS rendering via bloated JS libraries.

We sorely need a state-ful GUI markup standard so we can get desktop-friendly GUI's over HTTP instead of rely on binary, proprietary, and/or DOM-JS-bloat tools.

I kept hoping the web would eventually grow decent GUI standards, but it never did. Social networks and dancing-cat videos got all the attention, not real-work-GUIs. DOM is inherently the wrong tool for the job, and fixing it would break backward compatibility.

More on DOM-fail: https://www.reddit.com/r/CRUDology/comments/12jt7i1/the_four...

File buffering RAM and/or arrays was invented long before Adobe. The tricky part is probably optimizing the image processing algorithms to fit the filing method(s). For example, if images are split into "tile files", and a given algorithm requires referencing too many files/tiles at a time, creating too much file I/O, then it probably needs to be reworked into a tile-friendly algorithm.

I can intellectually see the power of Lisp, but in practice I find it's just really hard to read down the road, especially other people's Lisp. The visual cues provided by the "ugliness" of other languages do help reading (I gave examples nearby). Lisp is kind of like new tract homes: they look all the same such that it's easy to get lost. An old neighborhood with funny bent mailboxes and a mish-mash of house and yard styles is just easier to remember.

The main problem I find with Lisp syntax is that everything looks the same: a giant soup of parentheses. You have to read Lisp closely to know the context. A list of statements (function calls) visually looks different than a list of parameters in C-style languages, for example. Similarly, you see square brackets and immediate know it's a subscript/index to an array-like structure. And parenthesis (usually) mean something different than curly braces.

Visual Cues Help! Maybe your eyes are different, but most the programming world has agreed with me over the years and voted C-style over Lisp. I have even proposed a syntax style called "Moth" that attempts to meld the best of C-style, Lisp, and XML in terms of composability and roll-your-own control & block structures. I welcome better takes on the goal.

Moth link: https://www.reddit.com/r/ProgrammingLanguages/comments/ky22d...

And it still shows.

"Old" isn't necessarily bad. If you want productivity over fashion, older styles are often better. They are more mouse-friendly and easier to understand, as buttons actually look like buttons instead of faded flat stickers.

How does this compare to GTK in terms of features?

Maybe somebody can use it to make the state-ful GUI browser that the "office" industry sorely needs so we don't have to force DOM to act like a real GUI (which it does painfully and poorly). GUI's and mice do most the real work; let's not give all the standards attention to web toys and mobile.

I haven't seen the FBI's response to this report yet. I'd like to hear their side before forming an opinion.

Small and medium meteorites smack into the moon's surface all the time, being it has no atmosphere. I find it hard to believe that human-built landers have nearly as much impact on low-orbit grit than these meteor impacts.

If they protest they'll probably get plenty of "supporters" from the community, knowing human nature.

But if you don't blend the two, then you have a DRY violation. Someone should only have a say a field (column) is required in one and only one place, for example. The framework should take care of the details of making sure both the client and the server check.

I myself would like to see a data-dictionary-driven app framework. Code annotations on "class models" are hard to read and too static.

I keep saying this and will say it again: what's really needed is a state-ful GUI markup language. HTML+DOM+JS+CSS is the wrong tool for the CRUD/GUI job, and force-fitting it has inflamed the area so bad many don't want to even try to scratch it.

Bloated JS frameworks like Angular, React, Vue, and Electron have big learning curves and a jillion gotcha's because they have to reinvent long-known and loved GUI idioms from scratch, but DOM is inherently defective for that need, meant for static documents. There are just too many GUI needs that HTML/DOM lacks or can't do right: https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...

Let's byte the bullet and create a GUI markup standard. Perhaps base it off Tk or Qt kits to avoid starting from scratch.

To beat competitors, not have tons of beemers for beemer sake. The motivation is relative. The 3 big "robber barons" of the late 1800's use to send each other brag-grams over who was richer.

"Gimme gimme gimme!"