You could implement that as a top-level function or even as a class method, and it would just work. And it would be easy to understand and program (something which, I believe, Lisp macros aren't).
The only difference I think it would have is that it would run at execution time, not compile time. But I'm sure that a not too far away future version of Python will do that...;-)
so, the whole point is that Lisp is not a programming language but a kind of language definition language? Just a raw parse tree, and Build Your Own Syntax. See why I say it's difficult? You haven't ANYTHING done for you in advance.
I never got to understand why Lisp programmers think of the macro system as the primary and more exclusive power of the language, now I start to see it. But how do to learn to create those domain-specific languages? It is so far away from conventional academic lectures, that one needs to forget almost everything to start thinking that way!
And I'm not convinced that that syntaxlessness is indispensable. If the matter is problem solving, just learn problem solving, not Lisp language. I
would prefer to have some syntactic sugar which does the code more readable than those ((if()(and no then)(nor else keywords))s), even if that makes a little bit more difficult the "new language definition" (and I don't think it would: macro definition is famous to be a tricky bussiness on its own).
ORN: This resonates with your long-held interests in "computer programming for everyone". Don't you think that perhaps "everyone" is too broad, and that there aren't at least some people who will never be capable programming a computer?
GvR: That's a deep philosophical question. I'm optimistic about that in theory.
[...]
Given that I believe everybody can learn to read and write, given the right education and circumstances--obviously if your parents have no money and you're sent to work when you're seven years old, you're not in a very good situation unless you're exceptionally smart--I believe that the same thing would be possible for programming and thinking logically to some extent.
Show me one benefit of Lisp over Oz. And there are the drawbacks of Lisp, too. It has a really steep learning curve, and there are no good free (as in software) development environments, as far as I know. (IANALisp Expert, though). Just you, Emacs and the Lisp interpreter.
Lisp is as powerful as mathematics, but there is more to a language than its semantics. It has to be accessible, too.
The second name of Python is "Executable Pseudocode".
Sure you can do the same things in other languages, at the end all general languages are Turing Machine equivalent. The difference is that Python is EASY to read (according to Master Yoda). It is bottom-up designed to be.
So it is good not only for scripting, but too for prototyping and for everything which needs to be flexible and not too much efficiency-critical. The logic of some videogames is encoded in Python, you know.
Don't ever expect to see any contributions to Linux by the Communist party. Certainly they will modify it, release it and sell it, but you will never see the source.
I don't think that will happen, but if it does, it will be bad for them. By rejecting the GPL they would be creating an effective fork, and they would loss all support from the rest of the world community.
Don't think so, being a leftie myself. Of course you saying left-wingers would fucking freak out don't help your cause, but the overall post brings some interesting points.
Is humanity determined by the specific genotype you happen to have now? Any more that by your fenotype? If you do a aesthetic surgery, you are changing yourself into something that you couldn't naturally be. That too would make you less human?
Changing your life habits to live longer and healthier don't make you less human. If that goal is achieved by changing your genes, would it be different? Or if you are made physically stronger so you don't need a fork lift truck to carry packages and now can do it manually, is that so important?
Well I'm afraid I agree with the troll 8-) although I will put it in a less trollish way.
For a tool like a "graphic command line" to achieve widespread acceptance, it have to be both practical and easy to learn. I was thinking in something like Piper when I post the first comment. Piper has the following "paradigm" to connect different pieces:
Everything is a component.
Every component can accept (input) or produce (output) data, or do both.
Components can be connected or "piped" according to their input and output of data.
All components have a network "location." Components can therefore be refered to as "loci."
Nodes are only represented locally, if possible.
The problem I see with Piper is that it isn't integrated with the desktop, so new users have to learn a whole new set of concepts to get started with it.
If a project like Piper had a wrapper to access it from Karamba, for example, it would have the eye-candy and the consistent and well-known interface that it currently lacks. That kind of friendliness to end user is necessary, and I think that if Piper could be used directly from KDE it would have more acceptance.
And why do you call KDE and Gnome proprietary?;-) They are less proprietary that Unix pipes!
I've been waiting long for something to equal the power of the command line + Unix philosophy in a graphical environment. I think this technology has that power. I think we soon will see a set of graphic small tools which do one thing, and do it well.
Why "classic" frameworks as Gnome and KDE failed to provide this tools? Well, they follow the "component model", which basically means that there are BIG modular reusable tools intended to have everything but the kitchen sink. Those components are great to assemble stand alone applications, because they provide a great chunk of related functionallity. But that's not the Unix way.
The Unix way is to have small and versatile commands, to know what they do and to combine them in new ways to solve problems as they appear. I think most GNU hackers (and some intermediate users) benefit from that approach, and I think that a text command line is not a requirement for that.
You only need a common API to communicate those small tools, something that Unix carry out with pipes. But now we have two new environments, Karamba and gDesklets, which could be the base for a graphic API. I believe it's time to move from the Command Line Interface to the Command Graphical User Interface.
If you like gestures, use a window manager with gestures. They certainly exist, even fvwm has support for them, for heaven's sake!
That doesn't solve the specific problem of browsing through a strongly packed set of web pages as well as tabbed browsing does.
If you defer gestures recognition to the window manager, gestures will change through whatever application you have open in that virtual desktop.
You could add gestures to change only through current application, true (does fvwm have that feature?); but you still don't have all related page titles exposed in a single consistent place. For me, a "decent window manager" would be the one that implements tabs, which is the exact solution that I like.
No way. Those window managers have the titles hidden under a clickable button, not exposed side-by-side, which is the whole purpose of tabs in Mozilla.
You mean, a window manager which recognizes gestures in every app?
I use tabs mainly for the ability to change pages while browsing with just a rightclick-up-right gesture. And I haven't met yet a window manager which let me do that - namely, changing between windows in a same application with a gesture.
Not to mention the wonderfull usefullness of having the title of all pages not mixed with the titles of other open programs.
...that VR technology is being used in civil security training, and not just for military training. If videogames end in saving lifes, it's a good thing.
Slashdot Mirror
then, no mathematical mind is healthy! 8-) You did well in change, if you have a sequential mind.
You could implement that as a top-level function or even as a class method, and it would just work. And it would be easy to understand and program (something which, I believe, Lisp macros aren't).
;-)
The only difference I think it would have is that it would run at execution time, not compile time. But I'm sure that a not too far away future version of Python will do that...
;-) And I would like to like Lispness, but just don't get it.
I never got to understand why Lisp programmers think of the macro system as the primary and more exclusive power of the language, now I start to see it. But how do to learn to create those domain-specific languages? It is so far away from conventional academic lectures, that one needs to forget almost everything to start thinking that way!
And I'm not convinced that that syntaxlessness is indispensable. If the matter is problem solving, just learn problem solving, not Lisp language. I would prefer to have some syntactic sugar which does the code more readable than those ((if()(and no then)(nor else keywords))s), even if that makes a little bit more difficult the "new language definition" (and I don't think it would: macro definition is famous to be a tricky bussiness on its own).
ORN: This resonates with your long-held interests in "computer programming for everyone". Don't you think that perhaps "everyone" is too broad, and that there aren't at least some people who will never be capable programming a computer?
GvR: That's a deep philosophical question. I'm optimistic about that in theory.
[...]
Given that I believe everybody can learn to read and write, given the right education and circumstances--obviously if your parents have no money and you're sent to work when you're seven years old, you're not in a very good situation unless you're exceptionally smart--I believe that the same thing would be possible for programming and thinking logically to some extent.
Lisp is as powerful as mathematics, but there is more to a language than its semantics. It has to be accessible, too.
Sure you can do the same things in other languages, at the end all general languages are Turing Machine equivalent. The difference is that Python is EASY to read (according to Master Yoda). It is bottom-up designed to be.
So it is good not only for scripting, but too for prototyping and for everything which needs to be flexible and not too much efficiency-critical. The logic of some videogames is encoded in Python, you know.
Sorry I don't have mod points, folk.
And this one sounds as good news for world widespread interoperability!
I don't think that will happen, but if it does, it will be bad for them. By rejecting the GPL they would be creating an effective fork, and they would loss all support from the rest of the world community.
Doom III is not part of the GNU project, as far as I know.
How are you typing?
Oh well, don't answer.
Don't think so, being a leftie myself. Of course you saying left-wingers would fucking freak out don't help your cause, but the overall post brings some interesting points.
Is because it has the word 'fucking' in it? And the granparent is a troll, why?
This is a job for Metamoderator!!
OK thanks. It's "fenotipo" in my mother language, and although I searched it in a dictionary then I got it wrong again when I wrote it down! 8-)
Is humanity determined by the specific genotype you happen to have now? Any more that by your fenotype? If you do a aesthetic surgery, you are changing yourself into something that you couldn't naturally be. That too would make you less human?
Changing your life habits to live longer and healthier don't make you less human. If that goal is achieved by changing your genes, would it be different? Or if you are made physically stronger so you don't need a fork lift truck to carry packages and now can do it manually, is that so important?
For a tool like a "graphic command line" to achieve widespread acceptance, it have to be both practical and easy to learn. I was thinking in something like Piper when I post the first comment. Piper has the following "paradigm" to connect different pieces:
- Everything is a component.
- Every component can accept (input) or produce (output) data, or do both.
- Components can be connected or "piped" according to their input and output of data.
- All components have a network "location." Components can therefore be refered to as "loci."
- Nodes are only represented locally, if possible.
The problem I see with Piper is that it isn't integrated with the desktop, so new users have to learn a whole new set of concepts to get started with it.If a project like Piper had a wrapper to access it from Karamba, for example, it would have the eye-candy and the consistent and well-known interface that it currently lacks. That kind of friendliness to end user is necessary, and I think that if Piper could be used directly from KDE it would have more acceptance.
And why do you call KDE and Gnome proprietary? ;-) They are less proprietary that Unix pipes!
I've been waiting long for something to equal the power of the command line + Unix philosophy in a graphical environment. I think this technology has that power. I think we soon will see a set of graphic small tools which do one thing, and do it well.
Why "classic" frameworks as Gnome and KDE failed to provide this tools? Well, they follow the "component model", which basically means that there are BIG modular reusable tools intended to have everything but the kitchen sink. Those components are great to assemble stand alone applications, because they provide a great chunk of related functionallity. But that's not the Unix way.
The Unix way is to have small and versatile commands, to know what they do and to combine them in new ways to solve problems as they appear. I think most GNU hackers (and some intermediate users) benefit from that approach, and I think that a text command line is not a requirement for that.
You only need a common API to communicate those small tools, something that Unix carry out with pipes. But now we have two new environments, Karamba and gDesklets, which could be the base for a graphic API. I believe it's time to move from the Command Line Interface to the Command Graphical User Interface.
Yes, I knew of Expose. It doesn't solve the same specific problem of quickly changing through related pages which you already know where are.
But for general application-switching, it certainly may be great. I haven't tried it though, I don't have Mac OS X.
If you like gestures, use a window manager with gestures. They certainly exist, even fvwm has support for them, for heaven's sake!
That doesn't solve the specific problem of browsing through a strongly packed set of web pages as well as tabbed browsing does.
If you defer gestures recognition to the window manager, gestures will change through whatever application you have open in that virtual desktop.
You could add gestures to change only through current application, true (does fvwm have that feature?); but you still don't have all related page titles exposed in a single consistent place. For me, a "decent window manager" would be the one that implements tabs, which is the exact solution that I like.
No way. Those window managers have the titles hidden under a clickable button, not exposed side-by-side, which is the whole purpose of tabs in Mozilla.
You mean, a window manager which recognizes gestures in every app?
I use tabs mainly for the ability to change pages while browsing with just a rightclick-up-right gesture. And I haven't met yet a window manager which let me do that - namely, changing between windows in a same application with a gesture.
Not to mention the wonderfull usefullness of having the title of all pages not mixed with the titles of other open programs.
...that VR technology is being used in civil security training, and not just for military training. If videogames end in saving lifes, it's a good thing.
And the "informative" parent from "reporter" should go down.
Tie fighters and atmosphere? I remember some of them at Cloud City, chasing the Millenium Falcon.