This Slashdot article
-
@blakeyrat said:
What is the "one thing" a spreadsheet application should do well? And here's a bonus tip: the reason Excel took over this space ion the first place is it started to do things other than simulating a financial spreadsheet well, while its competitors did not.
Excel sucks - it does not run well on my new Raspberry Pi. The authors of Excel are all idiots, because they did write it so, that it would not run smoohtly on this 700MHz ARM procesor.
-
@blakeyrat said:
@j_p said:
(although I do like the CreateProcess() line. cmd, as we all know, starts processes by magic).
It's not magic. It's an API, provided by the OS. It's well-documented, look it up.
The assertion was that Explorer keeps a CLI open "behind the scenes" to do things like launching files. I was demonstrating that that assertion was complete bullshit. It's almost as if someone posting here doesn't know shit about how computers work, hmm!
Pop quiz: Mac Classic had no CLI. None. Zip. Zero. And yet it could launch applications and files. How do you think that was possible? I guess "magic" is the answer?
Yeah, blakey, go back and read what I said originally. What I said was that changing the properties of a shortcut to pass some arguments is doing the same thing as opening a cmd window and passing some arguments, or writing a batch file that passes some arguments. You retorted that it isn't the same thing because shortcuts call CreateProcess. I'm not the one who thinks CMD is magic in this scenario. If this still isn't clear to you, notice that at no point have I said that explorer keeps a CMD window around to start things up. Hell, I've written a simple unix shell when I was at uni for my operating systems course. I'm very much aware how they work.
@blakeyrat said:
@j_p said:
Okay but what's the difference between writing a file consisting of textual commands that ends in .bat and a file that ends in .js and double-clicking it?
No difference. Neither is using a CLI.
@j_p said:
What's the difference between writing a bunch of commands in a terminal or writing a bunch of commands in a file that you then open with a terminal?
"open with a terminal" is gibberish. What does that even mean?
Oh please it's perfectly obvious from context what I mean. I mean opening a .bat file is morally equivalent to writing those commands in a cmd window. Which is morally equivalent to writing a jscript file and using that. The specific CMD implementation isn't what I'm defending, blakey, I'm defending the concept of writing textual commands for a computer.
@blakeyrat said:
@j_p said:
CLIs are useful for the same reason programming languages are useful.
Programming languages are useful for writing software. CLIs are useful for kind of sort of connecting some other existing programs together, kind of, although the connections are super-fragile and the only type of data you can reliably pass around is text.
Text-based CLI-ish connections are /more robust/ than DLLs. They don't depend on ABI compatibility, they're more tolerant of API changes, and they provide a bunch of functionality for free that DLLs don't provide - like maybe the provider and the caller can live on different computers, or maybe you want to update the provider while the caller is running, or maybe you want to run the provider and caller at different security levels and without living in the same address space.
@blakeyrat said:
@j_p said:
As for this hangup about using the command line (or moral equivalents) as an API, don't you do web analytics for a living? You know, operating with programs that communicate with each other via a textual pipe?
The HTTP protocol doesn't really give us a choice in the matter. We don't do it because we want to.
The implication is that HTTP is a text pipe for a /reason/, and the reason isn't a historical accident. All the reasons that HTTP is a text pipe can be applied to /other/ protocols. Like maybe you want to distribute your compilation across multiple computers. Which make, a very, very old program as you've pointed out, can do almost for free because it doesn't give a damn where its child processes are spawned.
@blakeyrat said:
@j_p said:
Sure, sometimes the DLL approach has merits, but if the library you're calling out to has other user-useful functionality you may as well make it user-visible.
Right; by providing a 500k DLL that programs can use and a 10k program that exposes the useful functionality. That's exactly what I'm proposing be done. The beauty of this system is that if your little program needs improved it can be-- without the risk of breaking other programs on the system!
And the downside of that approach is that now DLL and consumer of DLL must live on the same computer, must live in the same address space when launched, must use the same ABI, the API of the program can't be readily updated (because updating DLL APIs is harder than updating a text-based API, blakey).
@blakeyrat said:
@j_p said:
I'm particularly amused by the "OH NO IF YOU CHANGE THINGS IT BREAKS" problem. When you change a DLL, of course, everything is peachy-fine. DLL hell wasn't a real problem that ever happened (and has been fixed by carrying around every version of every DLL).
Right, the difference is that the DLL Hell program has been worked-around (solved, in other words-- even you refer to it in the past-tense), and the "CLI-program-used-as-API" isn't solved, and the Linux community seems to dedicate zero resources to even attempting to solve it.
@j_p said:
- Visual C++ comes with a version of make and builds using it. Guess it isn't a good IDE. Although I'm happy to concede that there aren't any good linux C++ IDEs - I've still yet to run into a good IDE for any OS. Visual C++ is okay, although a bit buggy and slow, and the compiler it uses is awful. Good debugging features though.
C++ is shit.
@j_p said:
- Seriously making a shortcut is different because that invokes CreateProcess()? Do you actually think before you say these thing
Right. There's no CLI usage involved in making a shortcut in Windows Explorer and entering different launch parameters. If CMD didn't exist on the system at all, this process would work just fine.
@j_p said:
- Okay, I want a list of every Qt library we're using in a project. I go to that project (which is of course an indexed search location) and type '#include <Q' in the search window. All the files that contain an include to a Qt library come up. Now how do I get the list of Qt headers out of that? I don't think you thought your solution through.
C++ is shit. So it's no surprise working with C++ is shit.
Ah, the no-true-scotsman defence again. All of these things I'm doing are bad things that no sensible user would ever want to do. Obviously a C# developer would never want a list of all the libraries they're using.
(some of us write embedded code, interface with embedded devices, and can't use ethernet because the data we're passing back and forth would saturate a gbps connection, blakey. C++ serves a purpose, even if it's not great for doing web analytics)
@blakeyrat said:
@j_p said:
- Oh of course release-early-release-often makes people not use your software. That would be why Apache (you know, 'a patchy') is the most common web server
Apache is popular initially because when it was new there was no effective competition. Apache is popular now because it's cheap, and web serving is a "race-to-the-bottom" type software environment.
Apache is passably good because, a few years ago, people shamed them into making it not such shit after showing how embarrassingly slow it was compared to IIS, and it was such a black eye on the open source community they expended a lot of effort into fixing it.
@j_p said:
why Linux is the most-installed operating system in the world (tiny desktop penetration, sure, but all those embedded devices add up).
So? McDonalds is the most popular restaurant in the world, it's still no good. (Oh, and all of those non-computer devices? None of them have CLIs.)
@j_p said:
Free probably has something to do with that, yes,
If you replace the word "something" with "everything", then yes, your statement is accurate.
Thank you for gracefully conceding that release-early-release-often doesn't drive users away.
@blakeyrat said:
@j_p said:
but there are technical reason why linux is an excellent OS to use for embedded devices, and LAMP is used by most of the world's largest websites, so its got something else going for it.
You're seriously coming to DailyWTF and telling us there are reasons, technical reasons no less, that PHP is popular? You are so full of shit it's coming out your ears. Here's the reason PHP is popular, and you already know it: it's because it's free. In every other aspect it's a complete mess.
I was actually thinking 'perl' when I wrote LAMP. Amazon, Google, and Wikipedia all run on linux stacks of some kind. Implication: there are technical benefits.
@blakeyrat said:
@j_p said:
- In what universe does blakey live in if searching for and downloading a bulk file name renamer is easier than typing 'move *.blah *.blah2'?
What does it matter? It's a fucking contrived-as-hell example. And the only reason it even came up is because some other piece of software was broken. I want to see an example of how the CLI is better for a task that people actually perform commonly.
Thank you for gracefully conceding that you were wrong and that this is an example where CLI-style commands are superior. Now that you have conceded that a CLI is superior for some tasks, why are you still arguing, given that this was my central claim?
@blakeyrat said:
@j_p said:
- I'm not a git user, but I'd be very, very surprised if you couldn't tell it which diff program you wanted to use.
You can, but why should you have to? Looking at diffs is like... 50% of what people do with source control programs. And Git basically skipped completely over implementing it. Because Git was written by idiots.
@j_p said:
If you wanted to source control CAD drawings, then simply provide a diff tool that works for them and you're set. Because it's modular and just does source control. Duh.
Wouldn't it be great if Git worked with data other than text? I think one of the reasons Linux is so shitty is because Linux developers utterly lack any imagination whatsoever. (Which is probably why they have trouble with the word "should".)
Sigh. Blakey, again, needing his hand held through very simple inferences. If you tell git to use a specific diff tool, perhaps one designed for the data you're controlling (CAD diagrams, 3D models, bespoke binary format, whatever), then you can get diffs in whatever format you please. If the data is best represented graphically, your diff tool can do that. And if your diff tool can output incremental changes in the right format, git can even store your CAD data incrementally. Because it's modular. If it was implemented as a DLL, you'd need to design a special plugin interface to get similar functionality. Well, or have the DLL call out to an external diff tool like some kind of plebian.
-
@blakeyrat said:
The assertion was that Explorer keeps a CLI open "behind the scenes" to do things like launching files.
THAT WAS YOU WHO ASSERTED IT.
@blakeyrat said:
I was demonstrating that that assertion was complete bullshit.
Well done. We can at least agree that you were spouting bullshit.
-
@dkf said:
@flabdablet said:
I do like bash as a shell, and consider it one of the great underrated programming languages even though ${name} is astoundingly ugly syntax for disambiguating access to an rvalue.
It's not the worst feature. The default double expansion of variables, that's definitely worse when you're trying to write scripts with predictable behavior. Bash (and all the other bourne shell derivatives) only really work well when filenames typically don't have spaces (or other odd characters) in; works great on systems for techies, but has terrible problems with ordinary users.There is no "default double expansion". Expansion proceeds in a well-documented, well-conceived sequence of steps, and there are quoting rules that let you selectively turn some or all of those off.
The fact that the last of those steps is word splitting, which can cause the command line to be broken into more words than it was before expansion even started, does cause problems for people who insist on writing scripts that don't pay attention to the rules. Sucks to be them and their customers, I guess.
But there really are only so many ways you can generate a command pathname and a collection of argv() strings from a command line containing arbitrary strings including expandable parameters, and the way Bourne shells do it is reasonably concise, arbitrarily flexible and very rarely wastes the scripter's time. One of the main things that makes it work is the carefully designed quoting and quote removal rules, which make it possible to quote anything and also make wrapping anything you don't want word-split in double-quotes always harmless. Windows scripting would be a lot less confusing and error-prone if cmd had always had similar rules.
The only "odd" filename character that is genuinely hard to deal with in scripts is the newline, and that's only because so many tools make the assumption that one line of output == one filename or pathname. But since the only real alternative to having that problem is needing to deal with all the Rube Goldberg complexity needed to make something like PowerShell's object pipelines even possible, I far prefer to stick with what Jeffrey Snover sniffily dismisses as "prayer-based parsing" when I'm using a shell. In theory having what's going down the pipe all neatly encapsulated should save time and effort, but in practice I've found the opposite to be true.
-
@blakeyrat said:
@Master Chief said:
...with the possible exception of every system administrator ever.The shell is powerful, to be sure, even on Windows you can do a lot of things much easier and faster in CMD than in Explorer, and of course Bash needs no introduction there.
Yeah but this is my big issue with the argument: I don't deny the CLI can do some tasks faster, but those tasks are all things nobody ever needs to do
-
@blakeyrat said:
@j_p said:
- I'm not a git user, but I'd be very, very surprised if you couldn't tell it which diff program you wanted to use.
You can, but why should you have to? Looking at diffs is like... 50% of what people do with source control programs. And Git basically skipped completely over implementing it. Because Git was written by idiots.
No, viewing and editing diffs is like 50% of what people do with source control programs, and apparently a good diff editor is a surprisingly hard thing to create, because I have only seen one, ever, that did not absolutely suck: Beyond Compare. Maybe they just decided "let's leave this part to someone else and focus on the core functionality of version control."
-
@Mason Wheeler said:
I have only seen one, ever, that did not absolutely suck: Beyond Compare.
I am using vim (vimdiff), as I work with textfiles in git and it works good for me.
I looked on Beyond Compare, but (in comparing textfiles) it seems to do the same as vimdiff - maybe there is some difference, I did not seen, but on their pages it was not enhanced.
-
@gilhad said:
Git was developed for working with text files and not CAD files just because git was developed to help with developing linux kernel, which source contains lot of text files, but none CAD files.
Though git will still work correctly with CAD files (and any other structured or binary data you might care to mention). The only real issue is that the default diff — a part of the UI, really — is much better at showing the differences in plain text than in anything else. Use a different difference display strategy and it will work better for CAD files, or whatever.What I would like is a better GUI for git so that I'm exposed to less of the convention complexities while still having a sane workflow (branches for things being worked on, tags for marking particular states like releases, general sharing of state between a small group of people). Right now, I have to understand way too much of git to work like that…
-
@dkf said:
Though git will still work correctly with CAD files (and any other structured or binary data you might care to mention). The only real issue is that the default diff — a part of the UI, really — is much better at showing the differences in plain text than in anything else. Use a different difference display strategy and it will work better for CAD files, or whatever.
What I would like is a better GUI for git so that I'm exposed to less of the convention complexities while still having a sane workflow (branches for things being worked on, tags for marking particular states like releases, general sharing of state between a small group of people). Right now, I have to understand way too much of git to work like that…
You are right, but my point was, that git was developed for one concrete purpose and for that purpose works perfectly.
The other thing is, that we (other users than kernel developers) are using it for other purposes, where it works also good, but it is not, for what it was developed. Still we have the right and possibility to change it to our needs, which is much more, that any proprietary GUI tool can offer.
(And as my needs are similar to those of intended user group, I am satisfied with I got (for free) and I do not feel urge to change anything - apart from using .gitconfig for some convenient shortcuts as ci = commit, co = checkout and so, and for some scripts to fit my need of managing ~75 repositories
alias gom='git merge origin/master'
gl() { git log --graph --oneline --decorate=full "$@" |sed "s#refs/[a-z/]*/##g;s#tag: ##g" ; }
and scrit to apply one git command (with params) to all repositories - usual use is "ga fetch", "ga push" "ga status", but also "ga merge origin/master" or others are possible)
-
Wouldn't it be great if Git were actually usable, so that anybody could do the type of scripting and customization you can?
-
@blakeyrat said:
Wouldn't it be great if Git were actually usable, so that *anybody* could do the type of scripting and customization you can?
It is already usable for intented users. It was not developed for *anybody and his dog* and was not presented as such.
If you want some versioning system with GUI only and workflow easy for beginners, who do not read manuals, you are free to write such system.
You even are free to use git code for that, as long as you confirm with it licence (GPL). Or you can pay anybody willing to do it for you. (Or rise foundation and collect mony from others to hire someone like that ... or anything else)
As you did not pay for git nothing, you are already given much more, than you paid for.
Also note, that other GUI tools mentioned here (Excel, Beyond Compare, "some randome GUI renamingutility, that google offered me", ...) do not even offer such possibility of reworking/customizing/forking/rewriting.
As for me - it is easy usable and scriptable for me, so I have no needs to change the git. I make some simple scripts around that and they are free to use (under GPL).
-
@gilhad said:
It is already usable for intented users. It was not developed for anybody and his dog and was not presented as such.
Right. That's the problem.
@gilhad said:
As you did not pay for git nothing, you are already given much more, than you paid for.
It's free, so it doesn't matter that it's crap!
-
@blakeyrat said:
Wouldn't it be great if Git were actually usable, so that anybody could do the type of scripting and customization you can?
If you check the roadmap, you'll see that it's scheduled between teaching *anybody* to use "your" properly and teaching *anybody* to use "there" properly
More seriously, why is what he did too difficult for most people to understand?
-
@blakeyrat said:
@gilhad said:
It is already usable for intented users. It was not developed for *anybody and his dog* and was not presented as such.
Right. That's the problem.
The only problem is, that YOU are trying to use something, what was not developed for such users as you. It is the same problem, as Excel not working on Raspberry Pi.
@blakeyrat said:
@gilhad said:
As you did not pay for git nothing, you are already given much more, than you paid for.
It's free, so it doesn't matter that it's crap!
It is not crap, it is perfect tool for the work, for which it was constructed. If you do not like it, do not use it. If you want it to use for something, for what it was not intended, then the problem is you, not the tool.
Would you say, that Excel is total crap, because it sucks on editing photos?
-
It's also worth pointing out that Git was never meant to be a big project - Linus Torvalds wanted a source-control system for the project he was working on at the time, decided that everything currently available was crap and wrote his own tool for doing source control. It grew and became popular because he used it for linux. Linus seems to have this habit of accidentally creating popular tools while hacking around for his own purposes...
-
@j_p said:
Unix philosophy: Programs should do one thing well.
And I'm sorry, but this philosophy is completely outdated.
Don't get me wrong, I used to think like that, even up to about 2007-2008. My phone should be nothing but a phone. My MP3 player only an MP3 player. My e-reader only an e-reader. And you know what? It was inefficient. Here I am using a computer for office work, video editing, gaming, and all this other shit, but I'm insistent that each program have a single function. Well, that's crap. Being forced to get an Android phone because my old clamshell couldn't be replaced with another one taught me better. That Unix philosophy is Obsolete. It has no place in an efficient environment of today's computing.
@Mason Wheeler said:
...which is why Unix never caught on outside of highly technical users, because they still think that a good GUI is somehow separable from core functionality, whereas well-designed user applications are specifically designed, from the beginning, to be driven by the GUI. It's not a coincidence that the only places where any form of Unix has found mainstream acceptance are in derivative OSes that have been heavily reworked by companies like Apple and Google with tons of experience in providing good, intuitive user interfaces
Quoted for truth.
@blakeyrat said:
He could have downloaded a bulk file rename utility and done it in a GUI almost as fast. So I don't see that as a compelling argument.
That's actually the first thing I thought of right there.
-
@Castaigne said:
I used to think like that, even up to about 2007-2008. My phone should be nothing but a phone. My MP3 player only an MP3 player. My e-reader only an e-reader. And you know what? It was inefficient. Here I am using a computer for office work, video editing, gaming, and all this other shit, but I'm insistent that each program have a single function. Well, that's crap. Being forced to get an Android phone because my old clamshell couldn't be replaced with another one taught me better. That Unix philosophy is Obsolete. It has no place in an efficient environment of today's computing.
There's an old saying: "Jack of all trades -- master of none".In theory, yes, programs or devices that only do one thing are inefficient. But in the real world there's something even more inefficient: progams/devices that do many things and do them all badly. And that's what you get in most cases. This is one of those situations where people *think* they are being more efficient, but in most cases they aren't. There have been many studies done where they have measured the actual amount of time it takes to perform a task and it has been found that:
Using a GUI to do something is often faster than using a CLI
Multitasking often takes longer and produces poorer quality results than doing one task at a time
-
So what's the "one thing" a spreadsheet program should be doing well?
-
@blakeyrat said:
So what's the "one thing" a spreadsheet program should be doing well?
Spreadsheets, obviously. Duh.
-
@blakeyrat said:
Wouldn't it be great if Git were actually usable, so that anybody could do the type of scripting and customization you can?
My employer recently contracted out an automated build process for Team Foundation Server. We have a fairly complex build that took one developer from our team most of a week to write in MSBuild. The contract to port it over to a build process template (XAML, ugh) took the consultant around 4 months, and it still depends heavily on GnuWin32 tools.
Before any of that it was a batch file in our source control; it was a little ugly but it was reliable and easy to add or remove steps from. Porting it over to XML (MSBuild) made it harder to maintain, but allowed Visual Studio to automatically perform the whole build process whenever we compile. Porting it over to XAML (TFS build process template) made it difficult to maintain but allowed continuous integration in TFS.
TFS: more usable than Git?
-
If I had to describe it in a sentence, it would be 'provide a comfortable user interface for semi-technical to technical users to manipulate data, where the data is mostly numeric and array-based and the manipulation mostly consists of statistical analysis and some arithmetic'. A bit unwieldy, but that's kind of what you expect when describing a programming language. What's the one thing python should do well? Execute python programs. Similarly, spreadsheets are visual R (or Matlab if you prefer).
"Do one thing and do it well" is, of course, a rule of thumb. A more accurate way of saying it might be "If the functionality can be seperated, put serious consideration into seperating it into two programs", but that doesn't flow as well.
-
@Mason Wheeler said:
@blakeyrat said:
@j_p said:
- I'm not a git user, but I'd be very, very surprised if you couldn't tell it which diff program you wanted to use.
You can, but why should you have to? Looking at diffs is like... 50% of what people do with source control programs. And Git basically skipped completely over implementing it. Because Git was written by idiots.
No, viewing and editing diffs is like 50% of what people do with source control programs, and apparently a good diff editor is a surprisingly hard thing to create, because I have only seen one, ever, that did not absolutely suck: Beyond Compare. Maybe they just decided "let's leave this part to someone else and focus on the core functionality of version control."
I think I tried Beyond Compare once and thought it was pretty good.
So far, my favorite thing for dealing with diffs is actually the Eclipse compare editor. This is less a case of thinking it's great for the purpose and more a case of finding it good enough that I'm rarely motivated to look for better...its main disadvantage is that I have to run Eclipse to use it. Fortunately, I like some other stuff in Eclipse enough that I usually have it open.
This has been a somewhat interesting thread to read, though. It's like two groups of people, with each group having an argument with the other group, except neither group is having the same argument that the other group is having back with them... Several parts of it have come across to me as Blakey (with chorus) saying something that more or less amounts to "Have a CLI if you want it, but the GUI is more important, and the CLI and the GUI should both be making calls into the same API; the CLI should not be the API that the GUI uses; that is why *nix is stupid" and some other people retorting "Stop saying there shouldn't be a CLI; it should have a CLI first; that's also the API; if someone wants a nice GUI they can write one that performs the CLI calls in the background."
I may be reading that into it because I think that sort of situation is funny, though, rather than that actually being what's going on. Lots of times arguments are funnier if I make them up on my own.
-
@j_p said:
If I had to describe it in a sentence, it would be 'provide a comfortable user interface for semi-technical to technical users to manipulate data, where the data is mostly numeric and array-based and the manipulation mostly consists of statistical analysis and some arithmetic'. A bit unwieldy, but that's kind of what you expect when describing a programming language. What's the one thing python should do well? Execute python programs. Similarly, spreadsheets are visual R (or Matlab if you prefer).
You're assuming that spreadsheets are only ever used for numerical or mostly-numerical data.
And that they're designed for semi-technical people.
And that the person using it isn't just using it for read-only access.
You're assuming wrong.
-
@blakeyrat said:
what's the "one thing" a spreadsheet program should be doing well?
Manage and automate tabular data.
Or is that two things?Or maybe it's too vague. How many things is "tabular data"? How many kinds of actions is "automate"?
-
@j_p said:
for semi-technical to technical users
So non-technical users couldn't possibly have the kind of problems a spreadsheet would solve? That's bollocks.
@j_p said:
spreadsheets are Matlab
That's rather limited thinking.
-
@j_p said:
"Do one thing and do it well" is, of course, a rule of thumb. A more accurate way of saying it might be "If the functionality can be seperated, put serious consideration into seperating it into two programs", but that doesn't flow as well.
I think this is the real key. Blakey's spreadsheet question is a misinterpretation (from someone smarter, I'd assume deliberate, but he's earned no credit here).
@Einstein said:
Everything should be made as simple as possible, but no simpler.
But as already demonstrated, no one will ever agree on something like, "What should this application do?" Or what "simple" even means in this context (let alone what the context itself is or should be). It's probably racist just to consider context. Maybe I just need to check my CLI privilege.
-
@kilroo said:
It's like two groups of people, with each group having an argument with the other group, except neither group is having the same argument that the other group is having back with them...
I see it more like 3 groups:
1) there are people, who have problem, they want to solve, so they make tools to solve the problem (with UI good enought for them) - like Linus with git - and offers the result for free
2) there are people, who say: "Great, I have similar problem, which I can solve with your tools.Thank you. I may even contritribute a little, take this, what helped me better, if you want" - like me
3) there are people who say: "You all are idiots, I want YOU to spend a lot of time for FREE to solve MY problems the way I like to have solved them. No, I will not contribute nothing, it is YOUR work to make ME happy" - like Blakey (with chorus)
-
@gilhad said:
3) there are people who say: "You all are idiots, I want YOU to spend a lot of time for FREE to solve MY problems the way I like to have solved them. No, I will not contribute nothing, it is YOUR work to make ME happy" - like Blakey (with chorus)
That's a bit odd, since it connects to #1.
But the wisdom is: whatsoever man creates, that he shall also support.
You don't just make a thing, and throw it out there and ignore the desires from "your" users. If you don't want to be responsible for a product, don't publish it.
-
@dhromed said:
You don't just make a thing, and throw it out there and ignore the desires from "your" users. If you don't want to be responsible for a product, don't publish it.
Why not? What's wrong with putting something out there, in the words of the GPL, "in the hope that it may be useful, but WITHOUT WARRANTY OF ANY KIND, not even an IMPLIED WARRANTY of MERCHANTABILITY, nor of FITNESS FOR ANY PARTICULAR PURPOSE"? How does doing that make the world anything but better?
The mistake that people who take the line you just have, it seems to me, is considering an open source project to be a product. It isn't any such thing. Products are made to be sold. Producers have an expectation of direct reward for the act of production, and if that expectation is to be reasonable it does come with a reciprocal expectation that the product will be of merchantable quality and will be fit for the purpose advertised. Open source projects are not products; they are gifts.
It's notable and remarkable just how many of these freely offered gifts do turn out to be workable and in many cases superior alternatives to products, but that doesn't justify anybody taking the position that any such freely offered gift that doesn't happen to suit them is therefore "crap". All that does is make them come across as an ungrateful whiner with entitlement issues.
-
@kilroo said:
It's like two groups of people, with each group having an argument with the other group, except neither group is having the same argument that the other group is having back with them...
I don't think these groups can hear each other for all the shouting.
@gilhad said:
1) there are people, who have problem, they want to solve, so they make tools to solve the problem (with UI good enought for them) - like Linus with git - and offers the result for free
Perhaps one could assert that the difficulty that arises is when new software continues to be producing using outdated philosophies.
It's a deep and complex problem, as graphical interfaces are hard. Take Exchange 2007. Microsoft realised, correctly, that it was important to be able to script it in PowerShell. The Exchange GUI was redesigned to match the new architecture, but this resulted in a lot of tasks disappearing from the GUI. The ability to review mailbox sizes across a mailbox store was removed, and that's precisely the kind of task that graphical interfaces were created for, with scrollbars, clickable column headings to sort, a filter toolbar etc. Instead, you have to fuss about with PowerShell's verbose, text-oriented environment. Unless you're constantly working with Exchange, instead of clicking an "obvious" button (as much as Exchange's UI was ever "obvious" …) you now can't do many tasks without resorting to researching what to type in, which you'll forget again immediately afterwards.
Microsoft evidently didn't want to expend the effort duplicating all that functionality in a graphical interface, and Exchange 2013 has drastically reduced the graphical interface aspects.
I don't know for sure why this is. The Exchange UI was written in Microsoft Management Console in .NET, and you would like to believe that, for example, it would be possible to bring up a basic list of mailbox sizes in .NET with a few minutes of typing. It's one line of PowerShell, so surely you could at least get a default list plumbed into a list view in minutes with a simple data binding?
We should be at the point now where writing data-oriented programs that are graphical, scriptable, and even recordable, is trivial. The advances in computer processing power and capability should mean that most time spent programming should be in defining how your program is different from everyone else's, not in boilerplate repetition.
You have to remember that Blakeyrat is a former Mac user, where Apple set a philosophy back in 1992 of programs utilising a powerful self-documenting combined IPC/scripting/recording framework, something the rest of the world has never figured out yet. Fast-forward to over twenty years later, and we seem to have gone backwards. Nothing suggests to me that .NET as a framework provided any of the revolution in software design that it could have done. .NET appears to be a kneejerk overreaction to the intense butthurt at Microsoft caused by too many programmers who can't manage pointers and buffers, with little thought given to anything else besides.
You're not going to see a desktop software revolution until program construction is rethought from the ground up, and all the software design and construction problems we have now (including how every Windows program marches to the sound of a different drum) are effectively swept away into obsolescence. However, the industry is now being dragged by powerful currents in the direction of something worse ...
-
@flabdablet said:
What's wrong with putting something out there, in the words of the GPL, "in the hope that it may be useful, but WITHOUT WARRANTY OF ANY KIND, not even an IMPLIED WARRANTY of MERCHANTABILITY, nor of FITNESS FOR ANY PARTICULAR PURPOSE"?
Yeah, that's the letter of the law, but not the spirit of creation as I see it.
@flabdablet said:
is considering an open source project to be a product. It isn't any such thing.
I think it's wrong to dump your halfbaked shit onto the public. And it is halfbaked by definition. if you're going to make an effort to maintain it or play owner of the product then it's not halfbaked anymore.
@flabdablet said:
Products are made to be sold.
Products are things that have been produced. There's no implication of commerce.
@flabdablet said:
Producers have an expectation of direct reward for the act of production
No they don't you filthy capitalist pig*.
(For the purposes of the argument, we will not count "goodwill" or "personal satisfaction" etc. as direct rewards)
@flabdablet said:
Open source projects are not products; they are gifts.
Make it a good gift, instead of half-baked shit. Don't give me a dirty stick you found in the yard.
@flabdablet said:
It's notable and remarkable just how many of these freely offered gifts do turn out to be workable and in many cases superior alternatives to products
Yes, it is remarkable, because people usually dump their half-baked shit onto the world instead of taking some time to turn it into a product that they own and maintain. It shouldn't be remarkable. It should be common. It should be a point of pride when the hyper-advanced aliens come visit our tiny world. Look ye what humans do! Is it not great? they will say. Cookies for everyone!
@flabdablet said:
that doesn't justify anybody taking the position that any such freely offered gift that doesn't happen to suit them is therefore "crap".
I'm not taking that position.
I'm saying you take some responsibility for what you put into the world.
@flabdablet said:
How does doing that make the world anything but better?
I'm in favour of two things that are each half of the equation to make a better artisan world:
- make creation tools as accessible, easy and widespread as possible;
- teach creators to put some effort in, and make them understand their responsibilities as creators.I do not want any mechanical or systematic limitation of creative tools. The same openness that allows the motherfucker to shit on the human canvas will also allow a poor genius to enrich the world with their bright works.
*) hyper-irony-bole
-
@dhromed said:
Make it a good gift, instead of half-baked shit. Don't give me a dirty stick you found in the yard.
But that's the thing: sometimes a dirty stick is just what somebody needs. Obviously the person who made it needed one. And it's not like merely making a dirty stick available is forcing you to pick it up and use it to clean your teeth.
And if what you need is a clean stick, or what you need is dirt, then you might well find that beginning from a dirty stick is easier than beginning from nothing.
I absolutely disagree that creators have any responsibility at all. That clearly makes me an artist, and you a mere pleb, so stick that in your hyper-irony-bole and smoke it. Here, have a dirty stick to tamp that down.
-
I made some ninja-edits. Might want to re-read, if you have the patience.
-
@dhromed said:
I think it's wrong to dump your halfbaked shit onto the public. And it is halfbaked by definition. if you're going to make an effort to maintain it or play owner of the product then it's not halfbaked anymore.
This seems like it directly contradicts "release early and release often." I think it's fair to say that ideally these projects would be released with excellent usability and the features that everybody wants. I'd also like a million dollars. Even so, the stuff that's successful (by the standard of being popular, or at least widely used) tends to get supported by others in addition to the original devs. The various GUI add-ons for git are examples (or svn or hg and probably others, too).
And your idea of half baked is almost certainly different than mine or anyone else. That doesn't make anger against people who don't make software to your standards illegitimate, but it doesn't mean I (or the people who develop it) have to care about your rants, either.
-
@boomzilla said:
I think it's fair to say that ideally these projects would be released with excellent usability and the features that everybody wants.
That's impossible, obviously. Things change and you can't foresee everything.
I'm just opposed to a fire-and-forget mentality, and the idea of "I've given you a free gift therefore you can't demand anything from me" as an absolutist principle is unethical as I see it, so I try to strike at it when I notice hints of it.
@boomzilla said:
And your idea of half baked is almost certainly different than mine or anyone else.
I can make a thing for myself, as I've done many times.
If I am going to "release" it, then I'm going to put some extra work into it to make sure it's as drop-in as possible and needs few manual steps to make work. You gotta clean up your stick. If I foresee or notice that it's big or popular, then I'm going to make sure I free up time to maintain it, or at least point to someone who might do that work.
I like to think that PJH and Galgorah think I did that for my part of our mod-task userscripts. PJH certainly did for his part.
-
@dhromed said:
I'm just opposed to a fire-and-forget mentality, and the idea of "I've given you a free gift therefore you can't demand anything from me" is unethical as I see it, so I try to strike at it when I notice hints of it.
I think "fire and forget" is fine. If it's worthwhile, someone else may take up the reins if I release something and have lost interest or time or whatever to keep working on it. But that's different than having different priorities than some of your users. There's a lot more that goes into a serious effort than, "This would be cool!" Shoulder aliens should be aware that I'm not saying you shouldn't try to get a developer to implement / fix the stuff that's important to you. But I'm probably going to ignore you if you want me to care about your random issues or to think that the guy who isn't doing what you want is a terrible person because of that.
-
I suspect I'm not the only person troubled by the intense clutter on the web. For every good website, there are a hundred dubious-looking clone versions of it, probably with stolen material. For every good utility program, there are a hundred dubious-looking clone versions of it.¹
In the Windows world, this has massive implications for malware if you opt for one of these dubious-looking programs; trouble is, most people cannot tell the difference.
In the open source world, I imagine it's more a problem of time wasted battling with some stupid program when you should have gone with a better one, were you able to see the forest for the trees. How many alternatives do you have to try before it becomes clear that wrestling with some pig of a program is less pain than trying to find a better one?
¹Except anything I need, and I can never find even one single offering, so I get to write the half-baked dirty stick, which doesn't really matter as nobody ever wanted a program to do that anyway, hence none existing prior to that.
-
@boomzilla said:
But that's different than having different priorities than some of your users.
If you're thinking about your priorities and those of your users, then you're well beyond fire-and-forget land and into The Valley of Product Owners.
@boomzilla said:
If it's worthwhile, someone else may take up the reins if I release something and have lost interest or time or whatever to keep working on it.
You can't pass on the reins if you haven't held them yourself for a while. Fire-and-forget means you slap the horse and let someone random person try to stop it after it tramples over other people's business.
@boomzilla said:
But I'm probably going to ignore you if you want me to care about your random issues or to think that the guy who isn't doing what you want is a terrible person because of that.
I agree.
-
@Daniel Beardsmore said:
In the open source world, I imagine it's more a problem of time wasted battling with some stupid program when you should have gone with a better one, were you able to see the forest for the trees. How many alternatives do you have to try before it becomes clear that wrestling with some pig of a program is less pain than trying to find a better one?
I seem to have been lucky in my searches in the past in that the first or second package I've tried seems to have been a reasonable fit for my needs.
Last one I looked for was for a time tracker when Accounts were vaguely interested in how much time I'd spent on which projects during the week - first one I tried was usable. The fact that it's largely redundant now since we're supposed to normalise our hours to 37.5 hrs a week is more of a work WTF than anything else (the only weeks I actually work less than 37.5 hrs are those where I have 2 or more weekdays off work.)
-
@PJH said:
I seem to have been lucky in my searches in the past in that the first or second package I've tried seems to have been a reasonable fit for my needs.
It probably depends on the type of program, to be fair, although I did narrow my assertion to utility software. For example, something that graphs a host's ping times in a tray icon? Nothing that I know of ... I should write one, to be honest, since nobody else ever will. Anything involving specific tweaks to video files? No end of useless trash that doesn't work, all very dubious-looking. Somewhere there's a website full of someone's seemingly fire-and-forget document processing tools (e.g. join and split PDF pages), and I don't know whether those ever worked.
-
@Daniel Beardsmore said:
I suspect I'm not the only person troubled by the intense clutter on the web.
Format http:/*.*.* /s /f
That will take care of it.
-
@flabdablet said:
Why not? What's wrong with putting something out there, in the words of the GPL, "in the hope that it may be useful, but WITHOUT WARRANTY OF ANY KIND, not even an IMPLIED WARRANTY of MERCHANTABILITY, nor of FITNESS FOR ANY PARTICULAR PURPOSE"? How does doing that make the world anything but better?
It takes more time to find something working among the 57 broken open source libraries that talk to the Twitter API than to just do it your damned self. I actually wasted weeks in that exact scenario a couple years ago.
Your statement sums up to: "what's wrong with wasting people's time by creating 50 versions of the same thing, none of which are complete or working, but all of which claim to be complete and working on their web page?" To which the answer is: "if you do that you're a dick." In my eyes, that doesn't make the world better.
@flabdablet said:
The mistake that people who take the line you just have, it seems to me, is considering an open source project to be a product. It isn't any such thing. Products are made to be sold. Producers have an expectation of direct reward for the act of production, and if that expectation is to be reasonable it does come with a reciprocal expectation that the product will be of merchantable quality and will be fit for the purpose advertised. Open source projects are not products; they are gifts.
They're anti-gifts. They promise something great, but end up stealing your time.
Look, I have an old cast-iron boiler in my shed. It's worth maybe $50, assuming it's not crawling with lead paint and asbestos (which it probably is). It'll cost at least $300 to rent a truck with hoist to actually move the thing. If I give you my cast-iron boiler, am I giving you a gift? No I am not. I am being a dick.
@flabdablet said:
It's notable and remarkable just how many of these freely offered gifts do turn out to be workable
Maybe if there was a way to filter the ones that actually work from the ones that don't, this would be useful to me. There isn't, so it's not.
@flabdablet said:
All that does is make them come across as an ungrateful whiner with entitlement issues.
Congratulations, I've given you a gift! It's a cast-iron boiler in my shed! You haul.
-
@Daniel Beardsmore said:
It's a deep and complex problem, as graphical interfaces are hard. Take Exchange 2007. Microsoft realised, correctly, that it was important to be able to script it in PowerShell. The Exchange GUI was redesigned to match the new architecture, but this resulted in a lot of tasks disappearing from the GUI. The ability to review mailbox sizes across a mailbox store was removed, and that's precisely the kind of task that graphical interfaces were created for, with scrollbars, clickable column headings to sort, a filter toolbar etc. Instead, you have to fuss about with PowerShell's verbose, text-oriented environment. Unless you're constantly working with Exchange, instead of clicking an "obvious" button (as much as Exchange's UI was ever "obvious" …) you now can't do many tasks without resorting to researching what to type in, which you'll forget again immediately afterwards.
This is what I call "listening to the detractors".
There was a video game called Prince of Persia: The Sands of Time. It was brilliantly-written, had excellent environmental obstacles and traps, great characters, great voices, extremely immersive, full of amazing voice talent, was well-received. It even included a full version of Prince of Persia 1 and 2 at no additional cost as an easily-found "easter egg". But it had weak combat.
When it came time to write the sequel, the developers asked people who weren't fans of Sands of Time what they should change to win them over. Those people inevitably said, "the combat was weak", and so they endeavored to make the combat better-- and what we ended up with is a game with a crummy, nonsensical story, bad environments, bad characters (chainmail bikini wasn't enough, so they made a chick with a PLATEMAIL bikini-- ouch!), the Prince's character became a one-note cliche with no character development, the female lead disappeared altogether, crummy voice work-- but great combat. It was reviewed poorly and sold poorly.
Why? Because the fallacy here was they were thinking, "if only we could appeal to that last 10% of people who didn't like the original game...". But they didn't ask the 90% who liked it *why* they liked it, they only asked the people who didn't like it... they ended up (maybe) appealing to the 10% while turning off the 90%. And the kicker is: those 10% wouldn't buy it anyway, because frankly Sands of Time was such a great game that if you don't like it, you simply do not like *that entire genre*.
Microsoft has had the same thing going on recently. They go to LUGs and ask, "why don't you like Exchange?" and those people give them bullshit answers like, "it's not scriptable enough!" or "the GUI on Windows Server wastes resources!"*. Microsoft listens to these people and changes the product accordingly. But who aren't they listening to? The administrators who have been using and loving Exchange for decades. Does Microsoft seriously believe these Linux users are going to start buying and liking Exchange? No, because the reason Linux users don't buy it has nothing to do with scripting or having a GUI, it has to do with them hating Microsoft at a fundamental level.
It's kind of sad, really.
*) that concept is so hilariously ludicrously wrong it's hard to believe even the Linux-y-est of Linux users even believes it themselves.
@Daniel Beardsmore said:
We should be at the point now where writing data-oriented programs that are graphical, scriptable, and even recordable, is trivial. The advances in computer processing power and capability should mean that most time spent programming should be in defining how your program is different from everyone else's, not in boilerplate repetition.
Open source products all use C++, they're nothing but boilerplate repetition.
@Daniel Beardsmore said:
You have to remember that Blakeyrat is a former Mac user, where Apple set a philosophy back in 1992 of programs utilising a powerful self-documenting combined IPC/scripting/recording framework, something the rest of the world has never figured out yet. Fast-forward to over twenty years later, and we seem to have gone backwards.
Right. And Amen there's someone on this board who has used Mac Classic and seen the light, so to speak.'
@Daniel Beardsmore said:
Nothing suggests to me that .NET as a framework provided any of the revolution in software design that it could have done. .NET appears to be a kneejerk overreaction to the intense butthurt at Microsoft caused by too many programmers who can't manage pointers and buffers, with little thought given to anything else besides.
Let's be fair: the Windows API really sucked, and .NET did a lot to clean it up. But right, it did not address GUI scriptability which remains awful in Windows and all Unix-derived OSes. (The real problem with .NET is Microsoft won't fucking commit to it. They make great .NET products like XNA, then a few years later say "nope, no support for that suckers.")
@Daniel Beardsmore said:
You're not going to see a desktop software revolution until program construction is rethought from the ground up, and all the software design and construction problems we have now (including how every Windows program marches to the sound of a different drum) are effectively swept away into obsolescence. However, the industry is now being dragged by powerful currents in the direction of something worse ...
Again: amen.
The problem is that people who write software now, even people writing OSes, have no conception of the history of software development. They've never even USED any OS except Windows and Unix-alikes. They've never booted up an Amiga, just to check out Workbench. Or sat with Mac Classic long enough to script some GUI apps together. Or developed any familiarity with BeOS (and therefore realized: not only is the concept of tabs in applications a lot older than Firefox, but BeOS is the only OS that actually *did it fucking RIGHT*).
There's no history in IT. Nobody's comparing this shit. So it's all been done before, but at the same time it all gets done over and over and over again and nothing ever moves forwards. It's the CADT development philosophy, but endemic to the entire industry.
-
@blakeyrat said:
It takes more time to find something working among the 57 broken open source libraries that talk to the Twitter API than to just do it your damned self. I actually wasted weeks in that exact scenario a couple years ago.
That's even worse than trying out software programs, as there's much more work involved in determining whether some library actually does what you need. It's also more insidious, as you can find yourself mired in bizarre problems that would be far easier to follow and resolve if you'd written the library yourself and were familiar with what goes on inside. At this stage it might be too late to turn back and try an alternative … it might not even be the library!
I don't use a lot of library code, but I do remember my eyes nearly bursting after discovering that Perl could no longer do maths, before realising that someone had completely stuffed up numerical operator overloading. Fortunately that was only a small, and comparatively simple problem.
There will always be bugs, but every rival product or fork splits up the number of eyes you have looking at the codebase and the final product, if indeed anyone is even watching them at all. At the same time, sometimes old, abandoned gems from years ago actually work better than anything else.
Sadly I never did learn to say "Hu-mans" the way Quark did.
-
@blakeyrat said:
The problem is that people who write software now, even people writing OSes, have no conception of the history of software development. They've never even USED any OS except Windows and Unix-alikes.
Indeed! I still think we should adopt the RISC OS mouse button assignment. Adjust (right) is the complement of Select (left). In fact, you're one of the few people who will understand this concept. Adjust frequently did what Macs used modifiers for: drag a window while leaving it in the background (command-drag), close the parent folder window while opening a child (opt-double-click), etc — it's just that, by having a three-button mouse, you could do this so much easier.
Adjust-click would also reverse the direction of scrollbar buttons, toggle folder item selection, things like that. You just didn't need to reach for any modifier keys. Adjust+Close may have been iconise, as that didn't have its own title bar widget. Middle mouse ("Menu") would open a menu: all menus were styled like context menus; sometimes they were contextual, but often times the contextual part would be one submenu, with the floating menu functioning as the whole menu bar.
Maybe one day I'll find a use for my experience with all these old systems.
-
Allahu Akhbar!
@blakeyrat said:
@Daniel Beardsmore said:
...Exchange stuff...
This is what I call "listening to the detractors".
But was it really? I see how that fits your preconceived notions, but is there actual evidence that MS was talking to LUGs instead of Exchange admins (and how much overlap is there between the two, anyways)?
@blakeyrat said:
So it's all been done before, but at the same time it all gets done over and over and over again and nothing ever moves forwards.
That's just so much bullshit. I understand that you don't see enough of what you'd call Progress, but you spout ignorant and incorrect nonsense all the time, so who cares? There are lots of things I'd like to see changed that aren't going to change. A lot of it comes from the inertia of backwards compatibility and the reality that Doing Something New often sounds awesome until you get into the details and then you go back to what you had.
-
@boomzilla said:
But was it really?
Yeah, it's how it works when you ask a ton of people for improvements. You get a list of faults.
-
@blakeyrat said:
Your statement sums up to: "what's wrong with wasting people's time by creating 50 versions of the same thing, none of which are complete or working, but all of which claim to be complete and working on their web page?" To which the answer is: "if you do that you're a dick."
But those 50 versions were presumably created by 50 different authors, each of whom was clearly dissatisfied in some way with the ones available before theirs. I disagree that this makes any of the 50 authors a dick, except possibly for the part about publishing claims of being complete and working; I don't know how stable the Twitter API is so I'd be premature in castigating an author for a claim of completeness and correctness that might have been accurate at the time of publishing. It's a pity you wasted your time, but you did always have the option of finding a commercial product instead - unless all of those are broken as well, which having worked on many projects involving useless commercial libraries I know is a distinct possibility. And if that's the case, your argument ought to be directed against authors of Twitter API libraries generally, rather than picking out the open source guys.
@blakeyrat said:
It takes more time to find something working among the 57 broken open source libraries that talk to the Twitter API than to just do it your damned self. I actually wasted weeks in that exact scenario a couple years ago.
I presume you did then do it your damned self. Did you happen to make the resulting library - the only one that actually works, apparently - available anywhere? Because that would be a generous thing to do, even if you then abandoned it completely and took no responsibility at all for maintaining it.
@blakeyrat said:
Congratulations, I've given you a gift! It's a cast-iron boiler in my shed! You haul.
I have no need of a cast iron boiler so I'll pass, but if you were to list that on Freecycle, somebody probably would take it off your hands. One man's trash is another's treasure, and exactly the same thing applies to free software.
-
@blakeyrat said:
Why? Because the fallacy here was they were thinking, "if only we could appeal to that last 10% of people who didn't like the original game...". But they didn't ask the 90% who liked it why they liked it, they only asked the people who didn't like it... they ended up (maybe) appealing to the 10% while turning off the 90%.
You did notice you just undermined your entire argument for Git not having a CLI, yes?
-
@blakeyrat said:
The real problem with .NET is Microsoft won't fucking commit to it.
Since PowerShell is based on it, and the PowerShell designer and project lead is now the lead architect for their server operating systems, that's probably fixed.
