Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
tabtab
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
12 ms
·
91.
▲
by
tabtab
3y ago
No methodology can make up for bad management. Co's are quick to fire regular employees, but are slow to fire bad managers (or move them to a bitter fit). And KISS & YAGNI should apply to methodologies just as much as software syst
92.
▲
by
tabtab
3y ago
Addendum: I suppose we could use sp_addextendedproperty, but it's usually just easier to work with a "regular" table.
93.
▲
by
tabtab
3y ago
> Self-documenting code/schemas are an even better place But they don't offer enough columns and detail for certain things in my experience. A shop-rolled data dictionary can be "shaped" like shop needs.
94.
▲
by
tabtab
3y ago
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 wo
95.
▲
by
tabtab
3y ago
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 "tren
96.
▲
by
tabtab
3y ago
> 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 &quo
97.
▲
by
tabtab
3y ago
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
98.
▲
by
tabtab
3y ago
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
99.
▲
by
tabtab
3y ago
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
100.
▲
by
tabtab
3y ago
They have everything else in there, might as well add the kitchen sink. CSS is Swiss Army Rocket Surgery.
101.
▲
by
tabtab
3y ago
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 hi
102.
▲
by
tabtab
3y ago
Several years ago I read about using genetic algorithms to "evolve" better mini-sorts. I wonder how the two compare.
103.
▲
by
tabtab
3y ago
Back then software copyrights and patents were even murkier than they are now.
104.
▲
by
tabtab
3y ago
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.
105.
▲
by
tabtab
3y ago
Replace them with corresponding emoji's, and reinvent hieroglyphics :-)
106.
▲
Can AI common sense be faked via brute force?
2 points
by
tabtab
3y ago
|
0 comments
107.
▲
by
tabtab
3y ago
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
108.
▲
by
tabtab
3y ago
Where's GrammarGPT when you need?
109.
▲
by
tabtab
3y ago
Let's x-ray that apostrophe, it may be hiding something.
110.
▲
by
tabtab
3y ago
The whole classification system in current use is very lossy.
111.
▲
by
tabtab
3y ago
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 HTT
112.
▲
by
tabtab
3y ago
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 gi
113.
▲
by
tabtab
3y ago
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 readin
114.
▲
by
tabtab
3y ago
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 parame
115.
▲
by
tabtab
3y ago
And it still shows.
116.
▲
by
tabtab
3y ago
"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.
117.
▲
by
tabtab
3y ago
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 painfu
118.
▲
by
tabtab
3y ago
I haven't seen the FBI's response to this report yet. I'd like to hear their side before forming an opinion.
119.
▲
by
tabtab
3y ago
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.
120.
▲
by
tabtab
3y ago
If they protest they'll probably get plenty of "supporters" from the community, knowing human nature.
More ›