I've got a better idea: how about you prove that it can?I already have, Forth can gernerate arbitrary machine code, the result in this case is just machine code. Code is just superfluous.
I might code something like this though, however I think this interface idea is worn out. It has been done and redone, and I haven't seen much improvement. What I really like is Chuck Moores ideas, with his context based interfaces. The screen is used in full and changes depending on the context. The problem may arise when you want to use the result of one context in another context. Perhaps in that case there is way to design around it, only experimentation will tell. User interfaces are far more fuzzy when it comes to proving one way is better than another. Code is a user interface of sorts, which makes it a hard case that Forth is a more efficient interface than other methods. I have come to realize the Forth interface may not be suitable for everyone. I only recommend it as a very good way to program, one which I have experienced first hand, I'll leave it up to the individual to decide if it is right for him/her.
tk's "SHOW ME THE CODE" is a copout. He can't make any point, so he gives me a task to code which I've never had any intention of coding.
If tk actually wants to make a point, why doesn't he show all of us why his pet software can't be implemented in Forth. But really, any counter example would do. This is my chalange to tk. If Forth is not a general purpose tool it should be quite easy to find a computing problem which is cannot be applied to.
tk caught my imprecision, I'll give him that much. That he would use it distort my argument is expected (given his general dishonesty), which reminds to be even more precise in my argument and reasoning.
For the record. I'm not claiming Forth can solve unsolvable problems (halting problem, ect). I'm not claiming Forth can solve impossible problems (Duplicating GNU in 10 bytes).
What I am claiming, is that given a solvable problem on a real machine, Forth can be effectively used (the solution can be expressed concisely in the language), to find the optimal solution to this problem. This is true, since Forth gives precise control over the machine code generated, precise control over storage, and has no restrictions. The optimal solution can first be aproximated in the language. An even closer aproximation can be atained by fine grained control of machine code. The actual optimal solution will most likely never be reached (in any language). Forth is a tool which makes excelent aproximations possible for complex problems. Specifically, it provides the necessary tools of abstraction and information hiding required to make this approximation tractable for a human being. I know of no other language which does this. Lisp also provides the necessary tools of data abstraction, and information hinding. However Lisp does not give fine grained control of storage and machine code. That is perhaps the main seperation between the two.
The examples just show that Forth is useful for programming a DOS-like system.
If this is your honest opinion, I think I have little to discuss with you. I really don't think you wanted me show my code, you just wanted to make a point of some kind or another.
Forth has no limitations. It can be applied to any problem. It can be made as fast or slow, as small or large as the programmer's capability. I don't think any amount of discussion with you will get that across.
tk, it is your loss. I don't care if you ignore Forth. The people who are actually going to do anything of substance with it, are the people who see the potential in the tool, and conceive of new creations before they exist. I don't have to see the 500 line VLSI cad program (or any other program of great complexity) to know it can be created.
Looking at my diary, I see nothing in particular that is offensive. Perhaps my last entry, but that is mostly frustration with this site.
No one has actually pointed out what they find offensive, however indirectly they have expressed offense or perhaps dislike by rating me low.
My low rating is certainly not because my diary is of little interest. There are many on the recentlog with no rating at all, yet their entries will remain.
The recentlog filtering is just a new form of censorship. I find it particularly odd for this to come from a community that suposedly values freedom of speech and openness.
Reply to tk,
meritocracy Advogato is not a meritocracy, it is a popularity contest. It is easy to become a "Master" here and a "10", but you also have to be a politician and play to the crowd. I have a particular disgust for both. Self censorship is required to a great degree unless you want to become censored.
Forth You have not yet pointed to any flaw in Forth. I can show my code, but I don't think it will change your mind or a majority of people here. Forth is for a certain type, an open minded person, one who strives for excelence, honesty and simplicity. Forth does not need a army, it needs a small group of extremely talented individuals. If I reach a small number of these people, I will have been succesful.
Second reply to tk,
Fine I'm game. Here is what I've coded in colorForth:
All are a work in progress, and not necessarily at the peak of Forth's potential. Also realise this is a snap shot. Forth is interactive, it is a process not an instant in time. The drivers in particular, in their static form, do not reflect the power that was used in their creation. One of Forth's stongest features is interactive hardware interfacing.
Hopefully this will help for those who can only think in concrete terms.
All Americans be brave while we send our young men to war. When we send in planes from up high, with our unriveled techonology. When we drop bombs on the Iraqi people unprovoked. All the world be brave, for we Americans wage a war of terror!
The mathematical proof, is still a useful techinique in eliminating most expected bugs. If we prove that a program computes the gcd, we can have little doubt of it's function on a real machine, assuming the input integers are within the machines limits.
I believe that it is possible to design programming languages and runtimes to be much, much simpler.It's already been done, it's called colorForth.
Compatibility with existing designs is also important. Internal consistency can be proved, but compatibility can only be tested. This principle extends to file formats, programming languages, instruction sets, compression algorithms, communication protocols, file systems, all manner of I/O techniques, API's, etc. In other words, most of the things you care about when building a real system.GNU is faith based computing. There is no way any one person check all these things, not even close. You have trust the work of others to a high degree, and also make broad assumptions in creating new work.
response to tk:
It is probably the nature of Forth and also the excelent design of colorForth that I don't worry about standards and compatability so much. For other things, like Unix, as you say the cost may be huge.
In Forth the main thing that can foul things up is the semantics of the operators. As I've pointed out previously, the operators of colorForth are quite evolved. The block format is unlikely to change, it was designed to be extensible, so embeding different types of information in source code is entirely possible. I think this idea is quite neat, you could embed a string from another character encoding, or any other custom data. You could even include the code which extends the compiler inside your application, so there is no dependency.
So short term anoyances are unlikely with colorForth. In the long term, if the system has really changed so much, it is likely the hardware has changed as well. In this case your code probably isn't relevant. It might be best to start from scratch. I've noticed the changes in Chuck's Forth occur with changes in the hardware. The last 30 years have seen many hardware changes. Forth is considered the interface to the machine, so it is quite understandable for the Forth to change as well.
colorForth ignores portability with the result of extreme simplicity. Things are generally easier to write ignoring portability. This comes at the cost of the effort to port the code to different platforms. If the number of platforms is small, the cost is also small. Unix/C in constrast has a gigantic portability apperatus. The C language has complex type system, this probably helps portabillity to a degree, but does not really make C much more portable then macro-less colorForth. To accomidate for C's pitfalls there is also build systems, conditional compilation, and portability layers, more complexity. Furthermore, there is software compatability. C programs are often made compatible with multiple versions of Unix and sometimes Windows, even more complexity. The result is clear. Unix/C programs trade a great amount of simplicity for software/hardware compatability. Now the question is, which way is a greater burden on the programmers? From my experience it has been Unix/C way. Most code I don't even bother looking at, the cost of changing it is much greater than the benifit. On the other hand colorForth has not yet aquired what I consider basic functionality (networking, web, email). It will be intersting to see how well the colorForth method scales. I have a good amount of confidence in it at least.
Executing tree structures
On the pentium, I don't know how good that techinique would work. I'm quite wary of branches on the pentium in my own code. I had an oportunity to use this techinique recently, building a tree structure to decode a huffman coded stream. I decided not to. Jeff Fox used this techinique on a stack machine with good results, and aparently Phil Koopman did too, from the description in his book. When I get around to it, I'd like to read his thesis, which deals with the same subject.
tk, Language standardization is not for the benifit of coders. It is completely for marketing sake. The computing industry wants replacable parts. The last the thing they want is to be dependent on the talent of individuals. If you program in Forth and you leave, they believe replacing you with a "Forth programmer" will be just as good. But this is only an illusion, good programmers can program in any language, and can pick up new ones quickly. Some Forths, like colorForth, could be picked up within a day given proper training, even for programmers with no prior Forth experience. Language standardization only serves to gloss over differences of programmers and languages.
The Forth standard, and probably all language standards, was made to apeal to this industry. The ironic thing is that now that Forth has a standard it probably used less overall, and when used lacks many of the benefits of the original.
While I make no claims what real Forth is. colorForth is the one the Forth that got my attention. Previously, I did not have much interest in Forth, even though Forths are readily available for GNU. This makes me believe Forth is not just a superficial language, a syntax, but there is much more. There is a philosophy and also an aesthetic for simplicity and elegance. The virtual machine, that was avoided in the ANSI spec, is the embodiment of Forth machine philosphy. These machines are not only ideal for the execution of Forth, but show advantages for Rule-based systems and functional programming. colorForth seems well in keeping with the spirit and philosophy of Forth. It is encouraging that the lastest effort from the creator is, after many years, colorForth, and not "Visual Forth.NET Development Studio 2000 Professional Edition".
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!