On Thu, Dec 20, 2012 at 7:34 AM, c.
pretty sure it was an older version of the MinGW track, as I still opt to use SciTE for windows as a result. Don't know the name of the terminal it uses, but it seems as good as any.
>perhaps we could have a dedicated blog like this one, but about
See, while I typically try to ignore these philosophical threads, gems like this pop up. Found parts of his latest highly entertaining... in particular:
"So I was planning to tweak this code and send it back with a note about
“here’s a nice way to do it better and let the computer take more of
your mental load” (this person teaches a course on MATLAB for
scientists, you see, so I want to slightly reduce the f###ing brain
damage that gets propagated out into the academic world.)"
Made my morning.
About a GUI (which seems to have two meanings here, 1 is the user interface, 2 is using the program to creating interfaces.) Remember when all MP3 player interfaces sucked and then the iPod came around? (maybe not, but that could say more about the person reading this.) It wasn't overly new, other players did the same thing, some did more. But BAM... it won the marketshare game. AND YOU PAID (still pay) THROUGH THE NOSE FOR IT.
Can't/Won't pay for that? Then you get whatever's next best, not as shiny, but still gets the job done. my $15 Sansa with a broken LCD for example.
Next, I'm comfortable working Octave from a CLI. But I take issue with anyone who says a CLI should be enough for anyone. A CLI presents a barrier to entry. Why? because it's non-intuitive. Why? because it likely requires prior knowledge separate from the knowledge that got them to the CLI if they're using a graphical Windows/Linux/Mac OS. Once the CLI appears, they need to know what to do. A GUI takes advantage of visual cues and familiarity to guide the user. A CLI requires the person to know what help they want before they can get it. Now, Octave/ML likely require someone to know at least a tiny bit more in advance than for using an MP3 player. But if they just know they want to 'do some math', there would hopefully be an obvious path to starting to learn. and 'read this 300pg pdf' will send many an engineer back to ungly Excel-algorithms. :)
Many systems will have the entry prompt or MOTD say 'type help for a list of basic commands'. From there, a list appears and the user can use those visual cues to start fumbling around. A GUI takes advantage of a modern user's built in tendency to 'click around' for what looks right. It takes advantage of the parallel processing nature of visual learning, with a minimum of prior knowledge required. In Octave, if you intuitively type HELP, you are informed that you can get help with individual commands by typing 'help NAME'. but what if I don't know the name? I might find it in a GUI list of commands, or list of help topics, but now I just have the blinking cursor.
help integrate --> 'integrate not found'.
help quad --> Numerically evaluate the integral...
how would a user intuitively know the name of one numerical integration function is quad... he wouldn't. now, the 'see also, at the bottom of many helps is immeasurably useful. it provides visual cues in a parallel format for further exploration. user knowledge of how to overcome the initial CLI progress barrier can't be assumed since the DOS prompt disappeared under XP. how do you get them started...
This is in no way unique to Octave among the free software community (see, I didn't say open source. I may be learning.). Time gets spent by volunteers on what is useful to them. they're used to working with the program as it is. they'd often rather spend time on what's a barrier to them getting things done, which is rarely the interface. There's a reason non-free software can have a nicer interface. It's because they can pay developers to spend time on that aspect. you want a free tool, expect to get one not tailored to your likes. you want one that is? free may not be your best option.
Alright, guess it's time to get to work now.