4 ms·

> Programming COULD use a lot of simplification I so completely disagree. Writing JavaScript is already so simple that almost nobody knows how to do it any mor

> Programming COULD use a lot of simplification I so completely disagree. Writing JavaScript is already so simple that almost nobody knows how to do it any more. You can download a colossal framework and a billion NPM packages to write some completely unoriginal CRUD application and bitch about how hard life is. Fearing writing original code is the name of the game.

KronisLV 6y ago
But isn't using the code that people smarter/more proficient than you have developed a rather good way to go about things? If not, where do you draw the line? Should you write your own business logic? Should you write your own logic to allow implementing that business logic (e.g. request parsing, validators, data transformations and processing etc.)? Or maybe you should write your own web framework that routes and handles HTTP(S) requests? Or maybe the entire ORM (if you're using one in the first place) as well? But that ORM probably uses JDBC/ODBC or some other driver as well, and the HTTP(S) requests also can be processed because of some additional code and libraries. Should you write those as well? What about the operating system itself, and the code that allows it to interface with the hardware? What about the kernel? I don't necessarily agree with the OP's point about making a browser that has Node.js packaged (though it's a novel idea), but i definitely agree that defaults and tools matter. Tools like XAMPP ( https://www.apachefriends.org/index.html https://www.apachefriends.org/index.html ) or the CLIs for automatically generating projects and helping automate everything from creating project files, like in Ruby on Rails Generators ( https://guides.rubyonrails.org/generators.html https://guides.rubyonrails.org/generators.html ) or entire apps, like with JHipster ( https://www.jhipster.tech/ https://www.jhipster.tech/ ) or create-react-app ( https://reactjs.org/docs/create-a-new-react-app.html https://reactjs.org/docs/create-a-new-react-app.html ) all seem to decrease the chance of human error and make development safer, more consistent and easier. Even IDEs that are aware of the specifics of the frameworks you're using can be very useful! In addition, they can improve the developer experience (DX) a whole bunch, since in larger projects time can be invested to address common problems. For example, see Dylan Beattie's conference talk on the topic: https://youtu.be/lFRKrHE8oPo?t=431 https://youtu.be/lFRKrHE8oPo?t=431 I've seen people trying to write their own web frameworks and most of the time the results have been poor, both in understanding the system and maintaining it in the long term, in addition to which you can't hire people that are familiar with "Random Company's Web Framework". Unoriginality is good for being to maintain the project, as far as i'm concerned. Here's another conference talk, by Venkat Subramaniam about deciding between using existing code or writing your own: https://youtu.be/OheeK7Ux2-8?t=727 https://youtu.be/OheeK7Ux2-8?t=727
- chme 6y ago
  > But isn't using the code that people smarter/more proficient than you have developed a rather good way to go about things? One big task about programming is handling dependencies and thinking about assumptions. Before even beginning to write any code, you have to think about these things: - What environment do I expect the end user uses? Are there already some libraries I can use as well installed? - Do I need a GUI, or should it also run on headless devices? TUI or just CLI? - Does it make sense to use a big comprehensive framework or rather a bundle of minimal components? - Does a specific feature really need an additional dependency or can I rather implement something on top of the already existing dependencies? - How good is the maintenance of a library, code quality and is the license compatible? - and many more... All of those are very difficult questions and require often some crystal balls to get right. Lazy people might just add any dependency some stackoverflow or other random search result says, without thinking about these. While good developers think about each one and try to find a minimal set of them.
  - KronisLV 6y ago
    That's a fair argument to make, however i'm not sure that i'm able to entirely agree to this. > While good developers think about each one and try to find a minimal set of them. (tl;dr at the bottom, things up to "In short, " are merely my experience, which is entirely subjective) For example, suppose that i'm working on a Java project and i want to do some non-trivial operations with the filesystem. In this instance, my options for implementing the functionality would be as follows: 1. Attempt to do it myself by using the standard library 2. Attempt to find a really specific library that allows me to do what i need 3. Attempt to use one of the larger libraries out there, that provide a variety of related functionality, which may or may not be useful Each of them definitely should be evaluated, but for the most part, i've found the following to be true about these approaches: 1. Attempt to do it myself by using the standard library + Will be easily customizable, because no source/recompilation will be necessary for an external library (though mostly a problem of the toolchain and approaches to including libraries). + Will result in a small distribution size, since there won't be redundant code included. - The code mostly won't have good test coverage, since i cannot spare the time because of business/bosses needig functionality ASAP. Neither will i be able to address the technical debt that might arise from this solution, or throw out a sub-optimal solution and rewrite it until i get it right. Ideally this wouldn't be a problem, but i'm afraid that this is usually the case. - The documentation will be sub-par, since code itself doesn't provide many mechanisms for showing examples on how to use it (as opposed to a Wiki/sandbox), even in the case of "self-documenting code", non-trivial concepts will still require code comments, which will also need to be kept up to date by someone who'll need to edit the code. Onboarding will be more difficult, because initially noone will be familiar with the solution. - Time spent creating bespoke solutions will prevent me from implementing other solutions and addressing other concerns with the limited time i have. In addition, bugs could arise, since i'd miss certain aspects that people who are more proficient in working with IO would notice and address. 2. Attempt to find a really specific library that allows me to do what i need + Will result in a small distribution size, since there won't be too much redundant code included. - More often than not, minimal dependencies can result in many of the above problems (especially problematic with documentation, since i wouldn't even have had written the code in the first place). - In addition, minimalistic solutions often have relatively few contributors, which can result in them becoming abandoned some time down the road. Maybe not too important for small libraries that can be rewritten, but eventually you'll end up with unmaintained dependencies which will need addressing. 3. Attempt to use one of the larger libraries out there, that provide a variety of related functionality, which may or may not be useful + Will usually be actively maintained (for example, https://github.com/apache/commons-io has 70 contributors and 360k users). + Will usually also have reasonable test coverage (the library above has 89%, according to GitHub) + Will usually have a rather good documentation that's updated by others (sometimes in the form of a separate website, like https://commons.apache.org/proper/commons-io/) + Can easily be Googled with plenty of common problems (some of which are almost inevitable) addressed. This will also help others, who need to work with said code. + Maintenance and technical debt won't need to be addressed in house. Oftentimes it'll be as easy as bumping up the version number and running the tests surrounding the integration (if any exist). - Will probably include lots of bloat, which may or may not have a significant impact on the bundle size of your project. - Will most likely increase the attack surface of your project in some way. - Will also be difficult to audit and really get to know in entirety (if not impossible). In short, i don't think that how "minimal" dependencies are should be the deciding factor when choosing them, but rather the results of deliberation of the points that you've described above. In my experience, i've found that more often than not, counting on existing and popular frameworks/libraries/approaches is the best way to go. Though this is from the perspective of someone creating mostly business oriented solutions for external clients, thus i'm biased because of time/resource limitations and such. There was actually a rather humorous presentation a while back and while the best video i can find of it is still in pretty bad quality: https://youtu.be/AUYPnxv0yss https://youtu.be/AUYPnxv0yss (couldn't find the exact timestamp) one of the things that stuck to me was the suggestion that you should use whatever language/tool/framework that your friends/colleagues use, if possible. Essentially - use boring technology, that will be easy to reason about and that will help you more often than not.
chme 6y ago
> I so completely disagree. Writing JavaScript is already so simple that almost nobody knows how to do it any more. You can download a colossal framework and a billion NPM packages to write some completely unoriginal CRUD application and bitch about how hard life is. Fearing writing original code is the name of the game. The reason for this seems more that there a many coders that forget about the task of vetting their dependencies, which is a big part of programming. Just learning a language does not give you the discipline required to be a good software engineer.
- sidlls 6y ago
  I don’t think it’s because they forgot to vet their dependencies. I think it’s because there’s a culture of “just get it done” that fosters short cuts, and it’s coupled closely with a culture of worship around open source as if it should be implicitly trusted. The result has been a massive proliferation of perpetually-junior engineers writing code and rising in ranks to run things.
  - potta_coffee 6y ago
    The worst kind of toxicity is when your senior engineers and team leads are actually junior engineers.
    - sidlls 6y ago
      It’s hard to be too hard on them though: they never had proper mentorship as junior engineers and their practices are reinforced by modern practices. There is a worse toxicity in my opinion: when engineers at all levels religiously adhere to fads or practices just because others do (see: OO, TDD, etc.)

KronisLV 6y ago

But isn't using the code that people smarter/more proficient than you have developed a rather good way to go about things? If not, where do you draw the line? Should you write your own business logic? Should you write your own logic to allow implementing that business logic (e.g. request parsing, validators, data transformations and processing etc.)? Or maybe you should write your own web framework that routes and handles HTTP(S) requests? Or maybe the entire ORM (if you're using one in the first place) as well? But that ORM probably uses JDBC/ODBC or some other driver as well, and the HTTP(S) requests also can be processed because of some additional code and libraries. Should you write those as well? What about the operating system itself, and the code that allows it to interface with the hardware? What about the kernel? I don't necessarily agree with the OP's point about making a browser that has Node.js packaged (though it's a novel idea), but i definitely agree that defaults and tools matter. Tools like XAMPP ( https://www.apachefriends.org/index.html https://www.apachefriends.org/index.html ) or the CLIs for automatically generating projects and helping automate everything from creating project files, like in Ruby on Rails Generators ( https://guides.rubyonrails.org/generators.html https://guides.rubyonrails.org/generators.html ) or entire apps, like with JHipster ( https://www.jhipster.tech/ https://www.jhipster.tech/ ) or create-react-app ( https://reactjs.org/docs/create-a-new-react-app.html https://reactjs.org/docs/create-a-new-react-app.html ) all seem to decrease the chance of human error and make development safer, more consistent and easier. Even IDEs that are aware of the specifics of the frameworks you're using can be very useful! In addition, they can improve the developer experience (DX) a whole bunch, since in larger projects time can be invested to address common problems. For example, see Dylan Beattie's conference talk on the topic: https://youtu.be/lFRKrHE8oPo?t=431 https://youtu.be/lFRKrHE8oPo?t=431 I've seen people trying to write their own web frameworks and most of the time the results have been poor, both in understanding the system and maintaining it in the long term, in addition to which you can't hire people that are familiar with "Random Company's Web Framework". Unoriginality is good for being to maintain the project, as far as i'm concerned. Here's another conference talk, by Venkat Subramaniam about deciding between using existing code or writing your own: https://youtu.be/OheeK7Ux2-8?t=727 https://youtu.be/OheeK7Ux2-8?t=727

chme 6y ago
> But isn't using the code that people smarter/more proficient than you have developed a rather good way to go about things? One big task about programming is handling dependencies and thinking about assumptions. Before even beginning to write any code, you have to think about these things: - What environment do I expect the end user uses? Are there already some libraries I can use as well installed? - Do I need a GUI, or should it also run on headless devices? TUI or just CLI? - Does it make sense to use a big comprehensive framework or rather a bundle of minimal components? - Does a specific feature really need an additional dependency or can I rather implement something on top of the already existing dependencies? - How good is the maintenance of a library, code quality and is the license compatible? - and many more... All of those are very difficult questions and require often some crystal balls to get right. Lazy people might just add any dependency some stackoverflow or other random search result says, without thinking about these. While good developers think about each one and try to find a minimal set of them.
- KronisLV 6y ago
  That's a fair argument to make, however i'm not sure that i'm able to entirely agree to this. > While good developers think about each one and try to find a minimal set of them. (tl;dr at the bottom, things up to "In short, " are merely my experience, which is entirely subjective) For example, suppose that i'm working on a Java project and i want to do some non-trivial operations with the filesystem. In this instance, my options for implementing the functionality would be as follows: 1. Attempt to do it myself by using the standard library 2. Attempt to find a really specific library that allows me to do what i need 3. Attempt to use one of the larger libraries out there, that provide a variety of related functionality, which may or may not be useful Each of them definitely should be evaluated, but for the most part, i've found the following to be true about these approaches: 1. Attempt to do it myself by using the standard library + Will be easily customizable, because no source/recompilation will be necessary for an external library (though mostly a problem of the toolchain and approaches to including libraries). + Will result in a small distribution size, since there won't be redundant code included. - The code mostly won't have good test coverage, since i cannot spare the time because of business/bosses needig functionality ASAP. Neither will i be able to address the technical debt that might arise from this solution, or throw out a sub-optimal solution and rewrite it until i get it right. Ideally this wouldn't be a problem, but i'm afraid that this is usually the case. - The documentation will be sub-par, since code itself doesn't provide many mechanisms for showing examples on how to use it (as opposed to a Wiki/sandbox), even in the case of "self-documenting code", non-trivial concepts will still require code comments, which will also need to be kept up to date by someone who'll need to edit the code. Onboarding will be more difficult, because initially noone will be familiar with the solution. - Time spent creating bespoke solutions will prevent me from implementing other solutions and addressing other concerns with the limited time i have. In addition, bugs could arise, since i'd miss certain aspects that people who are more proficient in working with IO would notice and address. 2. Attempt to find a really specific library that allows me to do what i need + Will result in a small distribution size, since there won't be too much redundant code included. - More often than not, minimal dependencies can result in many of the above problems (especially problematic with documentation, since i wouldn't even have had written the code in the first place). - In addition, minimalistic solutions often have relatively few contributors, which can result in them becoming abandoned some time down the road. Maybe not too important for small libraries that can be rewritten, but eventually you'll end up with unmaintained dependencies which will need addressing. 3. Attempt to use one of the larger libraries out there, that provide a variety of related functionality, which may or may not be useful + Will usually be actively maintained (for example, https://github.com/apache/commons-io has 70 contributors and 360k users). + Will usually also have reasonable test coverage (the library above has 89%, according to GitHub) + Will usually have a rather good documentation that's updated by others (sometimes in the form of a separate website, like https://commons.apache.org/proper/commons-io/) + Can easily be Googled with plenty of common problems (some of which are almost inevitable) addressed. This will also help others, who need to work with said code. + Maintenance and technical debt won't need to be addressed in house. Oftentimes it'll be as easy as bumping up the version number and running the tests surrounding the integration (if any exist). - Will probably include lots of bloat, which may or may not have a significant impact on the bundle size of your project. - Will most likely increase the attack surface of your project in some way. - Will also be difficult to audit and really get to know in entirety (if not impossible). In short, i don't think that how "minimal" dependencies are should be the deciding factor when choosing them, but rather the results of deliberation of the points that you've described above. In my experience, i've found that more often than not, counting on existing and popular frameworks/libraries/approaches is the best way to go. Though this is from the perspective of someone creating mostly business oriented solutions for external clients, thus i'm biased because of time/resource limitations and such. There was actually a rather humorous presentation a while back and while the best video i can find of it is still in pretty bad quality: https://youtu.be/AUYPnxv0yss https://youtu.be/AUYPnxv0yss (couldn't find the exact timestamp) one of the things that stuck to me was the suggestion that you should use whatever language/tool/framework that your friends/colleagues use, if possible. Essentially - use boring technology, that will be easy to reason about and that will help you more often than not.

chme 6y ago

> I so completely disagree. Writing JavaScript is already so simple that almost nobody knows how to do it any more. You can download a colossal framework and a billion NPM packages to write some completely unoriginal CRUD application and bitch about how hard life is. Fearing writing original code is the name of the game. The reason for this seems more that there a many coders that forget about the task of vetting their dependencies, which is a big part of programming. Just learning a language does not give you the discipline required to be a good software engineer.

sidlls 6y ago
I don’t think it’s because they forgot to vet their dependencies. I think it’s because there’s a culture of “just get it done” that fosters short cuts, and it’s coupled closely with a culture of worship around open source as if it should be implicitly trusted. The result has been a massive proliferation of perpetually-junior engineers writing code and rising in ranks to run things.
- potta_coffee 6y ago
  The worst kind of toxicity is when your senior engineers and team leads are actually junior engineers.
  - sidlls 6y ago
    It’s hard to be too hard on them though: they never had proper mentorship as junior engineers and their practices are reinforced by modern practices. There is a worse toxicity in my opinion: when engineers at all levels religiously adhere to fads or practices just because others do (see: OO, TDD, etc.)