There must be some metric of the resonance of a particular piece by looking at the number of reposts and distribution of comments amongst them (plus an analysis of the sentiment of the comments and characteristics of the thread trees in each separate posting).
Just looking at this listing, without looking at the comments in each one, this seems to have a sustained resonance.
Its resonance may sustain because theres always people entering the field who are trying to build something, and either get caught up on a frameworks hypetrain or have fond enough memories using a given framework to build something quickly, and then getting burned trying to build something ambitious with a given framework because its opinionation proves to be too rigid one way or another, and a perpetual new influx of these sorts of people are happy to know it isn’t just them who hate (or at least were burned by) frameworks.
One of the very first times I was paid to professionally develop software for someone else I totally fucked it up by trying to build some kind of “modular” “reusable” contraption, that in reality was a vague collection of ill-defined ideas for what I wanted to make.
I have since come to believe that this is a trap that many people fall into.
Even a colleague of mine at my current job might be sort of in this track himself at the moment I think. And I don’t feel that he is interested in listening to me at all. Even though we are supposedly on the same team.
I think these kinds of things, when you fall into the trap, is something that you have to eventually realise on your own why it was a bad idea.
Meanwhile I am at the verge of quitting because I find it frustrating that we are working on this thing where it seems I am not being listened to and we are implementing something in a way that I recognise from my own past mistakes as a patently poor way of going about things.
But at the same time, I love the company I work for, and the pay is really good, and I am scared that if I quit I won’t find another job for a long time that will pay well enough to support myself and my girlfriend and our expenses.
Anyway. Point is, I agree with you, there will always be people trying to build these frameworks and what have you.
Overengineering confessions. He that is without sin among you, let him cast the first stone at her.
There’s a seductive aspect to abstraction and generalization. But I don’t even think that’s what makes these things so bad in practice. It’s other, more trivial things, like losing stack traces, imposing of types and flow control that the author didn’t anticipate, but pains the user tremendously.
We don’t really have good measurements for - and often overlook those aspects - which causes us collectively to suffer only after a great commitment of time and labor. I’m pretty convinced that complexity isn’t just mentally confusing but actually hard measurable, as long as we have language to describe it and a well tuned skepticism towards unnecessary layers of indirection. Function coloring is one such attempt, imo, at explaining the great costs of something which looks innocent.
Good abstraction is the foundation for most of what we do.
Bad abstraction is worse than no abstraction.
Not everything needs to be abstracted.
Ontology is bad abstraction (is a has a stuff).
Some people are bad at abstraction and some people are bad at writing business code; Both can be good coders.
Is “can do X” included in that definition (ie are you alluding to composition vs inheritance)? Can you elaborate on what constitutes good abstraction, in your book?
Exactly, that's one of the reasons I'm so happy where JS is as an indie dev (def not professionally though). JS has gone through so many "you need a factory factory factory", and now we have gone back to basic principles. A few examples I've lived:
- Browser incompatibilities. You couldn't just do X, because in other browsers X might behave differently. So you would write X blueprint and use an X factory that would auto-generate code for the different browsers. This applies to both JS, CSS and HTML BTW.
- Then the modules+bundlers came. Initially they were <script>, but when you had multiple you wanted to concatenate them for performance ofc, and in Node.js you wanted a way to import them. So a tool for each was created, then a tool on top of both was created, and thus a factory of factories of sorts was created.
- Then ES6+ came, which was similar to the first point so I won't bother you with it.
- Then Webpack and all of its derivates promised to solve all of the problems above, at the same time (with Babel and whatnot), and the era of mega-factories came to be.
Luckily nowadays we have standardize mostly around ES6+, and using ESM for imports/exports everywhere, so if you write plain JS and use ESM both in your code and in library code you don't need any more factories. You can still use a tool to bundle all your code, or to use more advanced coding paradigms like React*, but that's nowhere the peak of complexity we've lived.
That's one of the reasons I dislike TS BTW, because now that we are in "bliss plain JS" some people were not happy and had to add complex tooling again with TS.
*I draw the line here and declare that JSX is not JS, and thus this complexity thing doesn't apply there. If you are writing JSX you are writing it against CRA/Vite/Next, while plain JS you are writing it against the browser, so only things built on top of JSX, like TSX, can be considered factories from that point of view. If you think it's not fair, I'll argue it's as fair as JS, since in the end every browser is a "factory" of JS -> low-level code.
Which is precisely why a framework is necessary, but knowing how to write what you want without the framework is even more necessary.
If you only know how to code within the constraints of the framework, you're gonna fail for anything non-trivial. If you try to ditch frameworks entirely, same deal.
There is an art to translating whatever idea you have into large building blocks rather that coding it from small primitives.
Actually knowing how to code is important, but so is knowing how to take a problem and implement it without ever doing anything the framework authors didn't think of.
You might need a nasty hack like exporting a bitmap to a ramdisk and then importing it again to read a pixel value, to avoid messing with some nasty AI, or you might have a case where performance matters and you do want to mess with the buggy undocumented crap API.
It's almost like the idea that language shapes how you think. Frameworks are kind of like subsets or dialects of programming languages. If you actually know the framework well, you can often do stuff that seems like it would need low level control, in an idiomatic way that doesn't fight the framework.
I was thinking of building a Bluetooth device you can leave somewhere that alerts your phone should it be disturbed, as a portable security system. However the PineTime, an open source smartwatch, has all the features needed for $25, cheaper than almost any small quantity prototype.
Not sure if I'll ever get around to that project, but if I do, I probably won't be building any single function hardware just for it, especially not without being sure the whole idea is worth it.
> It's almost like the idea that language shapes how you think. Frameworks are kind of like subsets or dialects of programming languages. If you actually know the framework well, you can often do stuff that seems like it would need low level control, in an idiomatic way that doesn't fight the framework.
I think the analogy does not quite fit. A framework is certainly not a dialect. For me a dialect is a variant of the language in which you can accomplish almost the same.
A framework provides you with a couple of blocks for building something specific.
In terms of language, I'd say a framework is like technical jargon. Additional abstract terms that describe concepts useful in that domain. So domain experts don’t need to always explain everything from the beginning.
A framework is not a dialect, but a business context specific language.
You may re-use normal english words to have a new meaning. a bit like how companies like to have infinite initial acronym's for everything that nobody ever will understand outside the company.
There are quite a few titles which have appeared on the HN front page more than once. I've got an archive that's current as of a week or so back, and it shows 1,734 repeated titles.
The following 39 titles have appeared on the front page 5+ times, based on an exact text match, excepting a year indicator in parentheses, e.g., "(2023)". Note that the apostrophe glyph differs in the 2nd & 3rd entries for Peter Roberts AMAs:
1 10 OpenSSL Security Advisory
2 7 I'm Peter Roberts, immigration attorney who does work for YC and startups. AMA
3 7 I’m Peter Roberts, immigration attorney who does work for YC and startups. AMA
4 7 Richard Feynman and The Connection Machine
5 7 The Architecture of Open Source Applications
6 7 The TTY demystified
7 7 Why GNU grep is fast
8 7 You and Your Research
9 6 Bit Twiddling Hacks
10 6 Dictionary of Algorithms and Data Structures
11 6 How to be a Programmer: A Short, Comprehensive, and Personal Summary
12 6 The Bipolar Lisp Programmer
13 6 Why Lisp?
14 5 A Primer on Bézier Curves
15 5 A regular expression to check for prime numbers
16 5 Advanced programming languages
17 5 Akin's Laws of Spacecraft Design
18 5 Ask HN: Idea Sunday
19 5 Ask HN: What are you working on?
20 5 Beej's Guide to Network Programming
21 5 DNA seen through the eyes of a coder
22 5 Data Structure Visualizations
23 5 How Software Companies Die
24 5 How to Read Mathematics
25 5 How to Write a Spelling Corrector
26 5 Learning Advanced JavaScript
27 5 Notation as a Tool of Thought
28 5 Statistical Data Mining Tutorials
29 5 Structure and Interpretation of Classical Mechanics
30 5 Teach Yourself Programming in Ten Years
31 5 Ten Rules for Web Startups
32 5 Terms of Service; Didn't Read
33 5 The Book of Shaders
34 5 The Scientist and Engineer's Guide to Digital Signal Processing
35 5 The Tao of Programming
36 5 The case of the 500-mile email
37 5 Who Can Name the Bigger Number?
38 5 Why Lisp macros are cool, a Perl perspective
39 5 You can't tell people anything
A further 67 titles appear 4 times each, 259 appear 3x, and 2,120 appear twice.
("Front page" here means the archived HN front pages under the "past" link at the top of the page here.)
Data through 2023-06-21.
I could run the analysis based on the URL rather than title, but that would require parsing the raw HTML which I've yet to do.
Not all appearances are front-page appearances. And my very quick & dirty shell one-liner requires precise text matches.
"Why I Hate Frameworks" does appear six times on the front page, though with case and phrasing variants which mean that an exact text match won't pick it up:
Why I Hate Frameworks
Why I Hate Frameworks
Why I hate frameworks (2005)
Why I Hate Frameworks
[dupe] Why I Hate Frameworks (2005)
Why I Hate Frameworks (2005)
By my shell one-liner, it would have been counted as appearing four times (instances 1, 2, 4, and 6 above).
I could tweak the script by lowercasing (or title-casing) titles (I've a script that does the latter), and eliminating any instances of "[dupe]". While I'm at it, "[flagged]" and "[dead]" possibly as well, though I think the latter won't appear in the archive. And let's convert all apostrophe variants to a single apostrophe character (') (ASCII hex 0x27).
With those adjustments, I see "Why I Hate Frameworks" appearing six times, as expected, and there are 57 titles appearing 5+ times, rather more than the 39 initially posted above. There are 3,077 repeated front-page titles in total.
The one-liner, FWIW (rearranged to multiple lines):
"titlecase" itself is a sed script that uppercases words, with specific exceptions. I've just augmented it with a few more technology-related terms.
"parse.log" is the output of my first stage of parsing of the HN front page archive, which lists specific story properties in a tagged format, e.g., "Title:" "Date:" "Site:", etc.
1 14 I'm Peter Roberts, Immigration Attorney Who Does Work for YC and Startups. AMA
2 11 Richard Feynman and the Connection Machine
3 10 Openssl Security Advisory
4 10 The TTY Demystified
5 8 Why GNU Grep is Fast
6 7 Cool URIs Don't Change
7 7 How to Read Mathematics
8 7 The Architecture of Open Source Applications
9 7 You and Your Research
10 6 -2000 Lines of Code
11 6 A Primer On Bézier Curves
12 6 Advanced Programming Languages
13 6 Bit Twiddling Hacks
14 6 Dictionary of Algorithms and Data Structures
15 6 How Not to Sort by Average Rating
16 6 How to Be a Programmer: a Short, Comprehensive, and Personal Summary
17 6 How to Write a Spelling Corrector
18 6 Keep Your Identity Small
19 6 Ten Rules for Web Startups
20 6 The Bipolar Lisp Programmer
21 6 The Tao of Programming
22 6 Why I Hate Frameworks
23 6 Why Lisp?
24 5 A Regular Expression to Check for Prime Numbers
25 5 A Spellchecker Used to Be a Major Feat of Software Engineering
26 5 Akin's Laws of Spacecraft Design
27 5 Ask HN: Idea Sunday
28 5 Ask HN: What Are You Working On?
29 5 Ask HN: Who's Hiring?
30 5 Beej's Guide to Network Programming
31 5 Data Structure Visualizations
32 5 Dna Seen Through the Eyes of a Coder
33 5 Game Programming Patterns
34 5 How Software Companies Die
35 5 How to Become a Good Theoretical Physicist
36 5 How to Design Programs, Second Edition
37 5 Latency Numbers Every Programmer Should Know
38 5 Learn C and Build Your Own Lisp
39 5 Learn You a Haskell for Great Good
40 5 Learning Advanced Javascript
41 5 Let's Build a Compiler
42 5 Notation As a Tool of Thought
43 5 Statistical Data Mining Tutorials
44 5 Structure and Interpretation of Classical Mechanics
45 5 Teach Yourself Programming In Ten Years
46 5 Terms of Service; Didn't Read
47 5 The Book of Shaders
48 5 The Case of the 500-Mile Email
49 5 The Early History of Smalltalk
50 5 The Scientist and Engineer's Guide to Digital Signal Processing
51 5 What ORMs Have Taught Me: Just Learn SQL
52 5 Who Can Name the Bigger Number?
53 5 Why I Left Google
54 5 Why Lisp Macros Are Cool, a Perl Perspective
55 5 Why Open Source Misses the Point of Free Software
56 5 Why to Start a Startup In a Bad Economy
57 5 You Can't Tell People Anything
NB: I've further tweaked my scripts (and titlecasing) which results in a few minor changes to the results, though the above list remains highly illustrative.
I think I've spammed this thread enough for now ;-)
The simplest route to that for now would be to search the titles via Algolia, sorting by popularity. I could I suppose gin up the URLs for that, though as I've already noted, I think I've spammed this particular thread enough with long-list comments. (HN prizes intellectual curiosity, and whilst a few tables might meet that criterion, I think I'm pushing the limits.)
The difference between my data & analysis and Algolia is that Algolia doesn't itself report on either front-page-specific items, or on stories which have been repeated. But given a list of front-page stories, or repeated-front-page stories, you can search Algolia ... to surface all instances of those stories. The front page will in general have
If you're suggesting I list the URLs themselves directly ... as I'm working with the archive data, I don't have that readily available.
My current workflow is, roughly:
- crawl (or update) the front-page archive
- rerender the captured HTML as plain text, using w3m's `-dump` flag
- parse that text into a tagged multi-line-per-record format with the raw title line, parsed title, date (and several sub-element parsings of that), site ( as reportedd by HN), points, submitter, comments, and (artefact of the original question I'd sought to answer) any US cities or states mentioned
- create various reports and abstracts based off of that. "hn-titles", "date summary" (mostly the parsed data arranged on one line for easier awk processing), cities (US and "globally significant") and US states reports, etc.
Conspicuously absent in the parsing (3rd step) are both the full article URL, and the HN post URL.
I've got those, in the raw HTML, but I'd need to go through that and parse the original which up until now has been Too Much Work given what I can do with what I have now.
And if you're wondering how many votes are required to make the front page, here's a summary, by year, of the univariate stats for votes for the 30th story per page, that is, the lowest-ranked:
Note that the first three years were pretty low (min = 1, mean = 2.48, for 2007), but goinng back 5 years a story with > 23 points could have made the front page. There are also a few days with < 30 stories, all occurring in 2007 if memory serves.
(This is my first time seeing these particular stats, another analysis I'd been thinking of doing for a while. I had calculated the delta between 1st and 30th ranked stories going back some time. Also the variance by day of week, which is also fairly significant.)
This is the fun of posting my work publicly. Someone will pick it apart, and then it's a challenge to see if I can address the concerns.
I knew my first attempt was quick-and-dirty. It took a few minutes to improve that a lot, a few hours to track down numerous other issues (mostly involving title-casing exceptions, and adding more terms to that script which should either not be titlecased (e.g., "DNA", or which are mixed-case (e.g., iPhone), or which are ambiguous and should be treated differently in different cases (e.g., "us", which might be a first-person plural pronoun, or an abbreviation for "United States").
For the latter, I determined that "US" appearing either immediately after "the" or at the start of a title was virtually always the United States sense of the string. I've enshrined that in `titlecase`, though there are probably some other terms that tend to occur before or after the term which could be used to further disambiguate, say, "US Congress", "US Senate", or "US Law", for example. The additional gain from those is small.
If I were writing an AI then it might incorporate those weights, but this is just a simple sed script...
I recently started getting into Javascript 2D game programming.
MDN has a nice simple straightforward tutorial[1] on how to make a Breakout game in pure Javascript. Having read this tutorial, it all fits my brain. It's simple and I understand it.
There are also lots of frameworks you can use, e.g. Excalibur, which also has a breakout game tutorial[2]. This does not fit my brain: there are vast number of classes to learn, and how everything fits together is not obvious at all.
While I was reading the MDN tutorial I was thinking to myself how I could easily build a framework to automate a lot of the stuff. (No doubt many others thought the same!) If I did build such a framework I would understand it well. It would fit my brain. But would anyone else understand it? Possibly not.
I suspect that what makes a framework easy to learn is, above everything else, good documentation.
Yup that’s why I like babylonjs. It’s not so much good documentation but that the docs try hard to have working codepen style examples for almost everything you can think of doing with it. Code as documentation. Contrast with a lot of python docs where you usually get a docpage telling you what the arguments are and the return type but nothing else.
If I had to guess I would say there is a common resonating theme this strikes with many developers:
It seems many developers tire of working for employers who immediately bend to the will of the least competent employee by immediately jumping into unnecessary abstraction stupidity and/or they tire of their least competent peers defining the metrics for success and product quality.
Some people can program. Other people chase trends and call it programming.
Just looking at this listing, without looking at the comments in each one, this seems to have a sustained resonance.
Maybe I’m biased–it certainly resonates with me!