Many bans on cellphones allow hands-free, but I've always felt it wasn't because it is better to use hands-free, but because it is impossible to enforce. (If someone can back up or refute my assumption, mod him up).
Either that, or someone argued that hands-free devices made cell calls in the car safer, so they could sell more hands-free calling devices.:)
The use cases, options, and interfaces are different for searching programming language source files, XML files, and other text.... Trying to force them into a single command line tool makes little sense to me.
You make a good point, but I think a tool that forces the different data types into a single mould could still be useful, even if it can't provide all the functionality that a specialized tool would.
Right, but what is there not already a parser for in CPAN? And if you are handy with perl, what kind of comparison is difficult?
I couldn't say, honestly.:) So write a Perl script that recognizes the input file types, chooses the correct module, implements some kind of matching rule syntax, and performs the comparison with whatever module you chose in step 2, and a plugin system so people can add more file types without modifying your script, and yes, you've pretty much got bgrep.
I think at that point you're beyond "Perl's capabilities" and into the realm of "capabilities of things you can implement in Perl".
This violates so many rules of the Unix philosophy that I don't even know where to begin...
I'll take this on. It's a subject that is of particular interest to me.
First of all, you have to consider whether it even matters that a tool violates "rules" of the "Unix philosophy". I mean, seriously, why assume that some system design ideas cooked up 30-40 years ago are necessarily the One True Path? Because "those who do not understand Unix are doomed to reinvent it poorly"? What if the designers in question do understand Unix? Or what if <gasp> they might actually have some ideas that surpass those of Doug Mcllroy, ESR, K & R, and so on?
Second, how does one account for tools like Perl? By many accounts it is one of the greatest Unix tools ever created. By combining the functionality and syntax of several useful tools, incorporating a rich regexp syntax, and binding it together with a general-purpose programming language, it can be a very versatile and effective tool. But it runs afoul of various "rules" as well: (I will use a star to mark the rules I don't particularly agree with)
"Write programs that do one thing and do it well" (Doug Mcllroy's summary of the philosophy, first clause)
"Clarity is better than cleverness" (ESR, second rule* - I think there are times when it's worth having a compact notation with a difficult learning curve.)
"Design programs to be connected to other programs." (ESR, third rule - I would argue that Perl encompasses as much functionality as it can to avoid having to connect to other programs - to avoid outside dependencies, to eliminate the problem of communicating with other processes, and to stabilize and simplify the interface to that functionality.)
"Design for simplicity: add complexity only where you must" (ESR, fifth rule... Though it could be argued that this is exactly how the design of Perl evolved.)
"Programmer time is expensive; conserve it in preference to machine time." (ESR 13th rule - Perl runs afoul of this if you accept the idea that Perl code is particularly hard to maintain. A language with a clearer syntax would, presumably, conserve programmer time.)
"Use shell scripts to increase leverage and portability." (Gancarz, 7th rule. I would argue that Perl scripting exists largely as a way to avoid solving problems in the shell language.)
Perl's biggest "violation", which it shares with other scripting languages, is that first one: "do one thing and do it well." Perl, Python, etc. are perfectly capable of doing a fork/exec or popen or loading a.so or whatever - but generally if there's a piece of functionality that people want to have in those languages, they re-implement it as a native library for those languages. Why do we accept so blatant a violation of what may be rightly considered the Unix philosophy? Because it works. It's useful. So a better question, then, is why is it that violating such an important "rule" is apparently necessary to create such a useful tool? There are various reasons: First, any reliance on an outside program is a maintenance issue. If your script is written for GNU find, for instance, and you move it to a system that has some other implementation of find, it may not work. Things can change from revision to revision as well. Second, it actually makes it easier to access the functionality, since you don't have to deal with writing out a stream of values and/or reading back a stream of results - when you call a Perl module, everything is neatly packaged into a (usually) synchronous call/result function interface, and presented as native Perl data.
Perl could be a contentious example - but I chose it because to me, it and other scripting languages are examples of people bypassing the shell environment, rather than augmenting it. I would go so far a
Is it really "writing another perl"? The meat of these tools (which, I think, aren't yet implemented?) is that they filter and compare parsed data structures - and provide plug-in hooks so people can insert parsers for additional data types. Certainly this could be done as a Perl library - and doing so might have some advantages over creating new tools with their own plug-in mechanism. But implementing bgrep and bdiff is nowhere close to "writing another perl".
There are XML-based diff tools, programming language syntax aware diff tools, and complex edit distance based diff tools already. It seems difficult to come up with something more generic. Let's say you want to diff programming language source files in languages for which there is no diff tools. What good is a context free diff tool going to be? You'd need to specify the entire grammar for the language.
I don't know if you didn't read this bit, or if I've misunderstood your post... But the basic (proposed?) approach of bgrep and bdiff is to provide a plug-in mechanism that would be used to extend the tools to new languages and data types. So, yes, you would have to specify the entire grammar for the language, but you'd only do it once... Or preferably, someone would have already done it for you.:)
Dude, the only part of your post that I find objectionable is this assumption that you're going to be crucified for posting your thoughts. I know that there are some people on Slashdot who are pretty predictably triggered to shout down certain opinions - just don't assume that everyone here is like that, OK?
I think there's a lot to like about Powershell, and part of me will always be a bit jealous that Windows got a shell with those kinds of capabilities before Linux did. It does indeed seem that what they describe bgrep and bdiff doing could be accomplished in Powershell. I've never been too clear on some of the particulars of how that would be done, though. As I understand it, you can search/filter either XML data streams, or a sequence of.NET objects. Would the way to accomplish this in.NET, then, be to have a commandlet that opens the source file and passes them through as.NET objects? It would be a bit less compact than having the special type handling right in the "find" or "filter" command but it does lend a certain clarity to things, too...
They should call it... perl. Isn't this exactly why perl was invented?
Perl could do this - with the right libraries. But that's the real value they're adding here. They created tools that operate on files with knowledge of the structure of those files. So for instance a "diff" between two XML files with identical contents but differences in formatting could report that the files are identical... Or if you had some file structure that defined a directed-graph structure, a format meant to be edited in-place (and which therefore might sometimes have holes in it where data was removed - or which might have data presented in a different order depending on the sequence of operations used to store it) - the "diff" tool would decode the files, examining the data structure they're meant to represent - and show the differences in that.
Obviously it could be done in Perl - but it wouldn't be a one-liner unless you had those libraries which translate the particular file format into the desired level of abstraction.
I got one; I've generally heard it called a "BC wheel" or an "Impossible Wheel". Could never get the hang of riding the thing - with a normal unicycle (or even its cousin the Ultimate Wheel) you can put pressure on the pedals to stop the unicycle whizzing off and leaving you to fall to the ground. With a BC wheel you just have to balance incredibly well - it's hard.
Heh, suddenly I'm tempted to try and learn it. Though I don't know where I'd practice these days... As a kid I never really spent a lot of time trying to develop those kinds of skills (apart from learning unicycle, I mean - I didn't learn to do much in the way of unicycle tricks, for instance). But when I see people practicing skateboard tricks and stuff - just hanging around, trying things, possibly hurting themselves and getting up to do it again - I can easily imagine those people riding a BC. I know I could do it, too, if I took the time to learn.
I like seeing unicycles mentioned on Slashdot because balance sports generally seem to be enjoyed by tech-minded people. I suspect it's because they can require an intense but non-intellectual concentration - and possibly because they are non-competitive, unconventional and still easy to enjoy even when there's nobody else to join in.
When I was a kid I was part of a performing group called the Gym Dandies. The program had been going on for several years before I joined and I think as a result unicycling was not quite as alien to people as it is where I live now... It was a little scary, actually, the first time I went out riding the new unicycle I got a much stronger reaction from people than I expected... It was like I was walking on water or something. I was like... what, can't everybody do this? I used to ride around all the damn time as a kid and I don't remember anybody really taking notice.:) I don't know if that's cause they don't have Gym Dandies here or if maybe sometimes people did freak out when I rode around as a kid and I just don't remember or didn't notice, or what... But for a while after that first ride I was almost afraid to take the thing out of the garage.:)
Blonde-psycho mode, hauling ass on a motor-unicycle, big bag of ill-gotten loot in one arm, bazooka in the other, getting chased by cops... Good times.
When looking at the pictures does anyone get the feeling of the BC Comic?
If you want the "BC" experience, there are unicycles that are very much like what appeared in the comic - that is, a wheel with an axle that you stand on. They actually do call them "BC" unicycles.
On the other hand - one could turn that process, of fighting a bunch of broken software, into something positive, in the form of improvements to the software in question, or just learning more about one's computer.
"Improvements to the software in question" is, for those in a position to make those improvements, the best response. If you have to fight your system to get it to do the right thing, and you do so by changing the system so that you, and others who follow you, don't have to fight it, that's a Good Thing.
As for "just learning more about one's computer", I don't want a system where I have to learn stuff about it just to get it to do stuff that it should be able to do without my help. I may want to learn about various configuration files and devices and drivers out of curiosity - on my own time and schedule.
Well, I totally get that... I tried to address that point - that while I enjoy some of this stuff for its own sake, others may not. And there's not even any reason they should, especially if such diversions keep them from the other things they're trying to accomplish.
My post should be taken very much anecdotally. I've spent a fair bit of time simply avoiding problems, I think. I even bought a Mac to avoid problems. (And that's a great choice for a lot of people - it was a horrible choice for me personally. That doesn't speak to some flaw in Mac, it's just really not the system for me, as it turns out. Its nature conflicts with my preferences. It's a bad combination.) But personally I found that reversal, of confronting the issues and finding ways to solve them rather than just letting them cause me irritation over a long period of time, very rewarding. Even if it kind of sucks that I have to deal with some of that stuff at all.:) Taking charge of those situations and decisively beating the obstacles defeats a lot of the frustration that comes with them.
Most people do not really lack intelligence. What most people lack is a motivation to make use of their intelligence; they would rather have other people do their thinking for them. Why spend time reading a manual and learning how to use your computer, when all you really wanted to do was go to Youtube and watch cool videos that other people created?
On the one hand, I understand and appreciate your message here: which is that some of the activities involved in "geek machismo" aren't actually worthy diversions. Isn't it better, after all, to make something cool rather than fight your OS to get it to the point where you can make something cool?
On the other hand - one could turn that process, of fighting a bunch of broken software, into something positive, in the form of improvements to the software in question, or just learning more about one's computer. Obviously that isn't always what people are going to want to do (if I set out to make a video, I want to get that video made at some point...) but it can be worthwhile.
I'm not fighting xorg.conf when I can help it - but I've been on a kick lately where I try not to allow myself any complacency when my computer doesn't work the way I want it to. I have to run Windows at work, so I found ways to make it more comfortable (mostly the right kind of cygwin setup, put a bunch of programs on the PATH, and set up a terminal window bound to a hotkey "Quake Console" style...). DBUS kept bitching at me during boot-up about deprecated SYSFS rules, so I learned how to fix those. (Really, though, DBUS itself could have made that a bit easier, I think...) If I'm working on a project and using some semi-broken tool in that work, I find out why it's semi-broken, try to fix it, and submit a patch. I was working with an assembler that was generating the wrong opcodes for certain instructions, so I found the problem and fixed it. I was working with kdenlive and getting really bad framerates out of the live feed from my DV camera - did a little digging and found the problem. I am trying to adopt a stance of not backing down from these kinds of issues - and that's been good times so far. It feels good to confront that kind of crap and beat it.:) I think it's a bit easy sometimes, as a tinkerer, to fall into a trap of just doing things that are easy - like getting an Arduino and loading it with code someone else wrote. That stuff can be fun but it kind of bypasses the real meat of the hobby.
At the same time I try to be realistic about what this all means outside of myself and people who share my interests - I am a computer hobbyist, interested to a certain degree in computers for their own sake. For someone who is just interested in the computer as a means to some end, my approach would be completely unreasonable, and some of these issues I have to deal with would similarly be unreasonable. It can be tempting to take anecdotes from one's own experience and try to apply them globally - but of course this doesn't always make sense.:)
That's kind of my point. The piano's complexity can't be reduced without cutting its functionality.
And my point is that the piano UI doesn't have any complexity. Understanding music, reading sheet music, and developing the muscle memory are the difficult parts and they aren't attributes of the UI.
So the problem isn't that the UI is hard to use, just that it's hard to use in any useful capacity.:) Isn't that pretty much the same thing? The piano UI doesn't have any apparent reducible complexity - that doesn't mean it's not complex.
I mean, think of this in comparison to Photoshop, or something like it. You could have several dozen effects filters in there. After a little tinkering around you'll probably understand that they all (or most) operate on the current selection, if any, and their function will have some relation to their name - but without knowing just what each one does, when it's to be used and how, that interface is going to be overwhelming. But those effects filters all exist for a reason, and probably most of them couldn't be removed without some meaningful loss of capability. The problem, as with the piano, isn't learning how to activate those things, but learning when to activate them, and which one to use in a given situation.
This is why I argue that an application with a rich toolset can't necessarily be held to the same standards of simplicity as a simple application - a common approach in developing a simple application is to identify rarely-used features and hide or eliminate them to simplify the UI. That process can still happen even if the UI has a rich toolset, but the end result is still going to be a UI that will overwhelm newcomers. But when people learn to deal with the complexity, an application like that can be very powerful. Thus, even though the more complicated, high-capability application is not going to be "idiot friendly", (that is, immediately accessible to someone who hasn't learned the program) it may still be a good UI.
Does that mean there's no place for careful, thoughtful UI design in such applications? Absolutely not. People learning need to be helped along, and the application has the potential to aid in that process. And some feature-related complexity may turn out to not really be useful, or a redesign may preserve the functionality while improving the interface. I believe that even the type of people I describe as "computer hobbyists" - even if they say they're fine with a shoddy UI - when they actually have to deal with some badly-designed tool that they haven't already learned they'll bitch about it. Because it sucks to get up to speed on a tool that doesn't help you.
But a well-designed UI doesn't imply a UI that limits your options. Like the piano. It's complicated to learn to use it, but that's because it gives you a lot of power. And, like the piano, such a UI can be easy to explore - push a key, see what it does, and suffer no ill-consequences that you may not know how to undo.
I'm sorry, but still no. The piano is perfectly accessible to those that are new to it. They will quickly know what every button does. The fact that they are not musicians and haven't developed muscle memory to operate it in a way that's pleasant to listen to is not a problem with UI design.
That's kind of my point. The piano's complexity can't be reduced without cutting its functionality. It is a somewhat complex skill that takes time to learn and changing the interface can't address that. Attempting to simplify it would reduce what you could do with the instrument. The complicated part of the piano's UI is knowing how to play it, and that's not something you can change.
How would you simplify the UI of a piano, for instance, so that new users could play their favorite songs without all that pesky practice?
A piano is idiot ready. It has buttons that are organised to output a series of pleasant notes from low to high. And the buttons are velocity sensitive. That's all quickly discoverable even by a toddler. The 2 or three pedals are slightly less obvious, admittedly. The only complexity is the problem space - you have to be a piano player. The complexity is not learning how the piano works, it's learning how to make your fingers move appropriately.
It's the same thing, really. If you can't play the piano, then in a practical sense you can't use the piano. You derive little benefit from it in that case. My point is that if the problem space is complex, there's only so far you can go in terms of making the interface accessible to people who are new to it.
Or, what about files made by specialized programs that not many people use? Why should OS makers have to deal with metadata standards for every filetype in existence? The way it is now, only people who write apps dealing with a particular filetype have to deal with metadata standards.
That is not the way it is now. Desktop indexing (present in Windows, OS X, and at least optionally in Linux) monitors the filesystem, re-scanning the in-file metadata when a file is modified, so it can build a central database for quick searches. So the indexing system needs to know how to read these different file types.
Very dishonest argument.
Desktop search engines have it very easy. Just consider the possibility - they can simply run/usr/bin/strings on the general area of the file where metadata is likely to be found and index the resulting data.
Great, so the table's gonna have a lot of entries for "JFIF".:) And a lot of good "strings" is gonna do on compressed source data...
But in fact, this isn't what current desktop search engines do: they recognize known file type and process them specifically, so they know which ID3 field is the artist and which is the title, etc.
True, that's why I said users could force it on programs they don't trust. Although, being mandatory for everything would eliminate all badly written programs quickly.
Well, this is kind of what happened on Windows. The existence of the rules (and on by default, I believe) motivated people to clean up their code pretty fast... But it's still a nuisance and so it's fairly common for people to turn it off.:)
Yeah, it's the same thing as when Debian blocked the ability for a user to install anything via other channels than apt-get. Or so I heard. Maybe it was one of its other communist brethren. I haven't used it myself, of course, I'm just posting about things that aren't entirely impossible.
You make a good point - which is that it's all too easy for idle prognostication to turn into FUD. This is why I put that last paragraph in there. I was trying to say that it's unfair to pin this on Apple when they haven't done it. Even saying they haven't done it "yet" is unfair, because it suggests that they will.
However, I personally believe they will. I don't know when, I don't know that they'll be the first, but I believe it will happen. As I said, there is no basis for assuming the status-quo of computing, established decades ago, will hold. Things change, and there are people who have motivation to change them... And the current direction of smart phones and tablets is a clear step in that direction.
Also: 1: I have used OS X, and had quite enough of it, so fuck you. 2: Apple has released a closed platform already (iPhone and its relatives), Debian has not. So, again, fuck you and your broken analogy.
That sort of terminology ("idiot-ready") is why geeks are still despised and laughed at by everyone else in the world.
To be fair, it seems to me that non-geeks are willing and ready to adopt the mantle of "idiot" themselves in a self-deprecating way when it's comfortable to do so. For instance, people buy "idiots' guides" and books "for dummies". These books don't actually treat their audience like fools, but I was never entirely comfortable with the idea of people resigning themselves (even if just symbolically) to idiocy. If you do that, isn't it kind of like giving up before you've even tried?
Whatever, it sells books.:)
Personally, I took a similar direction when I started college, trying to get away from what I had been in high school - but over time came to the conclusion that I actually like those "geek" aspects of myself, and that anyone who couldn't appreciate that wasn't worth my time.
"idiot-ready" software is good software... for "idiots".
No, it's not. That's a myth started to defend the quality of OSS software and perpetuated by people who think they're above the masses because they know how to turn on encryption on their WiFi router.
"Idiot Ready" actually means 'thoughtfully designed'.
I want to emphasize that I do not actually think these people are idiots. I was just extending the metaphor that was already in play. So I will rephrase what I said to better reflect my intent: What is sometimes called "idiot-ready" software is good software for a large number of people. The majority, I would say. If those are the users you're targeting, then yes, that is a good design. I just believe it's a fallacy to assume it's right for everyone. "Good" design is subject to the question of who your audience is. And so I take exception to a blanket-labeling of simple UI as good UI without caveats about who and what the UI is intended for.
When you have an application whose entire purpose is to present a large toolbox of functionality - there is no way to make that simple. To use the application effectively, a user has to learn what tools are available and how to use them. Those tools need to be accessible - which means there's a limit to how far you can simplify the UI. How would you simplify the UI of a piano, for instance, so that new users could play their favorite songs without all that pesky practice?
That does not mean there is no place for thoughtful UI design - but a thoughtfully designed, high capability application will not be "idiot"-ready (I really must stop using that word... I'll have to think of a better way to convey that idea.) - people can not instantly dive in and use Photoshop or 3DS Max effectively just because the UI of those apps has been the subject of extensive, professional development. They could maybe get up to speed on the basics but learning the full set of functionality is bound to take time.
You have assumed I am defending OSS software design - I enjoy using Free Software and use it almost exclusively on my own systems, but your assumption is baseless and incorrect. Whether I like a particular application (Emacs, for instance) is separate from whether I think it's a good UI design. (Actually I think Emacs has some strengths in that regard - perhaps the main one being the ability to search for and invoke commands by name. But the rest, the keyboard shortcuts and all that - it's basically arcane. Useful once you've learned it but apart from the menubars there's not much hand-holding to get people up to speed.) I believe Free Software could benefit from improvements to its UI design, but UI design methodology is dominated by the idea that good UI design is an uncluttered window that presents all the relevant functionality of the application - and that functionality that can't fit in without cluttering the window is discarded. That isn't the direction that I, personally, want Linux, etc. to go. I want it to be a good system for me, and maybe others like me who have a deeper interest in computers (for their own sake, I mean) than most of the population. Let the other OSes target the majority of users out there, I'd rather see Linux be a good system for computing hobbyists.
Some traditional principles of UI design still hold in that case - I think computing hobbyists may not be quick to admit it but I think we all love a UI that helps us when we need it. I just think we also want it to stay out of our way the rest of the time.:)
This would be an important security feature if users could force it for any program.
The problem there is that if the program wasn't written to be well-behaved, it may trip various security rules by fairly harmless processes of its normal operation.
For instance, if a Windows program were to store a bunch of data in its directory in Program Files - on older versions of Windows this would be fine (because users commonly had administrator-level privilege and thus also write access to the application's directory in Program Files) - but in a more secure setup on a more recent version, this would be a problem. If the application isn't written properly to avoid tripping over those security rules, it either won't work, or the user will get pestered with lots of security messages...
Slashdot Mirror
>Using quoting syntax to provide commentary on what someone said instead of what they actually said
I guess that helps complete the illusion that you're on 4chan. :)
Many bans on cellphones allow hands-free, but I've always felt it wasn't because it is better to use hands-free, but because it is impossible to enforce. (If someone can back up or refute my assumption, mod him up).
Either that, or someone argued that hands-free devices made cell calls in the car safer, so they could sell more hands-free calling devices. :)
The use cases, options, and interfaces are different for searching programming language source files, XML files, and other text. ... Trying to force them into a single command line tool makes little sense to me.
You make a good point, but I think a tool that forces the different data types into a single mould could still be useful, even if it can't provide all the functionality that a specialized tool would.
Right, but what is there not already a parser for in CPAN? And if you are handy with perl, what kind of comparison is difficult?
I couldn't say, honestly. :) So write a Perl script that recognizes the input file types, chooses the correct module, implements some kind of matching rule syntax, and performs the comparison with whatever module you chose in step 2, and a plugin system so people can add more file types without modifying your script, and yes, you've pretty much got bgrep.
I think at that point you're beyond "Perl's capabilities" and into the realm of "capabilities of things you can implement in Perl".
This violates so many rules of the Unix philosophy that I don't even know where to begin...
I'll take this on. It's a subject that is of particular interest to me.
First of all, you have to consider whether it even matters that a tool violates "rules" of the "Unix philosophy". I mean, seriously, why assume that some system design ideas cooked up 30-40 years ago are necessarily the One True Path? Because "those who do not understand Unix are doomed to reinvent it poorly"? What if the designers in question do understand Unix? Or what if <gasp> they might actually have some ideas that surpass those of Doug Mcllroy, ESR, K & R, and so on?
Second, how does one account for tools like Perl? By many accounts it is one of the greatest Unix tools ever created. By combining the functionality and syntax of several useful tools, incorporating a rich regexp syntax, and binding it together with a general-purpose programming language, it can be a very versatile and effective tool. But it runs afoul of various "rules" as well: (I will use a star to mark the rules I don't particularly agree with)
Perl's biggest "violation", which it shares with other scripting languages, is that first one: "do one thing and do it well." Perl, Python, etc. are perfectly capable of doing a fork/exec or popen or loading a .so or whatever - but generally if there's a piece of functionality that people want to have in those languages, they re-implement it as a native library for those languages. Why do we accept so blatant a violation of what may be rightly considered the Unix philosophy? Because it works. It's useful. So a better question, then, is why is it that violating such an important "rule" is apparently necessary to create such a useful tool? There are various reasons: First, any reliance on an outside program is a maintenance issue. If your script is written for GNU find, for instance, and you move it to a system that has some other implementation of find, it may not work. Things can change from revision to revision as well. Second, it actually makes it easier to access the functionality, since you don't have to deal with writing out a stream of values and/or reading back a stream of results - when you call a Perl module, everything is neatly packaged into a (usually) synchronous call/result function interface, and presented as native Perl data.
Perl could be a contentious example - but I chose it because to me, it and other scripting languages are examples of people bypassing the shell environment, rather than augmenting it. I would go so far a
Why do we need to write another perl?
Is it really "writing another perl"? The meat of these tools (which, I think, aren't yet implemented?) is that they filter and compare parsed data structures - and provide plug-in hooks so people can insert parsers for additional data types. Certainly this could be done as a Perl library - and doing so might have some advantages over creating new tools with their own plug-in mechanism. But implementing bgrep and bdiff is nowhere close to "writing another perl".
There are XML-based diff tools, programming language syntax aware diff tools, and complex edit distance based diff tools already. It seems difficult to come up with something more generic. Let's say you want to diff programming language source files in languages for which there is no diff tools. What good is a context free diff tool going to be? You'd need to specify the entire grammar for the language.
I don't know if you didn't read this bit, or if I've misunderstood your post... But the basic (proposed?) approach of bgrep and bdiff is to provide a plug-in mechanism that would be used to extend the tools to new languages and data types. So, yes, you would have to specify the entire grammar for the language, but you'd only do it once... Or preferably, someone would have already done it for you. :)
So what? Maybe people want a non-proprietary solution that works on more than one OS.
If there are such people, and it's not just me, I'd love to oblige them. :) I really need to get crackin'...
I know I'll be modded down
Dude, the only part of your post that I find objectionable is this assumption that you're going to be crucified for posting your thoughts. I know that there are some people on Slashdot who are pretty predictably triggered to shout down certain opinions - just don't assume that everyone here is like that, OK?
I think there's a lot to like about Powershell, and part of me will always be a bit jealous that Windows got a shell with those kinds of capabilities before Linux did. It does indeed seem that what they describe bgrep and bdiff doing could be accomplished in Powershell. I've never been too clear on some of the particulars of how that would be done, though. As I understand it, you can search/filter either XML data streams, or a sequence of .NET objects. Would the way to accomplish this in .NET, then, be to have a commandlet that opens the source file and passes them through as .NET objects? It would be a bit less compact than having the special type handling right in the "find" or "filter" command but it does lend a certain clarity to things, too...
They should call it... perl. Isn't this exactly why perl was invented?
Perl could do this - with the right libraries. But that's the real value they're adding here. They created tools that operate on files with knowledge of the structure of those files. So for instance a "diff" between two XML files with identical contents but differences in formatting could report that the files are identical... Or if you had some file structure that defined a directed-graph structure, a format meant to be edited in-place (and which therefore might sometimes have holes in it where data was removed - or which might have data presented in a different order depending on the sequence of operations used to store it) - the "diff" tool would decode the files, examining the data structure they're meant to represent - and show the differences in that.
Obviously it could be done in Perl - but it wouldn't be a one-liner unless you had those libraries which translate the particular file format into the desired level of abstraction.
I got one; I've generally heard it called a "BC wheel" or an "Impossible Wheel". Could never get the hang of riding the thing - with a normal unicycle (or even its cousin the Ultimate Wheel) you can put pressure on the pedals to stop the unicycle whizzing off and leaving you to fall to the ground. With a BC wheel you just have to balance incredibly well - it's hard.
Heh, suddenly I'm tempted to try and learn it. Though I don't know where I'd practice these days... As a kid I never really spent a lot of time trying to develop those kinds of skills (apart from learning unicycle, I mean - I didn't learn to do much in the way of unicycle tricks, for instance). But when I see people practicing skateboard tricks and stuff - just hanging around, trying things, possibly hurting themselves and getting up to do it again - I can easily imagine those people riding a BC. I know I could do it, too, if I took the time to learn.
I like seeing unicycles mentioned on Slashdot because balance sports generally seem to be enjoyed by tech-minded people. I suspect it's because they can require an intense but non-intellectual concentration - and possibly because they are non-competitive, unconventional and still easy to enjoy even when there's nobody else to join in.
When I was a kid I was part of a performing group called the Gym Dandies. The program had been going on for several years before I joined and I think as a result unicycling was not quite as alien to people as it is where I live now... It was a little scary, actually, the first time I went out riding the new unicycle I got a much stronger reaction from people than I expected... It was like I was walking on water or something. I was like... what, can't everybody do this? I used to ride around all the damn time as a kid and I don't remember anybody really taking notice. :) I don't know if that's cause they don't have Gym Dandies here or if maybe sometimes people did freak out when I rode around as a kid and I just don't remember or didn't notice, or what... But for a while after that first ride I was almost afraid to take the thing out of the garage. :)
First thing this makes me think of is that scene with Lunch early in Dragonball Z...
http://www.youtube.com/watch?v=UT4H5qaWt0g
Blonde-psycho mode, hauling ass on a motor-unicycle, big bag of ill-gotten loot in one arm, bazooka in the other, getting chased by cops... Good times.
When looking at the pictures does anyone get the feeling of the BC Comic?
If you want the "BC" experience, there are unicycles that are very much like what appeared in the comic - that is, a wheel with an axle that you stand on. They actually do call them "BC" unicycles.
Those things scare me a little. :)
On the other hand - one could turn that process, of fighting a bunch of broken software, into something positive, in the form of improvements to the software in question, or just learning more about one's computer.
"Improvements to the software in question" is, for those in a position to make those improvements, the best response. If you have to fight your system to get it to do the right thing, and you do so by changing the system so that you, and others who follow you, don't have to fight it, that's a Good Thing.
As for "just learning more about one's computer", I don't want a system where I have to learn stuff about it just to get it to do stuff that it should be able to do without my help. I may want to learn about various configuration files and devices and drivers out of curiosity - on my own time and schedule.
Well, I totally get that... I tried to address that point - that while I enjoy some of this stuff for its own sake, others may not. And there's not even any reason they should, especially if such diversions keep them from the other things they're trying to accomplish.
My post should be taken very much anecdotally. I've spent a fair bit of time simply avoiding problems, I think. I even bought a Mac to avoid problems. (And that's a great choice for a lot of people - it was a horrible choice for me personally. That doesn't speak to some flaw in Mac, it's just really not the system for me, as it turns out. Its nature conflicts with my preferences. It's a bad combination.) But personally I found that reversal, of confronting the issues and finding ways to solve them rather than just letting them cause me irritation over a long period of time, very rewarding. Even if it kind of sucks that I have to deal with some of that stuff at all. :) Taking charge of those situations and decisively beating the obstacles defeats a lot of the frustration that comes with them.
On reading about this thing, I can't help but imagine a squirrel yelling "BERSERKER CLAW!" as it tears some hapless creature apart.
Most people do not really lack intelligence. What most people lack is a motivation to make use of their intelligence; they would rather have other people do their thinking for them. Why spend time reading a manual and learning how to use your computer, when all you really wanted to do was go to Youtube and watch cool videos that other people created?
Many people lack a motivation to use their intelligence in the ways that some people might think they should. For example, I have no motivation at all to, for example, devote any of my intelligence whatsoever to looking at or editing an xorg.conf file - I'd rather devote it to something useful, such as developing software
On the one hand, I understand and appreciate your message here: which is that some of the activities involved in "geek machismo" aren't actually worthy diversions. Isn't it better, after all, to make something cool rather than fight your OS to get it to the point where you can make something cool?
On the other hand - one could turn that process, of fighting a bunch of broken software, into something positive, in the form of improvements to the software in question, or just learning more about one's computer. Obviously that isn't always what people are going to want to do (if I set out to make a video, I want to get that video made at some point...) but it can be worthwhile.
I'm not fighting xorg.conf when I can help it - but I've been on a kick lately where I try not to allow myself any complacency when my computer doesn't work the way I want it to. I have to run Windows at work, so I found ways to make it more comfortable (mostly the right kind of cygwin setup, put a bunch of programs on the PATH, and set up a terminal window bound to a hotkey "Quake Console" style...). DBUS kept bitching at me during boot-up about deprecated SYSFS rules, so I learned how to fix those. (Really, though, DBUS itself could have made that a bit easier, I think...) If I'm working on a project and using some semi-broken tool in that work, I find out why it's semi-broken, try to fix it, and submit a patch. I was working with an assembler that was generating the wrong opcodes for certain instructions, so I found the problem and fixed it. I was working with kdenlive and getting really bad framerates out of the live feed from my DV camera - did a little digging and found the problem. I am trying to adopt a stance of not backing down from these kinds of issues - and that's been good times so far. It feels good to confront that kind of crap and beat it. :) I think it's a bit easy sometimes, as a tinkerer, to fall into a trap of just doing things that are easy - like getting an Arduino and loading it with code someone else wrote. That stuff can be fun but it kind of bypasses the real meat of the hobby.
At the same time I try to be realistic about what this all means outside of myself and people who share my interests - I am a computer hobbyist, interested to a certain degree in computers for their own sake. For someone who is just interested in the computer as a means to some end, my approach would be completely unreasonable, and some of these issues I have to deal with would similarly be unreasonable. It can be tempting to take anecdotes from one's own experience and try to apply them globally - but of course this doesn't always make sense. :)
That's kind of my point. The piano's complexity can't be reduced without cutting its functionality.
And my point is that the piano UI doesn't have any complexity. Understanding music, reading sheet music, and developing the muscle memory are the difficult parts and they aren't attributes of the UI.
So the problem isn't that the UI is hard to use, just that it's hard to use in any useful capacity. :) Isn't that pretty much the same thing? The piano UI doesn't have any apparent reducible complexity - that doesn't mean it's not complex.
I mean, think of this in comparison to Photoshop, or something like it. You could have several dozen effects filters in there. After a little tinkering around you'll probably understand that they all (or most) operate on the current selection, if any, and their function will have some relation to their name - but without knowing just what each one does, when it's to be used and how, that interface is going to be overwhelming. But those effects filters all exist for a reason, and probably most of them couldn't be removed without some meaningful loss of capability. The problem, as with the piano, isn't learning how to activate those things, but learning when to activate them, and which one to use in a given situation.
This is why I argue that an application with a rich toolset can't necessarily be held to the same standards of simplicity as a simple application - a common approach in developing a simple application is to identify rarely-used features and hide or eliminate them to simplify the UI. That process can still happen even if the UI has a rich toolset, but the end result is still going to be a UI that will overwhelm newcomers. But when people learn to deal with the complexity, an application like that can be very powerful. Thus, even though the more complicated, high-capability application is not going to be "idiot friendly", (that is, immediately accessible to someone who hasn't learned the program) it may still be a good UI.
Does that mean there's no place for careful, thoughtful UI design in such applications? Absolutely not. People learning need to be helped along, and the application has the potential to aid in that process. And some feature-related complexity may turn out to not really be useful, or a redesign may preserve the functionality while improving the interface. I believe that even the type of people I describe as "computer hobbyists" - even if they say they're fine with a shoddy UI - when they actually have to deal with some badly-designed tool that they haven't already learned they'll bitch about it. Because it sucks to get up to speed on a tool that doesn't help you.
But a well-designed UI doesn't imply a UI that limits your options. Like the piano. It's complicated to learn to use it, but that's because it gives you a lot of power. And, like the piano, such a UI can be easy to explore - push a key, see what it does, and suffer no ill-consequences that you may not know how to undo.
I'm sorry, but still no. The piano is perfectly accessible to those that are new to it. They will quickly know what every button does. The fact that they are not musicians and haven't developed muscle memory to operate it in a way that's pleasant to listen to is not a problem with UI design.
That's kind of my point. The piano's complexity can't be reduced without cutting its functionality. It is a somewhat complex skill that takes time to learn and changing the interface can't address that. Attempting to simplify it would reduce what you could do with the instrument. The complicated part of the piano's UI is knowing how to play it, and that's not something you can change.
How would you simplify the UI of a piano, for instance, so that new users could play their favorite songs without all that pesky practice?
A piano is idiot ready. It has buttons that are organised to output a series of pleasant notes from low to high. And the buttons are velocity sensitive. That's all quickly discoverable even by a toddler. The 2 or three pedals are slightly less obvious, admittedly. The only complexity is the problem space - you have to be a piano player. The complexity is not learning how the piano works, it's learning how to make your fingers move appropriately.
It's the same thing, really. If you can't play the piano, then in a practical sense you can't use the piano. You derive little benefit from it in that case. My point is that if the problem space is complex, there's only so far you can go in terms of making the interface accessible to people who are new to it.
Or, what about files made by specialized programs that not many people use? Why should OS makers have to deal with metadata standards for every filetype in existence? The way it is now, only people who write apps dealing with a particular filetype have to deal with metadata standards.
That is not the way it is now. Desktop indexing (present in Windows, OS X, and at least optionally in Linux) monitors the filesystem, re-scanning the in-file metadata when a file is modified, so it can build a central database for quick searches. So the indexing system needs to know how to read these different file types.
Very dishonest argument.
Desktop search engines have it very easy. Just consider the possibility - they can simply run /usr/bin/strings on the general area of the file where metadata is likely to be found and index the resulting data.
Great, so the table's gonna have a lot of entries for "JFIF". :) And a lot of good "strings" is gonna do on compressed source data...
But in fact, this isn't what current desktop search engines do: they recognize known file type and process them specifically, so they know which ID3 field is the artist and which is the title, etc.
True, that's why I said users could force it on programs they don't trust. Although, being mandatory for everything would eliminate all badly written programs quickly.
Well, this is kind of what happened on Windows. The existence of the rules (and on by default, I believe) motivated people to clean up their code pretty fast... But it's still a nuisance and so it's fairly common for people to turn it off. :)
Yeah, it's the same thing as when Debian blocked the ability for a user to install anything via other channels than apt-get. Or so I heard. Maybe it was one of its other communist brethren. I haven't used it myself, of course, I'm just posting about things that aren't entirely impossible.
You make a good point - which is that it's all too easy for idle prognostication to turn into FUD. This is why I put that last paragraph in there. I was trying to say that it's unfair to pin this on Apple when they haven't done it. Even saying they haven't done it "yet" is unfair, because it suggests that they will.
However, I personally believe they will. I don't know when, I don't know that they'll be the first, but I believe it will happen. As I said, there is no basis for assuming the status-quo of computing, established decades ago, will hold. Things change, and there are people who have motivation to change them... And the current direction of smart phones and tablets is a clear step in that direction.
Also:
1: I have used OS X, and had quite enough of it, so fuck you.
2: Apple has released a closed platform already (iPhone and its relatives), Debian has not. So, again, fuck you and your broken analogy.
That sort of terminology ("idiot-ready") is why geeks are still despised and laughed at by everyone else in the world.
To be fair, it seems to me that non-geeks are willing and ready to adopt the mantle of "idiot" themselves in a self-deprecating way when it's comfortable to do so. For instance, people buy "idiots' guides" and books "for dummies". These books don't actually treat their audience like fools, but I was never entirely comfortable with the idea of people resigning themselves (even if just symbolically) to idiocy. If you do that, isn't it kind of like giving up before you've even tried?
Whatever, it sells books. :)
Personally, I took a similar direction when I started college, trying to get away from what I had been in high school - but over time came to the conclusion that I actually like those "geek" aspects of myself, and that anyone who couldn't appreciate that wasn't worth my time.
"idiot-ready" software is good software... for "idiots".
No, it's not. That's a myth started to defend the quality of OSS software and perpetuated by people who think they're above the masses because they know how to turn on encryption on their WiFi router.
"Idiot Ready" actually means 'thoughtfully designed'.
I want to emphasize that I do not actually think these people are idiots. I was just extending the metaphor that was already in play. So I will rephrase what I said to better reflect my intent:
What is sometimes called "idiot-ready" software is good software for a large number of people. The majority, I would say. If those are the users you're targeting, then yes, that is a good design. I just believe it's a fallacy to assume it's right for everyone. "Good" design is subject to the question of who your audience is. And so I take exception to a blanket-labeling of simple UI as good UI without caveats about who and what the UI is intended for.
When you have an application whose entire purpose is to present a large toolbox of functionality - there is no way to make that simple. To use the application effectively, a user has to learn what tools are available and how to use them. Those tools need to be accessible - which means there's a limit to how far you can simplify the UI. How would you simplify the UI of a piano, for instance, so that new users could play their favorite songs without all that pesky practice?
That does not mean there is no place for thoughtful UI design - but a thoughtfully designed, high capability application will not be "idiot"-ready (I really must stop using that word... I'll have to think of a better way to convey that idea.) - people can not instantly dive in and use Photoshop or 3DS Max effectively just because the UI of those apps has been the subject of extensive, professional development. They could maybe get up to speed on the basics but learning the full set of functionality is bound to take time.
You have assumed I am defending OSS software design - I enjoy using Free Software and use it almost exclusively on my own systems, but your assumption is baseless and incorrect. Whether I like a particular application (Emacs, for instance) is separate from whether I think it's a good UI design. (Actually I think Emacs has some strengths in that regard - perhaps the main one being the ability to search for and invoke commands by name. But the rest, the keyboard shortcuts and all that - it's basically arcane. Useful once you've learned it but apart from the menubars there's not much hand-holding to get people up to speed.) I believe Free Software could benefit from improvements to its UI design, but UI design methodology is dominated by the idea that good UI design is an uncluttered window that presents all the relevant functionality of the application - and that functionality that can't fit in without cluttering the window is discarded. That isn't the direction that I, personally, want Linux, etc. to go. I want it to be a good system for me, and maybe others like me who have a deeper interest in computers (for their own sake, I mean) than most of the population. Let the other OSes target the majority of users out there, I'd rather see Linux be a good system for computing hobbyists.
Some traditional principles of UI design still hold in that case - I think computing hobbyists may not be quick to admit it but I think we all love a UI that helps us when we need it. I just think we also want it to stay out of our way the rest of the time. :)
This would be an important security feature if users could force it for any program.
The problem there is that if the program wasn't written to be well-behaved, it may trip various security rules by fairly harmless processes of its normal operation.
For instance, if a Windows program were to store a bunch of data in its directory in Program Files - on older versions of Windows this would be fine (because users commonly had administrator-level privilege and thus also write access to the application's directory in Program Files) - but in a more secure setup on a more recent version, this would be a problem. If the application isn't written properly to avoid tripping over those security rules, it either won't work, or the user will get pestered with lots of security messages...