@blakeyrat said:
@j_p said:That solution is just as vulnerable to UI changes as CLI-style interfaces, and it isn't as powerful. It's useful, definitely - I've used a similar feature in Notepad++ - but it's not a general purpose solution for scripting. Consider:
- How do you represent 'do something to everything in this variable-sized list'?
- If a program updates and control IDs change, your script can break.
- If control IDs aren't systematic it might be difficult to branch well. Say there are three radio buttons and you want to press a different one depending on some other state. Hope they're named something like 'radio1', 'radio2' etc. so that you can branch to them easily.
- If programs have custom controls, then they need to package and send the user-action event themselves, for the OS to record. That means scripts don't necessarily match up to what you did, because programs can take an arbitrarily long amount of time to make one of those objects.
- The editor for these script files must be getting pretty damned complex if it needs to do variables, branching and looping. Is that all GUI too, or does the script you've recorded turn into a textual representation that you can edit easily? I don't know about you, but I'm not so sure that dragging around boxes in a flowchart is a great way to program.
You don't know a damned thing about how AppleScript worked.
Not ever having used it, obviously not. I took a stab based on what I'd read so far, apparently it worked differently (Daniel Beardsmore actually explained it, notice), and then I discussed some of the implications of /that/ way of implementing it. Most of those criticism don't apply to the programs-export-verbs model, it's true (although I'm not entirely clear here on how the recorder turns actions you're taking in the UI into verbs to record). And if you want to do anything interesting in a script, you need to open it up in a text editor and write some text. Because it's basically a batch-processing CLI. Programs are programs, options to that program are verbs. The only difference is that it's got a way of interpreting a sequence of actions you take in the GUI and turning it into a script, which is only useful if you want to literally do the exact same thing over and over again.
BTW, Notepad++ can't even *draw menus* correctly, so it's not really a surprise its scripting feature is fucked.
I didn't say its scripting features are fucked. It's got a record-my-input-then-play-it-back feature, which is what I thought you were describing before. Its scripting features are entirely different. And yes, it does some weird things with menus, and the MRU tab switcher is just wrong on every level. It's still the best text editor I've found to date.
I'm amused at your "Doesn't do this thing correctly, therefore the entire thing is wrong" approach. Visual Studio doesn't do /tabs/ correctly. The 'next tab' shortcut goes in MRU order, and tab order in the tab bar isn't sorted in MRU, so you bounce around tabs at semi-random. Is it a totally awful IDE?
@j_p said:Windows and Mac OS have something like 98% of the /desktop/ OS market. If you consider only markets where scriptability is an important feature, surprise surprise linux is more popular.
If scripting were easy enough that anybody could do it, then it would be used on all types of computers.
This is a self-fulfilling prophecy: Linux scripting is so difficult that only those who devote their lives to maintaining Linux servers can pull it off. Therefore, only servers support scripting well. Gee, when you put it that way, it sounds really fucking stupid!
I don't even understand what you're getting at here. My point is that CLI-style environments are superior for scripting. I present as evidence the fact that in environments where scripting is regularly used, people tend to use operating systems that provide CLI-based, pervasive scripting. Because its better for being able to write scripts. You seem to be claiming that users don't know that scripting will solve some of their problems (probable), but I have literally no idea where the chain of logic goes from there. Again, do you really think that the only reason linux is so popular for web servers, including those for giant corporate entities like Facebook and Google that would benefit incredible amounts from even minor technical advantages, is because its free? You make a claim like that and then point out the Windows/Mac dominance of the desktop OS market as if network effects and being there first didn't play a part?
@blakeyrat said:
@j_p said:I think you're underestimating exactly how easy it is to preserve backwards compatibility in a CLI interface. You've got a tool that does something to input. What 'tool some input here' does is unlikely to need to change to improve the UI. When you start adding options the same thing happens - why would you need to change the behaviour of grep's recurse option?
I don't know what grep's recurse option does, so I can't answer your exact question. But how about this example: you have to change the CLI command because you find out it has a data-losing bug, or a security flaw.
grep does regular-expression-based searches. The recurse option makes it descend folders when searching - by default it only searches the working directory.
And in that scenario, it depends. If the bug is incidental to operation (say, if you pass it too much data it buffer-overflows) you just fix the bug. Any scripts that break were doing something they shouldn't have been doing anyway, and there probably aren't many. The tricky case, of course, is when the bug is implicit in the command - the gets() function in C is the best example I can come up with off the top of my head, even if it's not a CLI command. gets() retrieves a string from stdin into a pointer you provide, without any way of limiting length or getting length, so it's a guaranteed buffer overflow bug you can't do anything about if you use the function. It's very, very old, and still in the standard because of backwards compatibility. Every compiler and code-lint tool on earth will throw warnings at you if you use it, though. That's the solution here - if the foo -k option is fundamentally buggy or a security flaw, literally can't be made safe while doing the same thing, then you replace the functionality by adding in a new switch or whatever that does whatever similar useful thing that isn't a bug the original switch was intended for, you keep the buggy one in, and you make the program spit out warnings when its used while still doing what the command does. Same way you would if your DLL exports a function that's fundamentally buggy or a security flaw.
@j_p said:Usually improvements come in the form of new features and options. Or new programs that support the interface of the old tool but do more with it - like flex and bison over lex and yacc (lex/flex generate lexers for a language from a regex-based desciption of the tokens in it, yacc/bison generate recursive-descent parsers for a language based on an EBNF grammar for it).
So you're saying:
1) The only way to improve a CLI program's interface is to write an entirely new CLI program
2) ... which must then support the exact same UI as the old one
Which sums up to: there is no way to improve a CLI program's interface. Which is I believe the exact argument I've been making.
'adding new features and options'. Or in the case of bison, supporting more classes of input than yacc. Those are improvements. To the interface.
@blakeyrat said:
@j_p said:If you want to completely overhaul the interface, you make a new tool that does the same thing with a totally different interface, and old scripts will continue to work while the new tool has a fancy-pants new interface that scripts can start using.
Oh, so the CLI has a versioning system so the scripts can specify which version they were built for? That is sure a handy feature! Too bad you made it fucking up and it doesn't exist.
Either that, or you're saying the system needs to have literally every version of every CLI tool ever made on it simultaneously to avoid breaking old scripts. And if one of those tools uses the command "search" (even if it does useless crap, or nobody's used it in decades) you can never, ever, ever make a new "search" that works better because of the polluted namespace.
To be fair though: your idea here could actually be made to work, if: 1) there were some form of versioning system, 2) there were some enforcement that scripts were using a "version marker" or however you implement 1, 3) the app disk size were small enough that it's not a big deal. It still breaks in the case of changes due to security, as you have to change the older versions as well.
I didn't say anything about versioning. I said you write a new tool and let the old one die, and people will use whichever one they want. However many scripts do you think still reference cvs, or even rcs? Probably some. You can install rcs if you've got one of those scripts. But if you're most people and don't, then you don't run apt-get cvs (your distro, of course, won't install it by default).
You know when I brought up DLL hell earlier? How, exactly, do you think that was solved? I'll give you a hint: in c:\windows\system32, I currently have d3dx9_24.dll through to d3dx9_43.dll. God only knows how many versions of the .net runtime I've got installed. How come the have-a-copy-of-every-version solution is fine for git.dll if it's not fine for git?
@blakeyrat said:
^- this is the key point that j_p wasn't getting.
You don't script "click the second radio button on radio button group
'Gender'", you script "set the gender to male". Now when the program
adds a new gender (indeterminate), your script didn't break. Magic.
This is what happens when people actually *think* about the OS
and how it should work and spent 75% of the time in the designing room
and only 25% in the coding room. This is the difference between a
professionally-designed OS and a pile of glommed-together shit.
'foo --gender=male' doesn't break if 'foo --gender=indeterminate' becomes an option either.
@blakeyrat said:
Mac programs were scriptable, because it would be stupid for them not to
be. If you implemented AppleEvents, you for thousands of features from
the OS *for free*. (It's the same argument for using native widgets as
opposed to drawing your own.)
And all the accessibility features of Mac Classic, IIRC, were based
on AppleEvents, so if you wanted to sell your application to the
government you were required to implement it, basically. (How does Linux
handle this, BTW? Do Linux GUIs even *have* accessibility features? Do
they meet the government standards?)
But how scriptable? Does your text editor know what a paragraph is? The burden of implementing each verb is on the developer of each program, and I rather doubt the OS gives you much extra if you teach your program about concepts like that. The beauty of a CLI approach to scripting is that its the default. It doesn't require any effort. It's not an inducement to make your program script. Its so much of a default you can't even opt out.
I haven't used Linux as a desktop OS for a few years now, and I've never needed accessibility features, but they definitely do have them. What mechanisms they use or whether they meet certain government standards, I couldn't say.
That's true of AppleEvents also. Unless, again, the developer of the
software expended MORE effort to make his program WORSE. But you can't
control for that.
Is my model for this right? At the moment I'm picturing the design as:
- All input events to the program are AppleEvents
- The program can post itself AppleEvents it constructed and defined itself (Presumably its got some way of informing the windowing system that the AppleEvent that triggered it needn't be recorded)
- An AppleEvent represents an action of some kind - a verb - with various other attributes
- You perform actions solely by responding to AppleEvents - every GUI interaction just posts AppleEvents to the relevant queue or acts on an AppleEvent
- Programs have a metadata table they export specifying what verbs they support and what parameters they need.
Because the only-perform-actions-by-responding-to-appleevents aspects seems to me like it requires more work from developers, not less. And if you don't have that, then you've got actions that might not be readily scriptable taken (for example, because they occurred in response to a mousepress event, and doesn't have a nice name as a result). And features Daniel was discussing above, like saying "set the first word of every paragraph to red" requires a fair amount of effort from the program to understand 'word' and 'paragraph', work that only really benefits scripting. And I can see custom controls wreaking hell on that design if they're not very carefully designed.
@blakeyrat said:
Of course! That might make it too easy to use! And we don't want that
rabble on our precious computers! We only one super geeky people who
love typing bullshit in 80x25 text windows!
You hate it *because* Apple endeavored to make it accessible to
everybody. Fuck that attitude. Computers are for human beings. Apple
understood that. Ubuntu gives it lip-service. You obviously still have
some issues with the concept.
If that's the only reason you think I might dislike natural language programming, you're more nuts than I thought. Natural-language environments inevitably aren't. Apple didn't solve general language parsing a decade ago. Usually you end up with a programming language where the keywords are all English, you can insert words like 'the' anywhere you want, and the syntax is a little flexible. Meanwhile, the language is weird to use and stilted because it tries to obey rules evolved for conveying information to a creature capable of inference with a great deal of context, rather than specifying processes for a pretty dumb machine with very little context, /and/ the language is close enough to natural language that all your natural-language-skills come into play and actively get in the way. I don't like natural language programming for the same reason mathematicians don't write proofs in natural language.
Yeah there is: CLI developers hate discoverability, they had usability, and they hate change.
Gasp! You've discovered my secret plan, as occasional user of a CLI, to make all software everywhere worse!
But you can't open two shells at once without a GUI!
And in any case, if you think "man" pages are good documentation, you and I will never agree on anything ever.
Errr... you've never actually used a linux system, have you? Basically every shell since god-knows-how-long has keystrokes for shifting between multiple terminals. CTRL-SHIFT-number is pretty common, IIRC. Often your GUI session is just running in one of those terminals, allowing things like restarting the GUI without restarting the computer (want to change some low-level config options or your graphics driver, X crashed, whatever reason). I wouldn't be surprised if some or all of them support having more than one of them on screen at once, in different columns or something.
And, y'know, I've never said GUIs are useless and awful and shouldn't exist. They're damned useful for a bunch of tasks. Even most tasks. I just think that textual input and the CLI is also useful for different sets of features and tasks, and that wrapping a GUI shell over a CLI engine is a good way of designing some programs.
The man pages aren't intended as documentation (often that's kept in 'info', or sometimes in your distro's native help system), they're a reference for people who already know roughly what they're trying to do. You don't learn how to drive grep by reading its man page, because it would need to teach you regular expressions first. You check man when you go "crap, does the pattern or the directory to search come first in grep? And is there an option to search text inside files instead of the file name?". You know, the same way inspection in IDEs doesn't provide the full documentation for the method you're pointing it at?
And how do you view diffs of a 3D model using Git, which only ships a CLI interface?
Christ, blakey, git doesn't do viewing diffs. It really doesn't. It calls out to other programs to do it. If you tell git "use cad-diff on files of the form *.cad" then when you get diffs for foo.cad it'll run cad-diff and ask it to display them. Whether that opens a 3D window or does ncurses-based text graphics or some fancy image processing to say "the other one's got more blocks in it" is up to that program. It's not a shitload of work - it's just coming up with a way of sensibly talking about differences for the things you're diffing. Hopefully the person who makes your CAD software already has a similar tool, because they'd be in the best place to create one. A GUI-based git would have the same problem, because they're not going to write a diff program for every possible filetype in the world.
I don't think you actually know anything about git's development. What happened was that the SCM that had been used for the linux kernel up until then (BitKeeper) withdrew the free license it had offered the Linux kernel devs, because someone reverse-engineered their protocols. So they needed a new SCM. Linus looked at the stuff available at the time (2005), decided that none of them met the needs of linux kernel dev, so they wrote their own. Specifically, it had to be fast to merge patches, it had to be guaranteed atomic, it had to allow for distributed version control (which was /new/ back then, keep in mind), and it should ideally use cvs as the model of what not to do. They needed it fast. So they wrote it fast (it was self-hosting in a /day/), and hey, they met their design goals. So they released it to the public because a) the public needed it to get the linux repository and b) if it was useful to them it might be useful to other people. And hell, if they were crowing maybe because its because they'd made a ludicrously fast source control system in a few months?
I don't even want to know what you'd consider a complete source control system to look like if you think git is only 9/10ths complete because you have to type things. I guess the existence of GUI wrappers like TortoiseGit doesn't help?
The help command is named "apropos"? DISCOVERABILITY!
'apropos' is a semi-standard alias for man -k - that is, search the man page for a string. So if you want to search but don't know what the command is, 'apropos search' will probably find it. Not so much a help command as a "What was the program again?" command. I thought you were literate, blakey - haven't you ever run into the word before? Regardless, it's almost certainly a command that's brought up in any kind of in-system help, 'man' on its own tells you about man -k which does the same thing, and most shells have a 'help' command. Yes, this isn't as discoverable as a big friendly window with buttons. That's the tradeoff for providing a readily composable and scriptable environment to do things in. Again, you're probably not running bash or equivalent exclusively unless you really have to.