4 ms·

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

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. Maybe I’m biased–it certainly resonates with me!

7speter 3y ago
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. Or maybe thats just me.
- codetrotter 3y ago
  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.
  - klabb3 3y ago
    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.
    - paiute 3y ago
      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.
      - klabb3 3y ago
        > Ontology is bad abstraction (is a has a stuff). 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?
  - franciscop 3y ago
    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.
- sublinear 3y ago
  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.
  - eternityforest 3y ago
    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.
    - mo_42 3y ago
      > 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.
cabalamat 3y ago
> it certainly resonates with me! 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. [1]: https://developer.mozilla.org/en-US/docs/Games/Tutorials/2D_Breakout_game_pure_JavaScript https://developer.mozilla.org/en-US/docs/Games/Tutorials/2D_... [2]: https://excaliburjs.com/docs/getting-started/ https://excaliburjs.com/docs/getting-started/
- davedx 3y ago
  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.
dredmorbius 3y ago
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.
- gcoladon 3y ago
  Why doesn't "Why I Hate Frameworks" appear in your list? From dang's post it looks like that exact title has appeared 8 times? Possibly related: have you considered making your aggregator ignore punctuation and case in addition to the year indicators?
austin-cheney 3y ago
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.
- Sophira 3y ago
  There are also other articles along the same lines, such as Joel Spolsky's 2001 article "Don't Let Architecture Astronauts Scare You": https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect... It's basically the same idea but coming from a different angle, and it resonated with me enough that I still remember it.

7speter 3y ago

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. Or maybe thats just me.

codetrotter 3y ago
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.
- klabb3 3y ago
  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.
  - paiute 3y ago
    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.
    - klabb3 3y ago
      > Ontology is bad abstraction (is a has a stuff). 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?
- franciscop 3y ago
  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.
sublinear 3y ago
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.
- eternityforest 3y ago
  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.
  - mo_42 3y ago
    > 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.

cabalamat 3y ago

> it certainly resonates with me! 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. [1]: https://developer.mozilla.org/en-US/docs/Games/Tutorials/2D_Breakout_game_pure_JavaScript https://developer.mozilla.org/en-US/docs/Games/Tutorials/2D_... [2]: https://excaliburjs.com/docs/getting-started/ https://excaliburjs.com/docs/getting-started/

davedx 3y ago
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.

dredmorbius 3y ago

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.

gcoladon 3y ago
Why doesn't "Why I Hate Frameworks" appear in your list? From dang's post it looks like that exact title has appeared 8 times? Possibly related: have you considered making your aggregator ignore punctuation and case in addition to the year indicators?

austin-cheney 3y ago

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.

Sophira 3y ago
There are also other articles along the same lines, such as Joel Spolsky's 2001 article "Don't Let Architecture Astronauts Scare You": https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect... It's basically the same idea but coming from a different angle, and it resonated with me enough that I still remember it.