> Why would it be in Google's interests to do this? Because Google wants the best experience for its users.
Agreed, but a small hint, google is a SEARCH ENGINE, not a HTML correctness filter, just in case you didn't notice.
> And the best experience for users will be to get an XHTML valid webpage which works across any browser, is accessible for the blind and partially-sighted, and works on devices like mobile phones and PDAs.
*lol*
Yeah, that is the theory indeed.
Now if you excuse me, I'm back to reality of 2004, where XHTML is on average bigger then HTML 4.01 and is more complex to parse due to its XML complience.
In 2004, it also turns out to be the case that many PDA browsers understand HTML 3.2 and 4.01 perfectly well, but don't like sites using too much graphics, or sites countign on your screen being 800x600 no matter what.
Such sites that don't work with that are designed badly, and XHTML is a very bad kludge for trying to fix that, the design of such sites needs to be fixed.
So if you are worried about the PDA and Phone browsers, then you need to think again.
For that matter, the broken 3.2 variation that slashdot uses works pretty well on my PDA browser, while quite a few XHTML pages don't. (running PalmOS 4 and either palmscape or blazer)
So... wether HTML 4.01 or XHTML gives a better user experience is somewhat debatable, at least when looking at a real world PDA with 2 real world PDA browsers.
Ah well, have fun with your XHTML campeign, but get it out of your mind that it is relevant to the large majority of users, including those who the petition claims to help.
XHTMl > HTML 40.1 Strict > HTML 40.1 traditional >... Nah, that is not a usefull way to rank things when the content is what you are interested in (as opposed to whatever standard things comply with) So.. bad plan for as far as I'm concerned.
Ok, lets try to define this in a way that you may have a chance of understanding the point I am trying to make (and stop bothering making your point, I know you can do that and what the advantages of a commandline tool are in many cases, I have been using them for a long time really)
A commandline toool requires that
1. you can consiously express which files you want the tool to deal with in a way the tool understands, and
2. that you are aware of the tool to begin with.
WHen you can write an expression for 1 then all is fine, and when you cannot (for example because the files you need have not a single attribute that a computer can recognize and that you could express in a way that it can recognize, however that is extremely easy to recognize for you visually) then it is really a lot more efficient to have a visual environment for it.
You can try keep missing that point, and really, it is not about wether you prefer a gui or commandline in general, it is about that both can be better for some SPECIFIC cases, and you can count each and every case where a human is better at recognizing the information then a computer to that. And yeah, that may change when someone invents a way to have a computer deal with the specific type of information, but that is not going to change the overall picture.
THen, you are blindly ignoring a few facts here. The casual user has to take a quick peek at a manual page quite often when usign commandline tools. SOmeoen who uses them often won't for most cases, but someoen who uses them incidentley will. That makes the commandline very inefficient for everyone who is not going to use it very often. When your job is related to for example graphics processing, video editing, layout (as opposed to typesetting which can be done very well on the commandline), or anything else where you turn out workign a lot with graphical stuff then you are also very unlikely to spend much time at the commandline. When you happen to have a computer at home to read email every now and then and browse the web a bit, and write a letter every now and then, then you are not even using it often enough to remember all the details of each and every command, even if you were doing all from the commandline.
Bottomline, the commandline is more efficient in specific cases, a gui is more efficient in other specific cases, and everywhere inbetween, it really depends on who you are which tool works better. WHich one is most efficient in theory is completely and utterly irrelevant for the end-user.
Actually, freebsd comes with a fortune file that does something like that.
But a commandlien is goign to scare quite a few users at least at first. many such users already learned to 'deal' by clicking away windows they don't understand it seems tho, so I don't see a problem of having the icon in an easy to reach place for the quite substantial number of people who do use it often;P
> I think it's critical to learn what tools you have and how to use them correctly before you can really say "this is easier to do here vs. here".
You do realize that the amount of time and efford it takes to learn those tools is a huge factor in determining which one is easier I hope?
Yeah, people only spend a relatively short time learning something compared to the time they spent using it. That would suggest that the learning part is not very relevant, but it is because unless you are using a tool a lot really,there is a bit of recapturing knowledge involved each time you use it. The harder it is to learn a tool, the more difficult the tool will be to use incidentely (as opposed to using it all the time, there it really doesn't matter much)
Last but not least, your statement depends on the definition of the word easy. I bet that if you ask a random group of people out on the street about this, a large majority will agree that the easy to learn thign is in fact easier. It may not be more efficient, but that happens to also not be the same as easy.
> I'm not suggesting that you are not, but the key to being successful (efficient) at the cmd line is to have a certain level of mastery over the tools which are available.
I indeed think that when having used Unix systems before X even existed, I am aware of the find tool, and of tons of other possibilities to locate the specific information that I need from the commandline.
The problem with the commandline is that it is only faster if: 1. you know exactly which files you need and 2. you know how to select all of them.
Your comment is about the second condition, not the first.
Lets give you another example, you have a directory with the last 100+ pictures dumped from your camera, all having numerical names with no relation whatsoever to the content of the pictures yet. Now, you need to pick all pictures from that that relate to a specific subject, and move them into a seperate directory.
I see 2 ways for this.. commandline based, where it will load each picture, and asks if it should move that one also... or gui based with a previewer so you see them directly in your overview and can select the few that match. (and yeah, I explicitly took a type of content that you can't just grep easily, that is the exact point of this)
Another example: You start a new C project, and you are going to reuse code fragments from earlier projects, all the files you need however are in different directories and have no textual relation, nor are they from the same date. they are from the same user, but so are another 10000 files in the same dir tree.
The point is that a commandline tool can be a lot more efficient as long as you can be precise enough about what data it has to work on.
In cases where you cannot, or where as you point out, you are not aware of how to make the selection, it is definitely going to be less efficient.
Also, typing find and verifying if the arguments are indeed correct is not gonna be that much less work then clicking on data in a window and then 2 clicks to denote the beginning and end of your selection, and actually, the visual verification of if your selection is correct is very likely to be easier and more reliable when things become more complex.
It may be, depending on the exact selection you have to make, and in case of a date selection, find might do a good job for you indeed. You didn't get my point tho it seems. Even when there is NO POSSIBLE way except a list outside the computer (ie, on paper, in your head or such) to select the specific files, you can still do so efficiently with a file requester. Yes, you can still do it on a commandline also, and you don't have to bother to tell me how, I have been doing this kind of thing for longer then X windows exists.
The point is not if it is possible, but what is easier and more efficient. Besides, there is the simple saying that a picture says more then a thousand words, and that can be very true for graphical environments versus a text only environment as well.
I'm sorry but untill the day that it actually does anything else then full screen handling of text only ttys (or alternatively, split screen handling), it doesn't deserve the name window manager, regardless of how GNU describes the thing.
Its simple, it can't manage any windows, it can manage terminal sessions. If we'd follow the screen is window manager idea, then the virtual console handler of Linux is also a fullscreen window manager...
I run a stripped down KDE 3 on a p200 with 128mb, no problem whatsoever, so I'd say a k6 300 with 192 mb should be quite fine.
No, you don't want kde to start its kalarmd, kalenderd, kpilotd, knoted and whatever other 'helpers' it starts.. For FreeBSD people out there, there is a kde-lite port which will run without any trouble on such hardware. I bet people came up with a similar package for your favorite Linux distro also?
> Let's assume that there was a default icon for the terminal on the panel. Let's assume an unexperienced user clicked on that button. What would their response be?
Hey... that looks just like a DOS/command prompt window.. wheres that X button to close that thing..
On my freebsd + kde 3.2 desktop, I happen to have gotten a shell icon in the startup tray be default.. hard to find? hmm.. My suggestion would be that the distro you tried sucked due to bad defaults. DOn't blame KDE for that.
> That's my problem with all of the large distros (RedHat/Mandrake/SuSE). They seem to run like pigs, and even if you trim it down to, say Window Maker (my personal fav), it still doesn't run as fast as Slackware w/ WindowMaker or (especially) gentoo w/ WindowMaker.
Or try FreeBSD with X and any window manager.. SLackware, Gentoo and the *BSD distributions all have a much more lean and mean basic setup then rehat and anythign that tries to look like it or was derived from it.
That said, its not too difficult to strip down debian to something similar, and if you are prepared to put in the time and efford, Fedora can eb stripped down to a similar setup as well.
WHen you are not afraid of rebuilding everythuing from scratch, there is a lot more to be gained by optimizing for your specific hardware (strip out all irrelevant drivers, optimize for the specific cpu you have, consider if memory bandwidth might be hindering performance and optimize for size if that is the case etc etc)
Finally, go through your rc.d directory and disable all services that you do not really need (good idea securitywise as well)
Bottomline, the defautl performance of RedHat/Suse/Mandrake may be a lot different from Slack and Gentoo, but it should be quite possible to eliminate the difference if you know what you are doing.
> Do people honestly use file selector windows and drag and drop, and find that more efficient than tab completing in a terminal window? Do I just need more practice?
That depends. When you are going to copy/move a bunch of files that have a name startign with the same chars, a commandline copy/move will be quicker..
If you have a directory with 500 files in there, and you need to copy 30 of them with wildly different names, but created on the same day, it is often easier done and faster with a gui.
I use both a lot, and happen to use KDE 3.2 as window manager/desktop environment at the moment. What KDE offers for integration that I really notice? Well, not much.. but I bet that is because of me using it mostly as an advanced program lauyncher with lots of eye candy.
On the other hand.. at times I am very happy with the integration of file/directory/cvs/pdf/ps/whatever browsing and the support for spell-checking of form input and such.
The main reason for having KDE as default desktop is that I am not the only user of this workstation, and when others use it, they are usually rather happy to find an environment that looks and feels familiar even when they are mostly windows users.
And yeah, I could still give my own account a different window manager but heh. I also 'support' those peopel, so it really helps to use what they are using also.
At times I need speed and memory and I need X.. guess what, I usually just start twm (not even vtwm or such) if I need a window manager at all.. Usually this is for playing games so who cares about a window manager in such a case anyway.
Easy solution (and a good idea for reasons of security as well), have a special game account that gets a very minimalistic desktop and as much machine resources available as possible..
For all practical purposes, my machien has the power to run KDE and OOo and a bunch of browser windows and terminals. Thats what I need for my work usually, and in that KDE is not getting in the way at all.
I disagree, screen is a screen (or actually, tty) manager.
You don't need x-windows to use screen, and in fact most of the advantages of screen are to be gained from a serial terminal or other text terminal only connection.
The infrastructure costs for DSL may be a bit higher initially, but transport costs for data are a lot lower.
In fact, where I live, the one and only problem is that you cannot get DSL without renting a fully functional phone line, but in usage DSL is a lot cheaper then using the phone, to the point that you can get free dsl connections with pre-paid data transfer (which will be a lot cheaper then using a 'free' isp with a charged dialup number and such), upto 8mbit down/1mbit up with no bandwidth/transfer limits for way under $80/month.
I bet it helps tho that overhere (the Netherlands) you can almost always get DSL from a whole range of providers, and in many cases you can get cable internet as well, so there is a lot of competition also.
Not realy, it has been long known that deleting a file doesn't whipe the contents, it just tells the system it can use the space the filed occupied for another file now, and it unlinks the current file from the directory structure.
Actually removing the contents of a fiel is what you need, and tools for that have been around for at least the last 20 years that I remember.
So no, theres little to learn there, wha they seem to want to point out here is that security has a lot more to do with how you think and care about your information then with buying fancy firewalls from Checkpoint and such.
Yes, and I realize the Z4 had this capability. I also tried to point out that the capability is relatively trivial, and eventho the Z3 didn't have the capability, it would not have been impossible to make given there was an output device to actually punch the tape.
Being able to write binary numbers (and as a result a program) to tape is oen thing (a very usefull thing also)
It is no compiler however, and the actual language and compiler he conceived weren't implemented till after his death.
But thanks for making the point I was also trying to make, the inabillity of the Z3 to store a program is not something that is either hard to overcome or anywhere relevant in the discussion about it being a real computer.
To me the lack of branching, and thus the lack of conditional execution of things is a much bigger issue, but reading up on what he made tells me that there were ways to create loops still, so conditional execution is possible tho with a bit of a detour.
The machine was found to be fully Turring Machine complient for as far as limited storage hardware can be, but that was only in 1998.
According to WIkipedia and other sources, he did design the language, but no interpreter or compiler for it was available during his lifetime. I'd say that he didn't make the hardware compiler, he may have conceived the idea tho.
Good point, however, to me this is inherent to the word programmable. It accepts a stored program and can execute it.
Full TM complience? I don't know.. in case of the Z3 the lack of branching is a bigger issue to me then the lack of being able to store a program directy. With branching it would be possible to run a tm emulation on it at the very least I'd think...
When lookign for who was first, we don't look for additional things, we look for the first thing to meet the requirements.
For all I care, beign able to write machinecode to soem form of permanent storage, or even beign able to compile a higher level language into machien code are not part of the basic requirements for a programmable computer.
They may be usefull to compare with other early machines, but completely and utterly irrelevant for the 'who was first' question.
Slashdot Mirror
> Why would it be in Google's interests to do this? Because Google wants the best experience for its users.
Agreed, but a small hint, google is a SEARCH ENGINE, not a HTML correctness filter, just in case you didn't notice.
> And the best experience for users will be to get an XHTML valid webpage which works across any browser, is accessible for the blind and partially-sighted, and works on devices like mobile phones and PDAs.
*lol*
Yeah, that is the theory indeed.
Now if you excuse me, I'm back to reality of 2004, where XHTML is on average bigger then HTML 4.01
and is more complex to parse due to its XML complience.
In 2004, it also turns out to be the case that many PDA browsers understand HTML 3.2 and 4.01 perfectly well, but don't like sites using too much graphics, or sites countign on your screen being 800x600 no matter what.
Such sites that don't work with that are designed badly, and XHTML is a very bad kludge for trying to fix that, the design of such sites needs to be fixed.
So if you are worried about the PDA and Phone browsers, then you need to think again.
For that matter, the broken 3.2 variation that slashdot uses works pretty well on my PDA browser, while quite a few XHTML pages don't. (running PalmOS 4 and either palmscape or blazer)
So... wether HTML 4.01 or XHTML gives a better user experience is somewhat debatable, at least when looking at a real world PDA with 2 real world PDA browsers.
Ah well, have fun with your XHTML campeign, but get it out of your mind that it is relevant to the large majority of users, including those who the petition claims to help.
Yup, cli will be a lot easier for such stuff ;P
XHTMl > HTML 40.1 Strict > HTML 40.1 traditional > ...
Nah, that is not a usefull way to rank things when the content is what you are interested in (as opposed to whatever standard things comply with)
So.. bad plan for as far as I'm concerned.
Ok, lets try to define this in a way that you may have a chance of understanding the point I am trying to make (and stop bothering making your point, I know you can do that and what the advantages of a commandline tool are in many cases, I have been using them for a long time really)
A commandline toool requires that
1. you can consiously express which files you want the tool to deal with in a way the tool understands, and
2. that you are aware of the tool to begin with.
WHen you can write an expression for 1 then all is fine, and when you cannot (for example because the files you need have not a single attribute that a computer can recognize and that you could express in a way that it can recognize, however that is extremely easy to recognize for you visually) then it is really a lot more efficient to have a visual environment for it.
You can try keep missing that point, and really, it is not about wether you prefer a gui or commandline in general, it is about that both can be better for some SPECIFIC cases, and you can count each and every case where a human is better at recognizing the information then a computer to that. And yeah, that may change when someone invents a way to have a computer deal with the specific type of information, but that is not going to change the overall picture.
THen, you are blindly ignoring a few facts here.
The casual user has to take a quick peek at a manual page quite often when usign commandline tools. SOmeoen who uses them often won't for most cases, but someoen who uses them incidentley will.
That makes the commandline very inefficient for everyone who is not going to use it very often.
When your job is related to for example graphics processing, video editing, layout (as opposed to typesetting which can be done very well on the commandline), or anything else where you turn out workign a lot with graphical stuff then you are also very unlikely to spend much time at the commandline.
When you happen to have a computer at home to read email every now and then and browse the web a bit, and write a letter every now and then, then you are not even using it often enough to remember all the details of each and every command, even if you were doing all from the commandline.
Bottomline, the commandline is more efficient in specific cases, a gui is more efficient in other specific cases, and everywhere inbetween, it really depends on who you are which tool works better. WHich one is most efficient in theory is completely and utterly irrelevant for the end-user.
Actually, freebsd comes with a fortune file that does something like that.
;P
But a commandlien is goign to scare quite a few users at least at first. many such users already learned to 'deal' by clicking away windows they don't understand it seems tho, so I don't see a problem of having the icon in an easy to reach place for the quite substantial number of people who do use it often
Oh, and I forgot..
> I think it's critical to learn what tools you have and how to use them correctly before you can really say "this is easier to do here vs. here".
You do realize that the amount of time and efford it takes to learn those tools is a huge factor in determining which one is easier I hope?
Yeah, people only spend a relatively short time learning something compared to the time they spent using it. That would suggest that the learning part is not very relevant, but it is because unless you are using a tool a lot really,there is a bit of recapturing knowledge involved each time you use it. The harder it is to learn a tool, the more difficult the tool will be to use incidentely (as opposed to using it all the time, there it really doesn't matter much)
Last but not least, your statement depends on the definition of the word easy. I bet that if you ask a random group of people out on the street about this, a large majority will agree that the easy to learn thign is in fact easier. It may not be more efficient, but that happens to also not be the same as easy.
> I'm not suggesting that you are not, but the key to being successful (efficient) at the cmd line is to have a certain level of mastery over the tools which are available.
I indeed think that when having used Unix systems before X even existed, I am aware of the find tool, and of tons of other possibilities to locate the specific information that I need from the commandline.
The problem with the commandline is that it is only faster if:
1. you know exactly which files you need and
2. you know how to select all of them.
Your comment is about the second condition, not the first.
Lets give you another example, you have a directory with the last 100+ pictures dumped from your camera, all having numerical names with no relation whatsoever to the content of the pictures yet. Now, you need to pick all pictures from that that relate to a specific subject, and move them into a seperate directory.
I see 2 ways for this.. commandline based, where it will load each picture, and asks if it should move that one also... or gui based with a previewer so you see them directly in your overview and can select the few that match.
(and yeah, I explicitly took a type of content that you can't just grep easily, that is the exact point of this)
Another example:
You start a new C project, and you are going to reuse code fragments from earlier projects, all the files you need however are in different directories and have no textual relation, nor are they from the same date. they are from the same user, but so are another 10000 files in the same dir tree.
The point is that a commandline tool can be a lot more efficient as long as you can be precise enough about what data it has to work on.
In cases where you cannot, or where as you point out, you are not aware of how to make the selection, it is definitely going to be less efficient.
Also, typing find and verifying if the arguments are indeed correct is not gonna be that much less work then clicking on data in a window and then 2 clicks to denote the beginning and end of your selection, and actually, the visual verification of if your selection is correct is very likely to be easier and more reliable when things become more complex.
It may be, depending on the exact selection you have to make, and in case of a date selection, find might do a good job for you indeed. You didn't get my point tho it seems. Even when there is NO POSSIBLE way except a list outside the computer (ie, on paper, in your head or such) to select the specific files, you can still do so efficiently with a file requester. Yes, you can still do it on a commandline also, and you don't have to bother to tell me how, I have been doing this kind of thing for longer then X windows exists.
The point is not if it is possible, but what is easier and more efficient. Besides, there is the simple saying that a picture says more then a thousand words, and that can be very true for graphical environments versus a text only environment as well.
Ah yes, GNU says so so it must be true.
I'm sorry but untill the day that it actually does anything else then full screen handling of text only ttys (or alternatively, split screen handling), it doesn't deserve the name window manager, regardless of how GNU describes the thing.
Its simple, it can't manage any windows, it can manage terminal sessions. If we'd follow the screen is window manager idea, then the virtual console handler of Linux is also a fullscreen window manager...
I run a stripped down KDE 3 on a p200 with 128mb, no problem whatsoever, so I'd say a k6 300 with 192 mb should be quite fine.
No, you don't want kde to start its kalarmd, kalenderd, kpilotd, knoted and whatever other 'helpers' it starts.. For FreeBSD people out there, there is a kde-lite port which will run without any trouble on such hardware. I bet people came up with a similar package for your favorite Linux distro also?
> Let's assume that there was a default icon for the terminal on the panel. Let's assume an unexperienced user clicked on that button. What would their response be?
/command prompt window.. wheres that X button to close that thing..
Hey... that looks just like a DOS
You are right tho I think.
On my freebsd + kde 3.2 desktop, I happen to have gotten a shell icon in the startup tray be default.. hard to find? hmm.. My suggestion would be that the distro you tried sucked due to bad defaults. DOn't blame KDE for that.
> That's my problem with all of the large distros (RedHat/Mandrake/SuSE). They seem to run like pigs, and even if you trim it down to, say Window Maker (my personal fav), it still doesn't run as fast as Slackware w/ WindowMaker or (especially) gentoo w/ WindowMaker.
Or try FreeBSD with X and any window manager..
SLackware, Gentoo and the *BSD distributions all have a much more lean and mean basic setup then rehat and anythign that tries to look like it or was derived from it.
That said, its not too difficult to strip down debian to something similar, and if you are prepared to put in the time and efford, Fedora can eb stripped down to a similar setup as well.
WHen you are not afraid of rebuilding everythuing from scratch, there is a lot more to be gained by optimizing for your specific hardware (strip out all irrelevant drivers, optimize for the specific cpu you have, consider if memory bandwidth might be hindering performance and optimize for size if that is the case etc etc)
Finally, go through your rc.d directory and disable all services that you do not really need (good idea securitywise as well)
Bottomline, the defautl performance of RedHat/Suse/Mandrake may be a lot different from Slack and Gentoo, but it should be quite possible to eliminate the difference if you know what you are doing.
> Do people honestly use file selector windows and drag and drop, and find that more efficient than tab completing in a terminal window? Do I just need more practice?
That depends. When you are going to copy/move a bunch of files that have a name startign with the same chars, a commandline copy/move will be quicker..
If you have a directory with 500 files in there, and you need to copy 30 of them with wildly different names, but created on the same day, it is often easier done and faster with a gui.
I use both a lot, and happen to use KDE 3.2 as window manager/desktop environment at the moment. What KDE offers for integration that I really notice? Well, not much.. but I bet that is because of me using it mostly as an advanced program lauyncher with lots of eye candy.
On the other hand.. at times I am very happy with the integration of file/directory/cvs/pdf/ps/whatever browsing and the support for spell-checking of form input and such.
The main reason for having KDE as default desktop is that I am not the only user of this workstation, and when others use it, they are usually rather happy to find an environment that looks and feels familiar even when they are mostly windows users.
And yeah, I could still give my own account a different window manager but heh. I also 'support' those peopel, so it really helps to use what they are using also.
At times I need speed and memory and I need X.. guess what, I usually just start twm (not even vtwm or such) if I need a window manager at all.. Usually this is for playing games so who cares about a window manager in such a case anyway.
Easy solution (and a good idea for reasons of security as well), have a special game account that gets a very minimalistic desktop and as much machine resources available as possible..
For all practical purposes, my machien has the power to run KDE and OOo and a bunch of browser windows and terminals. Thats what I need for my work usually, and in that KDE is not getting in the way at all.
Oh, and I like konsole and konqueror.
> Err.. screen is a window manager.
I disagree, screen is a screen (or actually, tty) manager.
You don't need x-windows to use screen, and in fact most of the advantages of screen are to be gained from a serial terminal or other text terminal only connection.
Yes, you are missing something completely.
The infrastructure costs for DSL may be a bit higher initially, but transport costs for data are a lot lower.
In fact, where I live, the one and only problem is that you cannot get DSL without renting a fully functional phone line, but in usage DSL is a lot cheaper then using the phone, to the point that you can get free dsl connections with pre-paid data transfer (which will be a lot cheaper then using a 'free' isp with a charged dialup number and such), upto 8mbit down/1mbit up with no bandwidth/transfer limits for way under $80/month.
I bet it helps tho that overhere (the Netherlands) you can almost always get DSL from a whole range of providers, and in many cases you can get cable internet as well, so there is a lot of competition also.
Exactly my point ;P
The changing/removing them in the source seems like a typical application for sed also...
Hmm, noone out there who happens to haev a shell script or such from the 80s that does that already?
sure, and if they found a way to magically know whom to send it to...
Not realy, it has been long known that deleting a file doesn't whipe the contents, it just tells the system it can use the space the filed occupied for another file now, and it unlinks the current file from the directory structure.
Actually removing the contents of a fiel is what you need, and tools for that have been around for at least the last 20 years that I remember.
So no, theres little to learn there, wha they seem to want to point out here is that security has a lot more to do with how you think and care about your information then with buying fancy firewalls from Checkpoint and such.
For as far as I am concerned, they can come back when they have found a non obvious way to make a task list out of TODO comments in source..
For now it sounds like a glorrified form of
grep -r "TODO:' * >tasklist
Or similar.. I bet there is a lot of prior art also..
Why not use SPF? check my weblog for some details as to why this is a much better idea then blacklists or some of the other solutions being proposed.
Yes, and I realize the Z4 had this capability. I also tried to point out that the capability is relatively trivial, and eventho the Z3 didn't have the capability, it would not have been impossible to make given there was an output device to actually punch the tape.
Being able to write binary numbers (and as a result a program) to tape is oen thing (a very usefull thing also)
It is no compiler however, and the actual language and compiler he conceived weren't implemented till after his death.
But thanks for making the point I was also trying to make, the inabillity of the Z3 to store a program is not something that is either hard to overcome or anywhere relevant in the discussion about it being a real computer.
To me the lack of branching, and thus the lack of conditional execution of things is a much bigger issue, but reading up on what he made tells me that there were ways to create loops still, so conditional execution is possible tho with a bit of a detour.
The machine was found to be fully Turring Machine complient for as far as limited storage hardware can be, but that was only in 1998.
According to WIkipedia and other sources, he did design the language, but no interpreter or compiler for it was available during his lifetime. I'd say that he didn't make the hardware compiler, he may have conceived the idea tho.
Good point, however, to me this is inherent to the word programmable. It accepts a stored program and can execute it.
Full TM complience? I don't know.. in case of the Z3 the lack of branching is a bigger issue to me then the lack of being able to store a program directy.
With branching it would be possible to run a tm emulation on it at the very least I'd think...
When lookign for who was first, we don't look for additional things, we look for the first thing to meet the requirements.
For all I care, beign able to write machinecode to soem form of permanent storage, or even beign able to compile a higher level language into machien code are not part of the basic requirements for a programmable computer.
They may be usefull to compare with other early machines, but completely and utterly irrelevant for the 'who was first' question.