More complaining about git
-
So let's say that instead of repairing a bridge, or even blowing it up and building a new one, the city had launched a private jet service over the river. Sure, it's shiny and possibly more efficient, but suddenly you get a couple thousands of people with no way to drive their cars home.
That'd be a reasonable analogy if they had changedgit addto, say, ignore all.cfiles it came across, or something similarly ridiculous. It's more like... instead of replacing a suspension bridge with a suspension bridge, they decided to replace it with a cable-stayed bridge.
-
Also, not everything can be as awesome as Visual SourceSafe.
-
That'd be a reasonable analogy if they had changed
git addto, say, ignore all.cfiles it came across, or something similarly ridiculous. It's more like... instead of replacing a suspension bridge with a suspension bridge, they decided to replace it with a cable-stayed bridge.
-
The point is, the ideal (there's that word "ideal" that I know people around here don't understand) product, whether a bridge or an API, has a lifetime of "forever". If you give a shit about your work, you build it to last forever.
In order for it to last "forever," said bridge would have to be designed to handle foot traffic, horse-drawn carriages, cars, 18-wheelers, and anti-grav speeders. Could the most exacting stoneworkers and engineers from millenia past construct a bridge to those specifications?
As time moves on, requirements change. Those changes in requirements might result in major maintenance work: some of the stone might be supplanted by reinforced concrete to improve the "scalability" of the bridge.
Perhaps someone should tell the SQL Server team to stop deprecating shitty functionality supported in SQL Server 7/2000, and that they should support more than two major versions back with each major release. It's in stark contrast to the infinite compatibility offered by Chen et al. Somehow, they've managed to get developers and organizations to bend over and accept change (change that is almost exclusively for the better, as it happens). And I applaud them for it.
-
This just in: @blakeyrat can't handle pedanticism on w.tdwtf.
-
@Intercourse said:
And that is just...wrong. If you have to put bugs back in to get your API to support applications, you are on the verge of drowning in legacy support costs.
Interestingly, the contrary is the case. Take for example how several programs would get a handle to a their Window structure. That seems benign- except that the structure is completely undocumented. The reason it was undocumented? Well, so Microsoft could add features to it later- It was used internally by Windows itself.
However, the developers of the programs in question needed a feature and for some reason managed to stumble on the internal Window class structure as a way to get it.
So their product does something -accounting, spreadsheet- whatever, really well. It flies off the shelves. It works perfectly fine on Windows 95. The publishers get praise.
Windows 98 comes around. Suddenly the program breaks. Users take home their shiny Windows 98 box, install it, or take home their new Windows 98 PC and try to install and run the program, and it doesn't work. Do they blame Microsoft, or the software developer? Well- It worked before, right? The program didn't change, so it must be Windows' fault.
So- some argue- "Ah, so it's the developers responsibility!".
Except if they fix version 3.0 to get it running on Windows 98, what incentive would customers have to buy their new 4.0, which has been freshly painted and updated to use Windows 98's internal structures? None. This is why Microsoft has employed Appcompat Shims for some time. Windows 95/98+ had a limited form of this but Windows 2000 introduced the internal Appcompat database. Effectively it is a database that tells windows how to behave or pretend to behave internally so programs will work. The alternative was to keep fielding support calls from customers wanting to know why this new Windows version broke their Accounting Program version from 10 years ago. These "bugs" which are usually just undocumented internal behaviours or structures that programs stupidly used for their own purposes, are only replicated for the program that needs them.
-
Both are bad in different ways.
-
-
API-s can and should change. It's not as big of a deal as you're making it to be.
There should be a stated policy about how the API will change. Strict extensive changes are usually harmless, especially if they are appropriately namespaced and would have been an error previously. (Depending on someone else's error behaviour is usually terrible practice.)
Where it gets more complex is when you're dealing with structures. Then you either need some sort of versioning (which could be as simple as having a field with the length of the structure) or you have to have the API whose structure it is do all the allocation of it.
Deleting something is usually a bad idea except at an explicitly declared “we are breaking backward compatibility” release (usually termed a “major release”). Occasionally you get to do it sooner — e.g., if you find that it's something that nobody used because it'd actually been fucked for several releases and nobody did a support request to fix it — but that's pretty rare TBH. Never doing a major release is a recipe for total software sclerosis. BTDT.
Some fuckwads break their API every few months. That's an excellent reason to never use their shit no matter how good it seems to be right now.
-
He's not talking about the API moving forward, he's complaining about the UI changing. Despite what shitty Linux programmers think, CLI programs are not APIs. They're UIs. If other programs are using user interfaces, those programs are doing it wrong.
Unix was written around the concepts that Everything Is A File (no, seriously) and extends the KISS principle to derive that Programs Should Do Exactly One Thing.
As such, most Unix-based command-lines expect to be able to pipe input from one command to another and their command-line arguments ended up becoming an API. It's also why flags such as
-fand-Rgenerally mean the same thing in most Unix programs (-ffor file,-Rfor recursive). Not to mention why the existing arguments haven't changed in the 40ish years since Unix came around despite new ones being added. Git doing so is an anomoly, not a standard practice.Then again, it's written by the same people who change the driver ABI at the drop of a hat and have no driver API at all.
-
Unix was written around the concepts that Everything Is A File (no, seriously) and extends the KISS principle to derive that Programs Should Do Exactly One Thing.
Right and other fucking dumb philosophies that lead to shitty software.
Everything's a file! (Now figure out the complexities of representing something like, say, a video capture card with bonus FM radio receiver as a file.)
Release early, release often! (So show everybody in the world your broken bullshit? Not that "finished" open source software is any less broken, but still this is an awful idea.)
Each program should do one thing and do it well! (Ok, so what's the "one thing" a spreadsheet app should do? What's the "one thing" an app like HyperCard should do?)
There should be no ABI for drivers, so drivers have to be open source and live in the kernel! (Do I need to even expand on this one? Even most Linux users think it's dumb as shit.)
-
As such, most Unix-based command-lines expect to be able to pipe input from one command to another and their command-line arguments ended up becoming an API. It's also why flags such as -f and -R generally mean the same thing in most Unix programs (-f for file, -R for recursive). Not to mention why the existing arguments haven't changed in the 40ish years since Unix came around despite new ones being added. Git doing so is an anomoly, not a standard practice.
They haven't changed because they can't change. That's the point.
-
Release early, release often!
One thing I absolutely agree with. Get people to use it and find bugs that a testing and QA team never will until it is being used by real people anyway. You cannot fix all bugs before release. If you do, you will never release.
-
Incidentally, Unix does have an API. It used to be called C which was a programming language invented specifically to write Unix.
Of course, as C evolved, the Unix specific part got a specific name: POSIX.
-
@blakeyrat said:
The point is, the ideal (there's that word "ideal" that I know people around here don't understand) product, whether a bridge or an API, has a lifetime of "forever". If you give a shit about your work, you build it to last forever.
In order for it to last "forever," said bridge would have to be designed to handle foot traffic, horse-drawn carriages, cars, 18-wheelers, and anti-grav speeders. Could the most exacting stoneworkers and engineers from millenia past construct a bridge to those specifications?
TL;DR: yes and no @Groaner . Or, shall we see how long a Roman bridge can take the punishment of heavy freight rail service?I have two words for your concept of an eternal bridge, @blakeyrat, axle loads.
Humans are around 100kg give or take some. Pack animals will come in at 500-750kg (maybe a full ton if you convinced a bison to work for you). An animal-drawn cart/carriage/wagon might be a couple of tons (not including the team pulling it).Now, compare this to an 18-wheeler (8 tons an axle), or worse yet, railroad axle loadings (over 30 tons per axle). At these much higher loadings, the fatigue limits of most structural materials are exceeded, leading to steady crack formation and growth that will eventually necessitate bridge replacement.
-
How is it possible for people to miss the point so completely.
AXLE LOADS! GUYZ!! AXXXXEL LOADS!!!!!
CAN IT HANDLES THE AXELASLSLS!!
https://www.youtube.com/watch?v=1w7OgIMMRc4
OH NOES SO MANY AXLERSLS
The AXELS ARE WARPING REASLITY!
saved by cat being virtual cat
-
There should be a stated policy about how the API will change. Strict extensive changes are usually harmless, especially if they are appropriately namespaced and would have been an error previously. (Depending on someone else's error behaviour is usually terrible practice.)
Where it gets more complex is when you're dealing with structures. Then you either need some sort of versioning (which could be as simple as having a field with the length of the structure) or you have to have the API whose structure it is do all the allocation of it.
Deleting something is usually a bad idea except at an explicitly declared “we are breaking backward compatibility” release (usually termed a “major release”). Occasionally you get to do it sooner — e.g., if you find that it's something that nobody used because it'd actually been fucked for several releases and nobody did a support request to fix it — but that's pretty rare TBH. Never doing a major release is a recipe for total software sclerosis. BTDT.
Some fuckwads break their API every few months. That's an excellent reason to never use their shit no matter how good it seems to be right now.
On the other hand, if that fucktard is Twitter and your business depends on it, you suck it up and adapt.
API change is a technical and political decision. There's no hard morality code at play there. You change somewhere between how much you need and how much you can get away with.
-
-
-
On the other hand, if that fucktard is Twitter and your business depends on it, you suck it up and adapt.
Twitter are fucktards in a great many different ways. Like not being able to make their own Android app remember my account details. It's not like we're talking a different company either. Every single time I use it, it wants me to sign up new; the whole concept of “remember what you logged in with last time” just doesn't seem to work for them, despite Android having APIs specifically for that sort of thing. Even publishers of shitty little puzzle games get stuff more right than that.
Complete fucking morons.
Google flushes out users of old browsers by serving up CLUNKY, AGED version of search
