Reason #24,329 why modern software ecosystems suck
-
@Zenith I'm talking more about the js packages themselves using their own ways of communication. Because if I can imagine that, someone's face is against their desk dealing with it.
-
@Carnage said in Reason #24,329 why modern software ecosystems suck:
SPAs in a static document viewer.
All applications are just rapidly changing static documents. There's nothing inherently wrong with DOM as graphics backend. The problems with JS are entirely due to JS, and the problems with its ecosystem are entirely due to its ecosystem.
And JS frameworks are getting better. No question about it. The problem is that they simply release too many versions too fast and make too many breaking changes, which results in humongous maintenance costs for app developers, as well as makes their own test suites useless so regressions are rampant.
Another problem is that everyone does incredibly generic frameworks that can be used for anything and everything, but nobody made a framework specialized in simple CRUD work, which covers 99% of web apps. Wordpress was so successful not because it was generic, but because it was very specialized.
-
@levicki said in Reason #24,329 why modern software ecosystems suck:
@Zenith Because then 3rd-party vendors could add compromised TLS DLLs and steal those pearls you have been clutching.
Third party vendors could do that with any DLL. Are you suggesting a return to static linking?
-
@Gąska said in Reason #24,329 why modern software ecosystems suck:
@Magus those things happen with years of advance notice. Surely updating once every five years must be less painful than updating once every half a year?
Updating once every five years means when you do, all parts of everything break at once, community knowledge about doing the long trek through intermediate versions is also already long gone, and nuking the whole thing from orbit looks like a good idea.
Source: the Typo3 4.3.2 in production.
-
@uschwarz-0 like the "more bugs are fixed" security argument, the community knowledge one seems to apply to everything except JavaScript. At least I couldn't find anything about moving from express-js 3.0 to 4.0 a few months after its release, which had almost completely different API for everything and no migration manuals.
-
@wft It sounds like you don't really understand software development.
Maybe if you're so critical of "teenagers" you shouldn't be so wholly dependent on them. If you don't like being stuck with using other people's libraries, write your own.
-
@dfdub said in Reason #24,329 why modern software ecosystems suck:
@acrow said in Reason #24,329 why modern software ecosystems suck:
For someone to go out of their way to write FOSS without getting anything themselves out of it... I find that unlikely.
Well, it happens, but those people are usually very opinionated and have disgusting personal hygiene and therefore respond even worse to suggestions.
Filed under: Toe jam, anyone?
-
@Gąska said in Reason #24,329 why modern software ecosystems suck:
There's nothing inherently wrong with DOM as graphics backend.
-
@Unperverted-Vixen said in Reason #24,329 why modern software ecosystems suck:
@TheCPUWizard said in Reason #24,329 why modern software ecosystems suck:
There is no reason why something that has such a recommendation should inherently be marked as "obsolete".
It results in a build warning, communicating to the developer that it should not be used.
Actually removing them forces them not be used, which is fundamentally different than a recommendation
I agree that it shouldn't be removed from .NET Framework; but .NET Standard was a clean starting point, and would have been a good cutoff point,
But I was talking about specifically the word "deprecate" (and related forms), which does NOT have any such implication.
One could recommend that someone not use a particular piece of code simply because they dislike the developer who wrote it. They HAVE deprecated the code!
Now, determining that something is obsolete [aka the ObsoleteAttribute] would be a reason for deprecating. But it is a single subset of the scope of deprecation, therefore is would be foolish to assume that something is obsolete because it was deprecated). I don't like razorback lizards (not true, but go with it), all razorback lizards are animals...so if someone says they have an animal (pet) should I presume that it is a cat??
-
@Gąska said in Reason #24,329 why modern software ecosystems suck:
Another problem is that everyone does incredibly generic frameworks that can be used for anything and everything, but nobody made a framework specialized in simple CRUD work, which covers 99% of web apps.
This is spot on. I think the framework churn prevents more advanced tools from being created. Suppose I make an automated CRUD tool for Angular 7 to be easily integrated with Django, or something. It won't last half a year without a lot of maintenance, because next version will break something.
I generally avoid touching the front-end (for this and other reasons, the other being mostly the shit-avalanche of 'move this button' tickets), but when I look at what the front-end guys are dealing with, it's like they're writing in assembly. Functionality that ten years ago could be generated with automated tools like RoR, Cake etc in half an hour, including some tweaks, takes days of labor.
-
@levicki If you're going to take that condescending attitude "Oh, it's just kids, it's not serious stuff, they don't take it seriously" then I suggest you just write your shitty webapp from the ground up without relying on other people's code - if you can.
No-one owes you anything. If someone else's library changes in a way that breaks compatibility with your poorly-engineered code, you could always just ask for your money back.
-
@levicki said in Reason #24,329 why modern software ecosystems suck:
@gordonjcp said in Reason #24,329 why modern software ecosystems suck:
@wft It sounds like you don't really understand software development.
Maybe if you're so critical of "teenagers" you shouldn't be so wholly dependent on them. If you don't like being stuck with using other people's libraries, write your own.
Maybe you and some of those teenagers don't understand the terms "collaboration", "compatibility", "responsibility", and "support"?
Sure, those libraries are those teenagers' personal projects, and they can do what they want with them, but once they are published and adopted in other people's projects there should be certain level of responsibility not to break stuff for no good reason.
TL;DR -- If you want to break shit willy-nilly don't make your library public, and don't let people depend on it.
If you aren't paying them, you have no say at all in what they do. Fork and support the old version yourself on your free time then.
OTOH, if you are paying them, some level of professionalism and support is expected.I do agree with the feeling of utter retardedness in changing stuff just because.
-
@Carnage said in Reason #24,329 why modern software ecosystems suck:
If you aren't paying them, you have no say at all in what they do.
You're right, of course, technically. But that also means the entire idea of free zapftware is retarded to begin with, since it should be worthless. And yet it's everywhere - the damage has already been done - so I'm afraid that notion is very unrealistic.
-
@Applied-Mediocrity said in Reason #24,329 why modern software ecosystems suck:
@Carnage said in Reason #24,329 why modern software ecosystems suck:
If you aren't paying them, you have no say at all in what they do.
You're right, of course, technically. But that also means the entire idea of free zapftware is retarded to begin with, since it should be worthless. And yet it's everywhere - the damage has already been done - so I'm afraid that notion is very unrealistic.
You always pay somewhere. In the case of free software, you pay for it in maintenance costs.
-
I think that front-end framework developers assume that websites get rewritten every two years so they won't support an API for longer than that.
-
@magnusmaster said in Reason #24,329 why modern software ecosystems suck:
I think that front-end framework developers assume that websites get rewritten every two years so they won't support an API for longer than that.
I'm my current project, we can't even keep frontend developers around for more than a few months. If angular wasn't so completely retarded I could probably learn it and do a better and faster job at it than they are doing. But...
-
@Carnage Why do companies insist on using garbage like Angular then? So many jobs I can't/shouldn't apply for because it's all Angular all the time...
-
@Zenith For the same reason XML was so popular ~15 years ago: brand recognition. It doesn't matter that it's terrible; the Important Decision Makers know it's the big thing everyone's using, and that's good enough for them!
-
@Mason_Wheeler We need to be glad that Artificial Intelligence or Blockchain have not been related to UI just yet...
-
@Zenith said in Reason #24,329 why modern software ecosystems suck:
@Carnage Why do companies insist on using garbage Ike Angular then? So many jobs I can't/shouldn't apply for because it's all Angular all the time...
In this case it's government, and their explicit reason to force angular is that everyone is using it, not a single technical reason.
And they can't find a senior angular developer.What I've seen of angular in this project so far makes me want to stab someone's eyes. The framework is really dumb and ugly. I'd have preferred JSF over this pile of inconsistent excrement if a component web framework was to be used. And since our most used service sees about 100 unique users per week, it would work as well.
-
@levicki said in Reason #24,329 why modern software ecosystems suck:
Making breaking changes without really good reason and more importantly without a clear example of how to migrate your code while minimizing the disruption and the effort required to do so is just plain inconsiderate and rude.
I guess it's something like “this is the most important thing to me, so it should be the most important thing to you too!”
Although there's also a lot of people being so busy with what they're doing that they don't keep up with the tide in other areas. This isn't too pressing a problem when you're coding software with only a small number of other direct dependencies, but with so much of current software being so heavy on the dependency front, the mean time between problem breaking changes decreases a lot…
-
@Carnage said in Reason #24,329 why modern software ecosystems suck:
In this case it's government, and their explicit reason to force angular is that everyone is using it, not a single technical reason.
And they can't find a senior angular developer.Believe me, I've seen that reasoning enough times.
I turned down an interview recently because of Angular. Department of Corrections has a kitchen sink contract out there that I already interviewed for last summer. The problem was that the three Indians conducting that interview asked nothing but Angular questions. Which was stupid because the reason I applied was OnBase which has a far shallower talent pool than Angular. Of course, the Indian recruiter calling me about this "amazing opportunity" literally cannot understand that. "But it says VB.NET and SQL and blah blah blah!" So now I have to ignore its calls for a few weeks...
-
@Carnage said in Reason #24,329 why modern software ecosystems suck:
I'm my current project
Great attitude, you should always continue working on yourself!
-
@levicki said in Reason #24,329 why modern software ecosystems suck:
@dkf said in Reason #24,329 why modern software ecosystems suck:
I guess it's something like “this is the most important thing to me, so it should be the most important thing to you too!”
I just think that people sharing their code should stop and reconsider WHY they are actually sharing their code in the first place?
If it is because they want other people to use it, then they should carefully consider the impact of making big changes.
Stop using libraries that are to unstable. If you're not paying them for the labor, then you really haven't got many other options.
Would it be nice if everyone never changed anything and supported every old library? Yes, but when it's unpaid work, it's pretty presumptuous to tell people what they are allowed it supposed to do with their own projects.
Simply don't expect professionalism of your not paying for it.I swear it almost seems like some of them are actually doing it just to show off their code portfolio and mad coding skillz without any intent to actually support it. There is a simple solution to that -- make your repo private if you don't want to support others that depend on your code.
There are probably a not insignificant share of people doing it for precisely that reason.
-
If you can't write an API without such major flaws that you continually have to do complete rewrites, you shouldn't be writing them at all.
Filed Under: In before someone strikeouts "an API" and replaces it with "code"
-
@Carnage said in Reason #24,329 why modern software ecosystems suck:
If you're not paying them for the labor, then you really haven't got many other options.
In general, the options (that stand a chance of working) are either pay someone for support, or ask nicely and pray to God (it sometimes works). Demanding obnoxiously that someone do lots of grunt work for you for gratis… that just ain't happening. Occasionally you get lucky, but that's usually because you're leeching off what someone else wanted and was prepared to put up money and/or effort to get. Sometimes the leeching is encouraged a bit, to a certain extent (as in “hey, reuse this existing well-tested code rather than writing your own goddamn version, again”) but that's one a minority case and only really works for pretty generic stuff.
Support ain't free because it takes people's time and effort. If you're not paying or supplying your own effort (paying in another sense) then you've got no right to expect anything.
-
@powerlord said in Reason #24,329 why modern software ecosystems suck:
If you can't write an API with such major flaws that you continually have to do complete rewrites, you shouldn't be writing them at all.
And if you can't write a sentence that means the opposite of what you wanted to say you don't need to proof-read your posts...
Filed under: I'm sorry I'll stop now, yes I know where the door is
-
@levicki said in Reason #24,329 why modern software ecosystems suck:
@Carnage said in Reason #24,329 why modern software ecosystems suck:
Stop using libraries that are to unstable.
Thanks captain Obvious, but how do you determine which ones are unstable?
CommandLine was stable until 1.9.71.2. Then the project changed owner (transferred to an organization), and the next update broke everything. If they at least made a new CommandLine2 nuget package, but no, they let you update from 1.9.71.2 to something totally incompatible.
@Carnage said in Reason #24,329 why modern software ecosystems suck:
Would it be nice if everyone never changed anything and supported every old library?
I never said they should never change anything, and I don't expect that they support old stuff indefinitely, but see above.
@Carnage said in Reason #24,329 why modern software ecosystems suck:
Simply don't expect professionalism of your not paying for it.
The fact that other people are not giving them money doesn't mean using their libraries is free -- others invest their own time to learn how to use those libraries and write glue code for their own projects. For some libraries that can be considerable effort, and what I am having a problem with is not the changes themselves, but those retards pissing on everyone else's effort by making breaking changes without documenting how to migrate or splitting a project if changes are so substantial.
Like I said, if you are not paying directly, you will end up paying with your own time. You can rant all you like, but hobby projects will never be up to professional levels, and as far as documentation goes, even with professional products the documentation is most of the time pretty shitty.
If you want the documentation, pay then to write it.
-
@Carnage said in Reason #24,329 why modern software ecosystems suck:
Like I said, if you are not paying directly, you will end up paying with your own time. You can rant all you like, but hobby projects will never be up to professional levels, and as far as documentation goes, even with professional products the documentation is most of the time pretty shitty.
If you want the documentation, pay then to write it.And yet somehow these problems are endemic only to the javascript ecosystem, and, to a lesser extent, GNOME desktop. All other FOSS libraries seem stable like a rock compared to that. Even web frameworks written in PHP.
PS. sometimes you pay and you get something even worse than npm
-
@sebastian-galczynski said in Reason #24,329 why modern software ecosystems suck:
PS. sometimes you pay and you get something even worse than npm
Matthew 16:23 comes to mind.
-
@Zenith said in Reason #24,329 why modern software ecosystems suck:
the Indian recruiter calling me about this "amazing opportunity" literally cannot understand that.
More of the people responsible for outsourcing to cheap Indian companies need to be on the receiving end of the needful being done.
-
The Encyclopedia Galactica defines a robot as a mechanical apparatus designed to do the work of a man. The marketing division of the Sirius Cybernetics Corporation defines a robot as "Your Plastic Pal Who's Fun to Be With."
The Hitchhiker's Guide to the Galaxy defines the marketing division of the Sirius Cybernetics Corporation as "a bunch of mindless jerks who'll be the first against the wall when the revolution comes," with a footnote to the effect that the editors would welcome applications from anyone interested in taking over the post of robotics correspondent.
Curiously enough, an edition of the Encyclopedia Galactica that had the good fortune to fall through a time warp from a thousand years in the future defined the marketing division of the Sirius Cybernetics Corporation as "a bunch of mindless jerks who were the first against the wall when the revolution came."
-
@anonymous234 said in Reason #24,329 why modern software ecosystems suck:
This is one of the eternal discussions here. Developers like deprecating old code and moving on to newer versions that work differently. (Some of) the people that consume their products don't. Well, too bad, the people that own the product get to decide.
Not really, important customers that have our CEO phone number force us to support things like MS-DOS up to a few years ago
-
@levicki said in Reason #24,329 why modern software ecosystems suck:
CommandLine was stable until 1.9.71.2. Then the project changed owner (transferred to an organization), and the next update broke everything. If they at least made a new CommandLine2 nuget package, but no, they let you update from 1.9.71.2 to something totally incompatible.
I presume the version you're complaining about was 2.x.x, right? If so, the fact that the API had changed and is incompatible is indicated by the major version bump.
Sure, you could argue that changing the interface was not necessary. You might be right, I'm not familiar with the library. I just don't understand what caught you by surprise or why you even decided to update in the first place. Heck, they even point you to the right place if you're still wanting to use the old version:
Note: the API surface has changed since v1.9.x and earlier. If you are looking for documentation on v1.9.x, please see stable-1.9.71.2
-
@sockpuppet7 Well yeah, if you do this weird, obsolete thing called "selling the software" then you have to follow the market.
The future is open source where you have no incentive to do what your clients want.
-
@ixvedeusi My brain said to type "without" and my hands decided to type "with" instead. Oh well, fixed now.
-
@levicki said in Reason #24,329 why modern software ecosystems suck:
Major version bump doesn't always mean API change. It can mean major new features as well.
It should if everyone follow semver
-
@levicki said in Reason #24,329 why modern software ecosystems suck:
Major version bump doesn't always mean API change.
It (generally) does for NuGet packages.
-
@sebastian-galczynski said in Reason #24,329 why modern software ecosystems suck:
And yet somehow these problems are endemic only to the javascript ecosystem, and, to a lesser extent, GNOME desktop. All other FOSS libraries seem stable like a rock compared to that. Even web frameworks written in PHP.
Weell...
-
@levicki said in Reason #24,329 why modern software ecosystems suck:
You know nothing about the library changes and how big they were, and you know even less about my code, you are only making an ass out of yourself by assuming that it's my fault.
But it is your fault. Either use an old version of the library and maintain it yourself if you have to, or update your code to use the new way.
-
@powerlord said in Reason #24,329 why modern software ecosystems suck:
If you can't write an API without such major flaws that you continually have to do complete rewrites, you shouldn't be writing them at all.
They don't do it because they have to. They do it because they want to. I don't believe you've never had a project where, halfway through, you were like "this one thing could be made much nicer now that I know how it's actually used, but it would require a major rewrite of everything and nobody will pay me for that". Guess what - if you don't get paid either way, such rewrites are much more common, while making a complete product that has all necessary functionality becomes very rare. Some old time hackers call it CADT - Cascade of Attention-Deficit Teenagers.
-
@Gąska Sometimes, it's not until several years into dealing with a problem (and shipping product that's making at least some users happy) that you realise that the way you went about doing things originally wasn't right. There are various reasons why this can happen, especially including the pressure to get something working enough so that the code can ship at all, but happen it most certainly does. I'm not talking about cosmetic things like the placement of the OK button, I'm talking about fundamental aspects of the basic data model (such as having the wrong inter-entity relationships, which you've got meta-entities in place to patch over the problems with). Fixing the problems can allow everything to become much better and easily gain new, highly-desired capabilities that are currently very difficult to implement, but at the same time they're a major breaking change whose impact is both significant and hard to minimise.
Nothing I've seen indicates that whether the software in question is open or commercial really changes that. All that really changes is how long the old way of working continues to be supported (at least for basic bugfixes) after the new version becomes available. Support is one of these things that takes real effort along the way, and real effort inevitably has to be paid for somehow.
Which isn't to say that there's no unprofessional idiots out there who break stuff because they don't care. It's just a fantastically bad idea to build any kind of product on top of the shit those idiots spit out. (I've also seen plenty of commercial software which nonetheless had terrible support. Motherfucking assholes.)
-
@dkf said in Reason #24,329 why modern software ecosystems suck:
Sometimes, it's not until several years into dealing with a problem (and shipping product that's making at least some users happy) that you realise that the way you went about doing things originally wasn't right.
Also sometimes, the technical debt builds up and doing a rewrite looks like a better option than trying to untangle the mess you've made.
I've dealt with this multiple times inside a particular project where I've ultimately replaced the original way of doing things with something completely new (sometimes multiple times).
Sometimes it's even a good idea!
-
@boomzilla Then you give it another name.
-
@wft huh?
-
@boomzilla ie. instead of "MyLib 2.0", you call it "MyNewLib", so that people don't upgrade thinking they're getting a new and improved version and end up breaking stuff due to compatibility breaks.
-
@Mason_Wheeler said in Reason #24,329 why modern software ecosystems suck:
@boomzilla ie. instead of "MyLib 2.0", you call it "MyNewLib", so that people don't upgrade thinking they're getting a new and improved version and end up breaking stuff due to compatibility breaks.
Oh, I see. It was only addressing the first sentence of my post.
-
@Mason_Wheeler said in Reason #24,329 why modern software ecosystems suck:
instead of "MyLib 2.0", you call it "MyNewLib"
Before long there'll be MyNewNewLib and MyNewNewLibBisNewThistimewemeanit
-
@dkf Also fun is
MyLib2 version 3.4.
-
@dkf MyNewLib Core, obviously.
