I disagree, actually. There are plenty of languages, and even visual programming (via flow-diagrams, like Unreal Engine's "Blueprint" and Blender's shader flow diagrams), for those who just want to play around. For people who want to write a quick and dirty script, languages like python make it very easy already (relative to what they actually do).
> Programming COULD use [...] removal of barriers
Absolutely agree with this, though. There's an unnecessary elitism in many places that really needs to go..
> Development is sometimes hard and requires hard work to do right by people.
This is *so* important for these people to understand. There are languages and domains where the "elitism" is fully justified. If someone decides they want to write a high performance, easy to use, cross platform native application and complain about C++ or Rust being too complicated, then they should find an easier job. There is justified and unjustified elitism, and there are domains which could use, if anything, even more "complication" and more specifications, more "barriers" to ensure higher quality.
Flash was terrible for all sorts of other reasons. But it did demonstrate that there is a class of incredibly creative people out there who can create amazing things, but not on the command line, and not using the tools currently available.
How do we get them doing that again?
I'm serious. I don't think there can be another "explosion of creativity" of the (relative) magnitude of Flash, because people now express themselves by recording videos. It's both easier and more social than making interactive software, even with Flash.
?? What kind of bizarre red-pill nonsense is this? You think all those interactive Flash microsites were to impress girls? lol
I disagree. I follow a lot of game developers and you'd be hard pressed to say they don't do high-performance corss-platform native application development. They almost universally think C++ (and by extension Rust) are too complicated. They generally use C++ anyway because that's the industry standard, but they think there is definitely a conceptually less-complicated way to do things.
See: Jonathan Blow and Casey Muratori, for instance. The former is so sick of C++ he's making his own programming language, and the latter routinely complains about C++'s complexity and eschews all but the simplest features of it.
C++'s complexity is also a product of design choices like using templates to do both generics and metaprogramming, which in hindsight probably made things much harder than they needed to be. Rust has the benefit of being able to avoid decades of C++'s missteps.
However, I do know that a lot of objections to it from the people I follow are around the borrow checker and both the friction and high[0] compile times it causes.
[0] to put that in context, Jon is frequently annoyed by the sub-second linking time incurred by LLVM because it is more than an order of magnitude longer than his largest program (~60k line game, IIRC) takes to compile.
What makes it worse is that complication doesn't even exist for "good" technological reasons; it only exists for inertial, industrial reasons like compatibility with C and 1980s naivete -- both because of and in spite of it, since, like the other person said, even more complexity was bolted on to try to force new lessons without breaking backwards compatibility.
I used to love C++, since I thought its complexity was somehow, fundamentally necessary for a lang to be a "fancier C". Once I learned Rust and found out that was not true, I now hate C++ with a passion and can't wait until it completely displaces C++, which it should do ASAP[0]. :D
THAT SAID, some people (who are much better programmers than I am), say that C++ is the most expressively versatile language around, which is at least a "good" technological reason for its enduring existence. That's one I can't relate to, though, since the people who are saying that tend to be talking about very advanced, byzantine aspects of C++ that I never got to.
This has happened pretty regularly for decades at this point, people hate on c++ and think they have the silver bullet approach to do things better. They spend a few years on it, and it fails to get much traction.
There is a network effect around c++, sure. But industry standards are there for reasons, and usually most of them have a core at least that is sensible. People keep coming back to c++ mostly because it works, and it turns out often if you start with a safer and cleaner language you get 80% of the way there much faster, but a lot of the 20% that's left over is performance related and you just can't get there no matter how hard you try.
So from a business point of view, the pain level of c++ (and associated costs) is somewhat known, but most other approaches trade that off against project risks people just aren't willing to take.
It's not inherently crazy, even in 2021 to start a new high performance project in c++. Obviously the exact requirements matter, but there is a subset of what it can do that we don't really have a obviously good replacement for. What would be crazy is starting a new project in it that doesn't really need any of thee things it's good at.
Graphical programming languages, removing barriers to learning, etc. They've been chugging away for decades and visual programming, Blender, Blueprints, Scratch, etc are all we got out of it.
Does the article writer just think research doesn't exist? That CS sprouted from existence fully formed as a web browsing experience?
More like 50 years. :)
I'm not sure I want to code like that, but damn is it impressive.
Blueprints and Scratch are widely used and are important tools. Your comment sounds very dismissive, and if you meant to be, then I think you’re unaware of their impact and reach.
That said I don’t fully buy the author’s exact argument:
- node.js local install IS for a traditional programming environment on the CLI - you don’t need node built in when you have the browser - plenty of web IDEs exist that do as the author wishes… run node code in the browser while also editing it.
If you really hate `git checkout -b`, ship `git make-branch` that suits your taste. You can even package it as a trivial script to redistribute if you wanted.
Programmers do things by writing code, compiling, deploying, etc... so the notion of customizing an app through anything that looks like their workflow seems fine to them.
OTOH I write code for a living and I often hate the tools we use...
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.
The result has been a massive proliferation of perpetually-junior engineers writing code and rising in ranks to run things.
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.)
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 ) 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 ) or entire apps, like with JHipster ( https://www.jhipster.tech/ ) or create-react-app ( 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
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
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...
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.
> 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
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.
+ 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.
+ 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).
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 (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.
> 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.
Well I said 'minimal set of dependencies' not 'minimal dependencies'. My text wasn't meant to make a point for small libraries or for implementing everything inside the project, but just to point out the important factor of dependency management as part of programming, which I felt was missing in this discussion.
Of course if there is some big framework that is well maintained, possible already used by other software components that might be already available on the device of the end user, fulfills all business/project requirements and you might end up using it for more the just one function, then great! That also means you might not add many other random small dependencies to dependency set, now or in the future and that set might stay minimal.
But if there is something that is not part of the big framework, and easy to get wrong, then of course you should add some dependency that does it for you under all these deliberations instead of trying, and possible failing, to do it yourself.
You should however step back from this and reconsider, if you start adding libraries for just string padding and the like.
TFA is a classic x-y problem. Author says they want node in the browser. What they really want is something they can quickly be productive in, a one stop shop. Author is describing an IDE.
Many problems don't go away and don't become easier just beacuse you shove them under the carpet into a library. A lot of developers use libraries as an excuse to NOT THINK about the issues and ignore their existence not to save work. There's a fundamental difference between "I understand the problem and I know that library X will give me a good solution with low amount of work" and "This problem is hard, I'll shovel in another library and keep my fingers crossed that it does a good job at it."
It's saving work vs. saving thinking. First one is ok. Second one is not.
And for a different reason: I find that programmers who think like this, are also lazy when it comes to respecting the user. They're lazy when it comes to supporting accessibility. They're lazy when it somes to properly supporting i18n and making experience great for non-Americans. They're lazy when it comes to respecting privacy and not burning 8GB of RAM just to render a webshop frontend.
They'll say "this is hard" and add Facebook SDK to do things for them. They'll say "this is hard" and make the page inaccessible for people that don't own a 4000$ 16" MBP and has perfect vision.
That's the core issue of this attitude for me, which I'm seeing by too many people I mentor. Development is sometimes hard and requires hard work to do right by people.