I think there is a perception that if problems like that are first solved in a proprietary service rather than in core tools, it may in extension tie the ecosystem to that service, while at the same time lessen the need to solve problems in the foundation. Even if this perception is wrong, I think it exists and why you see concerns raised in this thread.
Some problems are hard, common and already solved. Sometimes solving these problems yourself adds no unique value to your product. In that case, you should just use a well-reviewed external ecosystem package.
A large project will run into many of these problems. It is a waste to re-invent the wheel because a cool new framework has too few pre-made wheels.
Exactly. They seem to be creating unsolvable, strawman problems instead of assuming we start with the middleware approach to getting things to work together. And there's both very efficient and very robust tooling available for that these days.
The problem is that those tools, while solving some problems in the development stage, create a host of other problems at other points in time: first install, building, deployment, maintenance...
I think they are too invested im hard problems, but not invested enough in tedious problems.
I don't want a new language, or a new preprocesser, or a new way of thinking about programs... I just want a one click way to take a folder of HTML that looks like a static site, and package it up into cross platform apps with all the proper API access.
I don't care about cryptocurrency and global decentralized databases, I just want to be able to run a site by buying a NAS appliances, putting files on it, and sharing the QR code on it without any signups and cloud accounts.
The hard problems are mostly solved. There's probably some long dead random github repo that does anything you want. They're just not packaged for all platforms and maintained professionally.
I don't need a phone without any binary blobs at all... I just want a mesh network feature and a fair trade stamp.
Because... it sucks to maintain something novel even if it's all just pieced together from npm. It sucks to be the one responding to issues. It sucks to actually run a project and keep track of devops stuff.
All the tech has been invented dozens of times over, but never polished, and always ruined with some unnecessary immutable log feature or performance destroying random access low latency routing thing like IPFS has.
Nah, they think they understand, and run with an under-informed opinion on something they have no to little real-world experience with until they've replaced the client's original concerns with something that's oversimplified for the sake of shoving into this or that software architecture pattern.
There are of course trans-disciplinary efforts done right but those take orders of magnitude more time than your typical VCs or zealous ladder-climbers allow in development timelines.
Software developers have been bailed out from having to confront this situation up to now because those who ask for software tend to ask for extremely simple workflow-helper type stuff rather than domain-expert-amplifier type stuff (see: pretty much every SaaS webapp ever). But the low-hanging fruit are getting pretty sparse by this point in the bubble.
Yep! And you need someone to help fix bizarre bugs in core that only crop up in your own weird environment. With support that's quick & easy, but otherwise you have to form your own dev team to specialize in it, making it costlier.
I think when something is built by several people, catering to outside interests, you end up with more churn, bloat, inconsistency, instability, etc. But your specific need has a better chance if being addressed. When something (like Elm) is built in a silo, you end up with less churn, bloat, instability, inconsistency. We forget how we got these nice things, and when we want something NOW we get cranky about the development model. So, as a developer with 20+ years of experience I can say that EVERYTHING (tools, languages, paradigms) is shitty in some ways, and I vastly prefer the ways that Elm and ecosystem are shitty.
Honestly, not necessarily--there are often many ways to solve a given software problem. If someone else has a vision for the software and a plan to achieve it as a team, as long as I can see that it is looks like a viable alternative I'm generally happy to go along with it. Far better than flapping in the breeze with nobody providing clear guidance or input, in my opinion!
When I read the concerns addressed here I cannot help but think of the end user (not a developer per say). There is an entire category of EUSE products that try to accommodate these concerns, however fall quite short. We need to rethink the entire paradigm of development, define sectors that need specialized product concerns (embedded vs games vs cloud) and build holistic ecosystems around them. There are startups doing this, yet how to categorize these types of tools is still not established; therefore hard to point at.
OK I think I sort of understand what you are saying.
Such as, for example, why don't we have an easy to use program like Dropbox that is just built in to every operating system, or freely available and in common use? Rather than having a bunch of people rely on this commercial system just to transfer files or make them available on the internet.
I agree that we are reinventing things an amazing number of times. I think we have at least 5 times as many crappy ways to accomplish basic things as we need. And certainly more cohesion is called for.
On the other hand I think that people often don't appreciate how changes to fundamental approaches are the best way to solve problems because problems are often structural or caused by the way the issues are framed.
I agree that there is too much reinventing the wheel and fragmentation of effort. I don't believe that Node.js is a good example of that. Although 54000 modules is too many and there is quite a lot of redundancy and crap in there. But having a very easy way to publish, consume and search for modules as well as instantly handle dependencies is a step forward.
Ecosystems die without adoption. A runtime that plugs its ears to the practical needs of users is a runtime that nobody but enthusiasts ever use. And you can't build any kind of sustainable business on an enthusiast-only runtime, VC or no VC.
That is one important aspect, absolutely. But I don't think it's the main point. There are normally good reasons for which the platform itself is necessary and useful. Working around it, while a good option to have, is rarely ideal - or else you fall back to the model where every team invents and builds its own tools. Renouncing (or worse, forking) the whole platform because a feature can't be prioritized to be added to it is not exactly a great outcome.
A problem with the mindset being discussed is that it makes it hard for people to collaborate, since everything gets complex and muddled. If you just move that problem from the shipped code to the tooling around the code, you haven't really gotten rid of it. There is still a big barrier to entry to contributing to the project, since people don't understand your infrastructure.
Well said. The issue is most of the core devs don't want to touch "support, consulting, hosting". It's a mental block. They think they can skip around doing only the "cool" stuff.
Edit: Sorry, is there something wrong with my pointing out that I didn't ever claim the things being imputed to me?
If I were to hazard a guess I'd say that people are finding your responses unnecessarily adversarial and pedantic. So the guy misinterpreted your comment as overly broad, you could try to understand his point and continue the conversation rather than simply "winning" by pointing out that you didn't say exactly what he implied.
FWIW I agree that the cycle exists. Especially in enterprise software, except there it's usually less about pulling in plugins and more about directly adding features to core to support more use cases/customer requests until the whole thing is a giant mess (in terms of UI, codebase, everything) and ripe for disruption by a "lightweight, fast-moving, focused" competitor.
"Frankly, I think that the majority of the current problems would be solved by trimming all of the fat from the core."
There are 100's of projects who proclaim to do so, and all of them remain obscure. By having a core that does, well, nothing (no blog, forum, commenting, news workflow, permissions, ... systems), as a developer you sill have to go hunt for 'modules' of which you usually have no idea how well they work and if they'll be maintained next year.
In theory the 'plugin' system is nice, in practice it turns into the situation where the 'core' rolls on like a freight train, leaving 'plugins' by the wayside, and users scrambling to patch together the known working versions and plugging the holes left by the incompatible versions. In the end, you still have to do a bunch of programming - but oh, before you can, you need to spend weeks to learn all the ins and outs of how to do so.
The answer is in slowing down development speed. Yeah it sucks because you can't work on cool new stuff, but maintaining backward compatibility and having a large base of usable modules, that are actually vetted by a larger group than just the one or two people who work in that module and only use the bleeding edge version themselves anyway is the only way to build a platform that people can rely on being there new year, and the year after.
reply