That's just plain BS. I can write a C compiler in AWK, using an AWK that runs on LISP in a LISP machine and generates JAVA bytecode. That does not mean it is no longer a C compiler but just a frontend to the JAVA virtual machine. Just because some Haskell compiler is written in C (and might I add most modern native compilers are self-compiling as a matter of pride), doesn't mean you just have a 'high level language frontend for the underlying C code'.
The real problem is how coupled compilers and languages are in most peoples minds. Languages aren't fast, compilers are efficient. Anything you say about C can be said about any other Turing complete language. They are all equivalent in computing power. However, compilers may be very good at converting the language to efficient machine instructions. This is due to language semantics and some accidental effects like the number of man-hours that have gone into tuning said compilers. In every case, the efficiency of a compiler is not an absolute that can be calculated but a qualitative measure of how well it does.
So, language efficiency is really not a sensible phrase. We could be worrying about matching compiler abilities with language semantics, but even then, machine architectures vary, leading to changes on the language level to cater for achitectural differences (would C still do well on a Lisp machine or a PostScript printer or a GPU?). In the end, making choices based on specific machine capabilities will lead to short term gains, but as compiler tech gets better and the number of platforms increases more abstraction will make it easier to get 'ok' performance on 'most' platforms.
The entire field of Linear Systems (start at http://en.wikipedia.org/wiki/System_analysis and click out from there) is greatly simplified by converting systems of linear differential equations to Laplace domain ( http://en.wikipedia.org/wiki/Laplace_transform ) and getting a frequency response by substituting s = iw where i = sqrt(-1) and w is a frequency. Due to the Euler identity ( http://en.wikipedia.org/wiki/Euler's_identity ), we can then transform this all back to time. The simplification is that we manipulate differential equations as algebraic equations in Laplace space.
I do this stuff all day and I can not imagine a world where sqrt(-1) is just undefined. Of course, the Laplace domain is not really restricted to linear systems, but it makes things easier when they are.
Now, this could all seem like "mathematical dickwaving" to you if you have not used it before, but it seems pretty damn useful to me that I can now determine optimal controller settings mathematically instead of having to guess values and have my plant blow up in the process. So there you have my little piece of the usefulness of imaginary numbers. (pure) Mathematics are not really involved in solving practical problems, but engineers can use all this rigorous theory to solve real problems. It is possible to prove that we don't need more than simple operators and a few digits to solve all problems -- having powerful mathematical tools just makes the journey shorter and more enjoyable.
OO.org's formula editing is very similar to WordPerfect's old style formulas. They are both based on the EQ syntax used by TROFF and GROFF, but not anything like XML.
Yes, good for them. These people are more interested in getting on with whatever their job actually is, then in 'exploring' their computers to find out where everything is. Stop trying to make everyone think like you, and instead focus your skills on making it easier for people to do what they do want to do.
I say: How about I do my thing and they do theirs and if they can't get their thing done it is not my job to do it for them? Why is it that it is always the technologically literate people who have to "focus your skills on making it easier for people to do what they do want to do". I am also a person and I also want to do what I want to do. Who's looking out for me?
In many cases they learn to program for their own projects, where speed/ease of coding may be more important than security. If you just pick up an old C book, no-one warns you to stay away from gets(), so people learn to use it, and it works. Then they get told to use something else that is more secure but it is slow or more difficult to learn, so they don't.
In my building there is a whole floor of guys doing simulations in Fortran 77. When I tell them about new functions in F90 or about ways they could solve their problem in C++ they have only one question: "isn't that going to be slow?".
So ultimately the problem is that most "bad" code comes from people who have hacked together a useful tool by leveraging their experience in fields where security or stability doesn't really matter. They have probably been coding successfully for some time without ever seeing anything wrong with their approach until they used it out of context.
You totally misunderstand Stallman's ideology. This is the exact reason he has tried to distance the Free Software movement from the Open Source movement. The OS philosophy is pragmatic. They say OS is a good business choice and in some cases can be a better way for everone to profit from software.
The FS people are not pragmatists. This is the first thing you probably don't understand (you seem like a hardcore pragmatist yourself). The movement is about the idea that software (and other forms of abstract information) should not be bound by the same rules as physical objects. They are different and should be treated differently. To some extend Stallman is a Utopian. The difference is that he has taken real steps to move in the direction he wants the world to move in. And it has paid off greatly. The GNU tools are ubiquitous in Unix-like environments.
As other posters have said: do your thing your way, but understand that this man has principles (not just wrong-headedness) and has put in an amazing amount of effort to stick by them. You may mock principles for being inefficient, but some of us respect them.
I get that one can add protective measures that are not 'in the way' and that a tool that encourages or invites accidents or misuse could be redesigned to make it inherently safe. I am an engineer, so I am aware of the idea of designing in safety. As I said, you make a few good points.
I think the problem with your original post is that it muddies the water with statements like 'long manuals are the hallmark of bad design' in the context of computer use. Especially because many of the readers here regularly use language-based tools that are literally impossible to master without a manual, simply because language is not self-documenting, and does not necessarily have to be. I think what you may be missing is that people like the GNU project have put in significant effort to make their tools 'intuitive' to the user, by using similar flags and by presenting a unified abstract view of the machine through files. Perhaps you where trying to say that the 'original' unix attitude encouraged bad design, but that it is changing. Instead it came off as bashing non-graphical/non-self-documenting systems as overly dangerous and complex.
I think usability and power are not totally orthogonal, but there is a nonzero angle between them. We can all agree that some usability improvements cost nothing in power, but we will not agree that a complicated system relying on use of language to supply power can be used optimally without reading the instructions.
PS: I think I agree with almost everything you are saying, so don't think I am being argumentative.
You make a few good points, but seem to have a misplaced faith in designing out problems. Let's take a look at the 'real world', which has been around a lot longer than the computer world, and see whether good design has triumphed to make the world around us work without danger and reliance on human memory or judgement.
Let's look at powertools, cars, airplanes, guns, knives or other things that modern people use. All of them have measures designed to stop people from hurting themselves and require no training to use, as their use is obvious, right? Wrong. If I design a knife that is too blunt to cut flesh, it cannot cut my steak. If I design a car that does not move fast enough to kill me if I am in an accident, the car doesn't move fast enough period. Notice how this is ok, and how we can give kids blunt plastic knives until they have learned how to use them well enough to use 'big tools'.
This pattern is even more pronounced with 'professional tools' like planers, jigs or powerful hydroulics. You need trained operators for those, because they can take of your arm or kill many people at once. The true myth of our time is that computers should be both easy to use and powerful enough to do anything you want. Design can bring you so far, but each level of ease of use you slap onto a device usually makes it that much less powerful. Observe F1 racing cars -- not an 'easy drive', but really good at what they do. Safety measures and 'easy to start' engines are too heavy, so they don't make the cut.
Getting back to the computer, there is no way to stop you from making mistakes. There are a few common mistakes, but there is no reliable way of knowing whether the user really wanted to delete all the files in that directory. I know people who have 'accidentally' deleted files in Windows, clicked on 'yes, I am sure', emptied the recycle bin and then realised they made a mistake. How was the operating system to know to stop the user? Professionals hate people looking over there shoulders, double-guessing their actions. They don't like little dogs asking them to type a file query. They like the power of a stripped down interface that allows them the freedom to do what they want they way they want. If all your needs are filled by GUI tools, there is no reason not to use them, but I prefer to get stuff done my way.
So, in the end, things get down to formalisms and language. And that's the thing about language -- it has rules. You have to learn the rules. You have to use the language often to remain fluent. What you get in return is tha ability to express yourself accurately. And thank goodness that we have a powerful language interface to the OS in things like bash.
Humans are well-equipped to accept visual input. We have good pattern recognition and high bandwidth for visual processing. So it is no surprise that people are happy in a graphical environment that shows them much of what they want to know using rich graphics. What is surprising is the eagerness with which they discard language as a medium for outputting information.
Most people are bad at expressing themselves exactly using pictures or gestures. It is only using formalised systems like language (or sign language) that we gain the abstraction necessary to express ourselves about things we cannot see or that have not happened yet. Common problems can be solved using nice interfaces that allow you to do only 'the right thing'. Once you reach Turing completeness, however, it is provably impossible to stop someone from screwing up in ways that are undetectable by the system.
This is the core of the problem. Most people want to give vague directions to an expert and have him use judgement to deliver an acceptable solution to the problem. These people are not heavy computer users or see the computer as a means to an end . They are probably best served by custom apps that do the things they want to do very well with low risk of error. Other people need computers on a daily basis to complete complex tasks that are unique to their situations. Analysts, accountants, engineers all need computers to do exactly the thing they need done in exactly the way they want. For these people, a system of choosing the 'correct' options soon turns into an extreme challenge in itself. Excel is Turing complete, but it is damn near impossible to imagine elegant ways of handling some of the problems I have solved with a few lines of Python or Matlab code.
What I am trying to say is that this idea of people being reluctant to program is only valid because we have actively discouraged the use of precise language to describe problems. We have encouraged people who lack the means to express themselves by saying that they should be allowed to use a more 'forgiving' interface. There will always be a trade-off between power and ease of use. Somehow, we have come to believe that it is ok to spend 15-20 years mastering a native language, but mastering an environment that allows you to communicate with a computer should take no less than a few days. What kind of expressive power can we expect then?
I would like to point out that the article is not about plain phase changes, but rather about phase changes near the critical point, where liquid and gas phases become indistinguishable. Predicting ideal phase change behaviour has been done, but the critical point poses some unique challenges.
perl is a programming language, surely nobody thought of this before?
Apache when you come down to it, is a file server, yay.
ViolaWWW is a program to view something, wow, never would have guessed that.
I wouldn't call any of those real innovations, just evolution of what came before.
Ok, now you show me some 'real innovations', and I will call them evolutions of what came before. I have not seen anything in my life that couldn't be classified as evolutionary when looking with a broad perspective. Even recent things like the vacuum tube, the transistor, powered flight -- they had been coming a long time before they were developed.
So before you poo-poo someone else's list, perhaps you could show us some concrete examples of 'real innovations', just so we're all on the same page.
Larry Wall copied Perl from existing languages like awk, sed, and sh. Apache copied (literally) the NCSA web server. Sure, these projects did not copy commercial, closed-source software, but that does not make Perl and Apache paragons of innovation.
Well, I suppose GP should have used awk as an example then... I would like to know what will classify as innovation using this mindset of 'it is similar to something else, so no innovation'. By that measure, I suppose Engelbart had real innovation and everyone else has just been playing with his ideas. I guess he wasn't that innovative either, because he was just mimicking ordinary objects. And no programming language can really be innovative, because we have Lisp. Or in fact, after Lambda calculus it all just stagnated.
Nothing is truly new in the sense that it has no relationship to anything that came before -- things that are recognised as innovations are usually improvements on existing things or combinations of existing things. I think perl is significantly different from awk, sed and sh, learning from them but building something new. I am not an expert on Apache, but I get the feeling there are new and exiting improvements in there that were not put in by the NCSA guys.
Re:Why emacs? Because it's greast
on
The Future of Emacs
·
· Score: 5, Insightful
You know, I'm a fan of emacs, but doesn't this everything-and-the-kitchen-sink approach go against the Unix philosophy of making lots of small interoperable tools that do one thing really well?
But you see, that is why emacs is so great, because all of these 'features' are not 'built into' emacs, but in fact emacs lisp programs that extend the basic editing functionality. The core emacs abilities are key to editing: supply a place for the text to be displayed (buffers), supply easy ways to switch between multiple files being edited (this may be slight overkill -- perhaps a window manager should be used for this, or some terminal switching type program, but getting the kill ring to come across those would be hard), supply a good arsenal of editing commands at a low level, and supply the ability to change the action mapped to any key. All the rest is on top of this core. A lot of the functionality is even sourced from other commands (like ediff -- uses diff).
I think it was Eric Raymond who said that all the time that went into snazzy interfaces and GUI support in other programs was spent on editing text in emacs. It shows -- if you want to edit text, use a dedicated text editor.
That being said, I think the main reason for Tetris in emacs is "because it's there" -- on some geek level it seems quite cool to me.
To a large extent, I use emacs because it is the only editor I have worked with that offers the comprehensive support for LaTeX that I need. The AucTeX environment has an absolutely amazing grasp of how the LaTeX process works and what support structures are required to speed development with extensive keyboard support. Of course, once you start using Emacs you start realising that it is really nice to be able to transpose characters, change case, transpose lines, have a working kill ring and amazing code editing support.
I have not found an editor that does as much to help me get my code on the screen in such an unobtrusive way. Because each major mode is not just a set of highlighting and indenting rules, but indeed a little customised editor, you get thousands of hours worth of tweaking for indenting code, adding helpful hints, language-specific doodads (the FORTRAN mode has special support for moving blocks and locating variables), etc, all with very little cost in terms of screen real estate. And did I mention good keyboard support? And the fact that the editor and keybindings stay the same in Windows, Linux and Mac OS X -- I'l take that above 'interface guidelines' any day[1].
I think the high integration of a good programming language (emacs lisp is quite good at doing what it does) also makes all of these things easier and more natural to develop, as a set of handy scripts easily transitions into a major mode.
I am constantly plagued by the idea that someone, somewhere is doing something more efficiently than I am, so I experiment with editors constantly. I have tried more than I can remember. If you have a good recommendation, reply on this thread, but for me the question has always come back to 'why _not_ emacs?'.
[1] I also think that interface guidelines are heavily weighted toward the inexperienced user -- emacs has a high learning curve, but like many professional tools, it pays back once you have learned to use it. Many people (like me) find it clunky to have to wade through seven levels of menus to find a feature when I could have just used M-x obscure-feature-name.
Unix copy/paste? What's wrong with it? I copy stuff to and fro quite happily. Or are you whining about the "select is copy, middle click is paste"? Because while you were apparently sleeping, the mainstream stuff all started supporting Ctrl+C/Ctrl+V.
Let me see,
gnome-terminal: No
emacs: No
Ctrl+C never work in terminal applications, and I don't think emacs have ever cared about any kind of UI standards.
You cannot expect emacs to adopt Ctrl+C for copying (or any of the other 'UI standards') when it runs on many, many different platforms and has a large user base that likes the bindings just the way they are. Of course, you could re-assign the bindings, or use an emacs that has bindings you like (Aquamacs allows 'normal' Mac bindings). Of course, in terminal Ctrl+C has a predefined meaning (to kill the currently running process). I would feel quite lost of I tried to kill a running console app and got no response.
Your point is probably that we should change from the way that feels natural to us to something that seems natural to other people. Honestly though, the kind of person who likes using Mac shortcuts is not very likely to fire up Emacs or gnome-terminal. If they want to learn these things, surely a natural thing to learn are the keybindings? I guess this just goes back to the point that Linux developers are largely in this to make life better for themselves. It is ok to make things better for other people in the process, but it becomes really difficult to motivate when people want you to do things that are good for them but bad for you.
I know I shouldn't feed you, but I guess I'm feeling in that mood.
Popularity and ease of use for the novice user is what made Windows what it is. Fortunately one does not remain a novice forever, and once one starts wanting more power, one starts looking at stuff like Emacs. I have not found (and believe me, I have looked) a Free editor that has even half the power of Emacs for the stuff I do (like LaTeX editing, multiple language coding in the same environment). If you have an alternative that will make me more productive than I am using Emacs, I would be happy to suffer the same learning curve I went through with Emacs. In fact, if you could point me to an alternative to LaTeX for typesetting my PhD that would be as easily automatable and customisable as LaTeX, producing the same or better quality output, I would also be happy to investigate.
Some people use what they use because they have tried all reasonable alternatives and chosen what works best for them.
"There is just a different mindset between geeks and non-geeks for many things."
That's true, but does that automatically mean the geeks should cater to the non-geeks? If I have an engineering, computer-savvy mindset, should I not use expressions like F = m*a in my code because perhaps a non-engineer won't understand it? I use the things that make me happy and they can use the things that make them happy and we don't have any problem. The problems start when they use things that make them happy but make me sad -- like Word files I can't open and they can't understand. I think that as more formats open up and higher abstraction makes it easier to port applications to the platforms where they are needed, the problem will just go away.
Here in South Africa, the going rate is about ZAR 5 for a 'bankie', (about an ounce). If you buy bulk it's less, but 4500 $ * (6.6 ZAR / $) * (1 ounce / 5 ZAR) gives about 168 kilos (370 pounds). That's a LOT of weed. Guess it helps to be close to the point of production.
Well, I think we DO need the RIAA. For example, if you write a hit song, and someone else TAKES it......what happens to you?
Well, you sue them using existing compyright law (if they have indeed breached your rights). This is like if someone wrongs you in any illegal way -- you take it up in court. So, we do not need the *AA any more than we need a Murder Victims Guild.
"Intellectual property" is a term invented by the people you're shilling for. It's not a real thing that can be removed from someone's posession, thus is not a valid target for "theft."
So, I can hack into your bank and initiate an electronic funds transfer from your account to my account, right? I'm not taking away any actual currency from your physical possession, I'm merely shifting bits around inside the bank. I'm not even taking the bits *from you*, but if you're going to be picky about it, I can give you a CD-ROM chock full of bits. This is ok with you, right?
The act you are describing would properly be called fraud, not theft. Fraud is illegal. Theft is illegal. Fraud is not theft. Reducing the namespace of criminal acts makes it more difficult to distinguish between severity of crimes. Copyright infringement, patent violations, fraud and theft are all quite different things, entailing different calls on morality. Once we use one word to describe all of them, they become equated in the minds of the public, which is what the record labels and the rest of the pro "Intellectual Property" community wants. They want everyone to equate ideas with physical property.
This is also why there are several outspoken people who try to avoid clouding their thinking this way. Patents, copyright, breeder's rights, trademarks, etc all cover different aspects of law surrounding intangible things.
Interestingly, none of them cover the actual intangible thing. One is not granted ownership of an idea/song/etc, one is granted rights to a limited monopoly on the exploitation of that idea/song/whatever. This right is in the case of copyright given as soon as the idea is transformed to physical media, and happens automatically. The phrase 'copyright theft' is therefore so strained as to be laughably meaningless.
What all this comes down to (for those of you still tuned in), is that most people are not trying to say "it's not theft so it's OK", they are trying to say "it's not theft, so we should approach it differently from theft'. Jaywalking is not 'road theft'. Murder is not 'life theft' and copyright infringement is not 'copyright theft'. Let's keep the law nice and clear.
laptops can be difficult to use for a full 8 hour day. The keyboard is all wrong, and the screen is always too low.
Actually, the conventional wisdom of a high screen is not as accurate as you may think. Check out the picture here. They show a good viewing position for your screen in about the same position as your laptop screen would be (just a bit further away).
6. Once work hours ends, forget everything until the next day regardless of the pressure. Work isn't your personal life.
What about academia? I am in the fortunate position to do during the day basically what I would have done anyway, but getting paid for it. My research and learning is my passion, and I see the University only as an alternative place to go and do research and learn. Score. Not all jobs require that you switch off when you leave.
Isaac Newton was a firm believer in alchemy. Strangely, he still managed to do good science. Unfortunately one's belief in things other than the clinical hand of science is not a good indicator of scientific prowess -- athiests do not make better scientists than scientologists/pagans/christians/etc automatically.
Of course there is the ever-present interplay of freedom vs security. I guess the grandparent just has a higher need for freedom than his perceived small increase in security from these measures justifies.
Slashdot Mirror
That's just plain BS. I can write a C compiler in AWK, using an AWK that runs on LISP in a LISP machine and generates JAVA bytecode. That does not mean it is no longer a C compiler but just a frontend to the JAVA virtual machine. Just because some Haskell compiler is written in C (and might I add most modern native compilers are self-compiling as a matter of pride), doesn't mean you just have a 'high level language frontend for the underlying C code'.
The real problem is how coupled compilers and languages are in most peoples minds. Languages aren't fast, compilers are efficient. Anything you say about C can be said about any other Turing complete language. They are all equivalent in computing power. However, compilers may be very good at converting the language to efficient machine instructions. This is due to language semantics and some accidental effects like the number of man-hours that have gone into tuning said compilers. In every case, the efficiency of a compiler is not an absolute that can be calculated but a qualitative measure of how well it does.
So, language efficiency is really not a sensible phrase. We could be worrying about matching compiler abilities with language semantics, but even then, machine architectures vary, leading to changes on the language level to cater for achitectural differences (would C still do well on a Lisp machine or a PostScript printer or a GPU?). In the end, making choices based on specific machine capabilities will lead to short term gains, but as compiler tech gets better and the number of platforms increases more abstraction will make it easier to get 'ok' performance on 'most' platforms.
The entire field of Linear Systems (start at http://en.wikipedia.org/wiki/System_analysis and click out from there) is greatly simplified by converting systems of linear differential equations to Laplace domain ( http://en.wikipedia.org/wiki/Laplace_transform ) and getting a frequency response by substituting s = iw where i = sqrt(-1) and w is a frequency. Due to the Euler identity ( http://en.wikipedia.org/wiki/Euler's_identity ), we can then transform this all back to time. The simplification is that we manipulate differential equations as algebraic equations in Laplace space.
I do this stuff all day and I can not imagine a world where sqrt(-1) is just undefined. Of course, the Laplace domain is not really restricted to linear systems, but it makes things easier when they are.
Now, this could all seem like "mathematical dickwaving" to you if you have not used it before, but it seems pretty damn useful to me that I can now determine optimal controller settings mathematically instead of having to guess values and have my plant blow up in the process. So there you have my little piece of the usefulness of imaginary numbers. (pure) Mathematics are not really involved in solving practical problems, but engineers can use all this rigorous theory to solve real problems. It is possible to prove that we don't need more than simple operators and a few digits to solve all problems -- having powerful mathematical tools just makes the journey shorter and more enjoyable.
OO.org's formula editing is very similar to WordPerfect's old style formulas. They are both based on the EQ syntax used by TROFF and GROFF, but not anything like XML.
I say: How about I do my thing and they do theirs and if they can't get their thing done it is not my job to do it for them? Why is it that it is always the technologically literate people who have to "focus your skills on making it easier for people to do what they do want to do". I am also a person and I also want to do what I want to do. Who's looking out for me?
In many cases they learn to program for their own projects, where speed/ease of coding may be more important than security. If you just pick up an old C book, no-one warns you to stay away from gets(), so people learn to use it, and it works. Then they get told to use something else that is more secure but it is slow or more difficult to learn, so they don't.
In my building there is a whole floor of guys doing simulations in Fortran 77. When I tell them about new functions in F90 or about ways they could solve their problem in C++ they have only one question: "isn't that going to be slow?".
So ultimately the problem is that most "bad" code comes from people who have hacked together a useful tool by leveraging their experience in fields where security or stability doesn't really matter. They have probably been coding successfully for some time without ever seeing anything wrong with their approach until they used it out of context.
You totally misunderstand Stallman's ideology. This is the exact reason he has tried to distance the Free Software movement from the Open Source movement. The OS philosophy is pragmatic. They say OS is a good business choice and in some cases can be a better way for everone to profit from software.
The FS people are not pragmatists. This is the first thing you probably don't understand (you seem like a hardcore pragmatist yourself). The movement is about the idea that software (and other forms of abstract information) should not be bound by the same rules as physical objects. They are different and should be treated differently. To some extend Stallman is a Utopian. The difference is that he has taken real steps to move in the direction he wants the world to move in. And it has paid off greatly. The GNU tools are ubiquitous in Unix-like environments.
As other posters have said: do your thing your way, but understand that this man has principles (not just wrong-headedness) and has put in an amazing amount of effort to stick by them. You may mock principles for being inefficient, but some of us respect them.
I get that one can add protective measures that are not 'in the way' and that a tool that encourages or invites accidents or misuse could be redesigned to make it inherently safe. I am an engineer, so I am aware of the idea of designing in safety. As I said, you make a few good points.
I think the problem with your original post is that it muddies the water with statements like 'long manuals are the hallmark of bad design' in the context of computer use. Especially because many of the readers here regularly use language-based tools that are literally impossible to master without a manual, simply because language is not self-documenting, and does not necessarily have to be. I think what you may be missing is that people like the GNU project have put in significant effort to make their tools 'intuitive' to the user, by using similar flags and by presenting a unified abstract view of the machine through files. Perhaps you where trying to say that the 'original' unix attitude encouraged bad design, but that it is changing. Instead it came off as bashing non-graphical/non-self-documenting systems as overly dangerous and complex.
I think usability and power are not totally orthogonal, but there is a nonzero angle between them. We can all agree that some usability improvements cost nothing in power, but we will not agree that a complicated system relying on use of language to supply power can be used optimally without reading the instructions.
PS: I think I agree with almost everything you are saying, so don't think I am being argumentative.
You make a few good points, but seem to have a misplaced faith in designing out problems. Let's take a look at the 'real world', which has been around a lot longer than the computer world, and see whether good design has triumphed to make the world around us work without danger and reliance on human memory or judgement.
Let's look at powertools, cars, airplanes, guns, knives or other things that modern people use. All of them have measures designed to stop people from hurting themselves and require no training to use, as their use is obvious, right? Wrong. If I design a knife that is too blunt to cut flesh, it cannot cut my steak. If I design a car that does not move fast enough to kill me if I am in an accident, the car doesn't move fast enough period. Notice how this is ok, and how we can give kids blunt plastic knives until they have learned how to use them well enough to use 'big tools'.
This pattern is even more pronounced with 'professional tools' like planers, jigs or powerful hydroulics. You need trained operators for those, because they can take of your arm or kill many people at once. The true myth of our time is that computers should be both easy to use and powerful enough to do anything you want. Design can bring you so far, but each level of ease of use you slap onto a device usually makes it that much less powerful. Observe F1 racing cars -- not an 'easy drive', but really good at what they do. Safety measures and 'easy to start' engines are too heavy, so they don't make the cut.
Getting back to the computer, there is no way to stop you from making mistakes. There are a few common mistakes, but there is no reliable way of knowing whether the user really wanted to delete all the files in that directory. I know people who have 'accidentally' deleted files in Windows, clicked on 'yes, I am sure', emptied the recycle bin and then realised they made a mistake. How was the operating system to know to stop the user? Professionals hate people looking over there shoulders, double-guessing their actions. They don't like little dogs asking them to type a file query. They like the power of a stripped down interface that allows them the freedom to do what they want they way they want. If all your needs are filled by GUI tools, there is no reason not to use them, but I prefer to get stuff done my way.
So, in the end, things get down to formalisms and language. And that's the thing about language -- it has rules. You have to learn the rules. You have to use the language often to remain fluent. What you get in return is tha ability to express yourself accurately. And thank goodness that we have a powerful language interface to the OS in things like bash.
Humans are well-equipped to accept visual input. We have good pattern recognition and high bandwidth for visual processing. So it is no surprise that people are happy in a graphical environment that shows them much of what they want to know using rich graphics. What is surprising is the eagerness with which they discard language as a medium for outputting information.
Most people are bad at expressing themselves exactly using pictures or gestures. It is only using formalised systems like language (or sign language) that we gain the abstraction necessary to express ourselves about things we cannot see or that have not happened yet. Common problems can be solved using nice interfaces that allow you to do only 'the right thing'. Once you reach Turing completeness, however, it is provably impossible to stop someone from screwing up in ways that are undetectable by the system.
This is the core of the problem. Most people want to give vague directions to an expert and have him use judgement to deliver an acceptable solution to the problem. These people are not heavy computer users or see the computer as a means to an end . They are probably best served by custom apps that do the things they want to do very well with low risk of error. Other people need computers on a daily basis to complete complex tasks that are unique to their situations. Analysts, accountants, engineers all need computers to do exactly the thing they need done in exactly the way they want. For these people, a system of choosing the 'correct' options soon turns into an extreme challenge in itself. Excel is Turing complete, but it is damn near impossible to imagine elegant ways of handling some of the problems I have solved with a few lines of Python or Matlab code.
What I am trying to say is that this idea of people being reluctant to program is only valid because we have actively discouraged the use of precise language to describe problems. We have encouraged people who lack the means to express themselves by saying that they should be allowed to use a more 'forgiving' interface. There will always be a trade-off between power and ease of use. Somehow, we have come to believe that it is ok to spend 15-20 years mastering a native language, but mastering an environment that allows you to communicate with a computer should take no less than a few days. What kind of expressive power can we expect then?
I would like to point out that the article is not about plain phase changes, but rather about phase changes near the critical point , where liquid and gas phases become indistinguishable. Predicting ideal phase change behaviour has been done, but the critical point poses some unique challenges.
perl is a programming language, surely nobody thought of this before?
Apache when you come down to it, is a file server, yay.
ViolaWWW is a program to view something, wow, never would have guessed that.
I wouldn't call any of those real innovations, just evolution of what came before.
Ok, now you show me some 'real innovations', and I will call them evolutions of what came before. I have not seen anything in my life that couldn't be classified as evolutionary when looking with a broad perspective. Even recent things like the vacuum tube, the transistor, powered flight -- they had been coming a long time before they were developed.
So before you poo-poo someone else's list, perhaps you could show us some concrete examples of 'real innovations', just so we're all on the same page.
Larry Wall copied Perl from existing languages like awk, sed, and sh. Apache copied (literally) the NCSA web server. Sure, these projects did not copy commercial, closed-source software, but that does not make Perl and Apache paragons of innovation.
Well, I suppose GP should have used awk as an example then... I would like to know what will classify as innovation using this mindset of 'it is similar to something else, so no innovation'. By that measure, I suppose Engelbart had real innovation and everyone else has just been playing with his ideas. I guess he wasn't that innovative either, because he was just mimicking ordinary objects. And no programming language can really be innovative, because we have Lisp. Or in fact, after Lambda calculus it all just stagnated.
Nothing is truly new in the sense that it has no relationship to anything that came before -- things that are recognised as innovations are usually improvements on existing things or combinations of existing things. I think perl is significantly different from awk, sed and sh, learning from them but building something new. I am not an expert on Apache, but I get the feeling there are new and exiting improvements in there that were not put in by the NCSA guys.
You know, I'm a fan of emacs, but doesn't this everything-and-the-kitchen-sink approach go against the Unix philosophy of making lots of small interoperable tools that do one thing really well?
But you see, that is why emacs is so great, because all of these 'features' are not 'built into' emacs, but in fact emacs lisp programs that extend the basic editing functionality. The core emacs abilities are key to editing: supply a place for the text to be displayed (buffers), supply easy ways to switch between multiple files being edited (this may be slight overkill -- perhaps a window manager should be used for this, or some terminal switching type program, but getting the kill ring to come across those would be hard), supply a good arsenal of editing commands at a low level, and supply the ability to change the action mapped to any key. All the rest is on top of this core. A lot of the functionality is even sourced from other commands (like ediff -- uses diff).
I think it was Eric Raymond who said that all the time that went into snazzy interfaces and GUI support in other programs was spent on editing text in emacs. It shows -- if you want to edit text, use a dedicated text editor.
That being said, I think the main reason for Tetris in emacs is "because it's there" -- on some geek level it seems quite cool to me.
To a large extent, I use emacs because it is the only editor I have worked with that offers the comprehensive support for LaTeX that I need. The AucTeX environment has an absolutely amazing grasp of how the LaTeX process works and what support structures are required to speed development with extensive keyboard support. Of course, once you start using Emacs you start realising that it is really nice to be able to transpose characters, change case, transpose lines, have a working kill ring and amazing code editing support.
I have not found an editor that does as much to help me get my code on the screen in such an unobtrusive way. Because each major mode is not just a set of highlighting and indenting rules, but indeed a little customised editor, you get thousands of hours worth of tweaking for indenting code, adding helpful hints, language-specific doodads (the FORTRAN mode has special support for moving blocks and locating variables), etc, all with very little cost in terms of screen real estate. And did I mention good keyboard support? And the fact that the editor and keybindings stay the same in Windows, Linux and Mac OS X -- I'l take that above 'interface guidelines' any day[1].
I think the high integration of a good programming language (emacs lisp is quite good at doing what it does) also makes all of these things easier and more natural to develop, as a set of handy scripts easily transitions into a major mode.
I am constantly plagued by the idea that someone, somewhere is doing something more efficiently than I am, so I experiment with editors constantly. I have tried more than I can remember. If you have a good recommendation, reply on this thread, but for me the question has always come back to 'why _not_ emacs?'.
[1] I also think that interface guidelines are heavily weighted toward the inexperienced user -- emacs has a high learning curve, but like many professional tools, it pays back once you have learned to use it. Many people (like me) find it clunky to have to wade through seven levels of menus to find a feature when I could have just used M-x obscure-feature-name.
Let me see, gnome-terminal: No emacs: No Ctrl+C never work in terminal applications, and I don't think emacs have ever cared about any kind of UI standards.
You cannot expect emacs to adopt Ctrl+C for copying (or any of the other 'UI standards') when it runs on many, many different platforms and has a large user base that likes the bindings just the way they are. Of course, you could re-assign the bindings, or use an emacs that has bindings you like (Aquamacs allows 'normal' Mac bindings). Of course, in terminal Ctrl+C has a predefined meaning (to kill the currently running process). I would feel quite lost of I tried to kill a running console app and got no response.
Your point is probably that we should change from the way that feels natural to us to something that seems natural to other people. Honestly though, the kind of person who likes using Mac shortcuts is not very likely to fire up Emacs or gnome-terminal. If they want to learn these things, surely a natural thing to learn are the keybindings? I guess this just goes back to the point that Linux developers are largely in this to make life better for themselves. It is ok to make things better for other people in the process, but it becomes really difficult to motivate when people want you to do things that are good for them but bad for you.
I know I shouldn't feed you, but I guess I'm feeling in that mood.
Popularity and ease of use for the novice user is what made Windows what it is. Fortunately one does not remain a novice forever, and once one starts wanting more power, one starts looking at stuff like Emacs. I have not found (and believe me, I have looked) a Free editor that has even half the power of Emacs for the stuff I do (like LaTeX editing, multiple language coding in the same environment). If you have an alternative that will make me more productive than I am using Emacs, I would be happy to suffer the same learning curve I went through with Emacs. In fact, if you could point me to an alternative to LaTeX for typesetting my PhD that would be as easily automatable and customisable as LaTeX, producing the same or better quality output, I would also be happy to investigate.
Some people use what they use because they have tried all reasonable alternatives and chosen what works best for them.
"There is just a different mindset between geeks and non-geeks for many things."
That's true, but does that automatically mean the geeks should cater to the non-geeks? If I have an engineering, computer-savvy mindset, should I not use expressions like F = m*a in my code because perhaps a non-engineer won't understand it? I use the things that make me happy and they can use the things that make them happy and we don't have any problem. The problems start when they use things that make them happy but make me sad -- like Word files I can't open and they can't understand. I think that as more formats open up and higher abstraction makes it easier to port applications to the platforms where they are needed, the problem will just go away.
Here in South Africa, the going rate is about ZAR 5 for a 'bankie', (about an ounce). If you buy bulk it's less, but 4500 $ * (6.6 ZAR / $) * (1 ounce / 5 ZAR) gives about 168 kilos (370 pounds). That's a LOT of weed. Guess it helps to be close to the point of production.
Well, I think we DO need the RIAA. For example, if you write a hit song, and someone else TAKES it......what happens to you?
Well, you sue them using existing compyright law (if they have indeed breached your rights). This is like if someone wrongs you in any illegal way -- you take it up in court. So, we do not need the *AA any more than we need a Murder Victims Guild.
"Intellectual property" is a term invented by the people you're shilling for. It's not a real thing that can be removed from someone's posession, thus is not a valid target for "theft."
So, I can hack into your bank and initiate an electronic funds transfer from your account to my account, right? I'm not taking away any actual currency from your physical possession, I'm merely shifting bits around inside the bank. I'm not even taking the bits *from you*, but if you're going to be picky about it, I can give you a CD-ROM chock full of bits. This is ok with you, right?
The act you are describing would properly be called fraud, not theft. Fraud is illegal. Theft is illegal. Fraud is not theft. Reducing the namespace of criminal acts makes it more difficult to distinguish between severity of crimes. Copyright infringement, patent violations, fraud and theft are all quite different things, entailing different calls on morality. Once we use one word to describe all of them, they become equated in the minds of the public, which is what the record labels and the rest of the pro "Intellectual Property" community wants. They want everyone to equate ideas with physical property.
This is also why there are several outspoken people who try to avoid clouding their thinking this way. Patents, copyright, breeder's rights, trademarks, etc all cover different aspects of law surrounding intangible things.
Interestingly, none of them cover the actual intangible thing. One is not granted ownership of an idea/song/etc, one is granted rights to a limited monopoly on the exploitation of that idea/song/whatever. This right is in the case of copyright given as soon as the idea is transformed to physical media, and happens automatically. The phrase 'copyright theft' is therefore so strained as to be laughably meaningless.
What all this comes down to (for those of you still tuned in), is that most people are not trying to say "it's not theft so it's OK", they are trying to say "it's not theft, so we should approach it differently from theft'. Jaywalking is not 'road theft'. Murder is not 'life theft' and copyright infringement is not 'copyright theft'. Let's keep the law nice and clear.
Why bother?
Because it is a passion. I get to learn new things that nobody else knows yet. I get paid to do that.
Unfortunately, this also explains why our salaries are so low...
laptops can be difficult to use for a full 8 hour day. The keyboard is all wrong, and the screen is always too low.
Actually, the conventional wisdom of a high screen is not as accurate as you may think. Check out the picture here. They show a good viewing position for your screen in about the same position as your laptop screen would be (just a bit further away).
6. Once work hours ends, forget everything until the next day regardless of the pressure. Work isn't your personal life.
What about academia? I am in the fortunate position to do during the day basically what I would have done anyway, but getting paid for it. My research and learning is my passion, and I see the University only as an alternative place to go and do research and learn. Score. Not all jobs require that you switch off when you leave.
Isaac Newton was a firm believer in alchemy. Strangely, he still managed to do good science. Unfortunately one's belief in things other than the clinical hand of science is not a good indicator of scientific prowess -- athiests do not make better scientists than scientologists/pagans/christians/etc automatically.
Of course there is the ever-present interplay of freedom vs security. I guess the grandparent just has a higher need for freedom than his perceived small increase in security from these measures justifies.