Older blog entries for mslicker (starting at number 35)

28 Sep 2002 (updated 28 Sep 2002 at 18:17 UTC) »
tk's "SHOW ME THE CODE" is unreasonable. Why? With Forth I'm discussing a general purpose tool, one which can be applied to any problem. Must I recode everything that has ever been coded to prove this point? This is impossible. For one there are an infinite number of problems a person using Forth would want to address. For another, I would have a devote all my time to this task with no hope of finishing.

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.

--- Update

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.

27 Sep 2002 (updated 27 Sep 2002 at 20:25 UTC) »
tk wrote,
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.

--- Update

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.

27 Sep 2002 (updated 27 Sep 2002 at 04:23 UTC) »
Zaitcev: I think ratings say quite bit about this social group. Prominently, people here would rather filter out what they disagree with, than engage in a discussion.

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,

The code

Fine I'm game. Here is what I've coded in colorForth:

Heapsort
Keyboard driver
Mandelbrot Set
Matrox video driver
Jpeg image decoder

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.

20 Sep 2002 (updated 20 Sep 2002 at 22:15 UTC) »
bgeiger, My response was a poem, not a polemic. I think have very littte to discuss here with anyone. Perhaps when raph finishes implementing BlandTech2000 he can also implement account removal, so I can disassociate myself from this insipid site.

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!

15 Sep 2002 (updated 16 Sep 2002 at 03:10 UTC) »
mbp, Thanks for your last couple of posts. I am reminded that Computer Science is much closer to Physics than Mathematics. Machines are bound by physical reality, and while mostly under our control, are subject to unexpected events which makes "proof" unattainable.

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.

raph, writes:

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.

--- Update

graydon, Actually that was a quote of raph. My apology for the confusion, my quotation style was ambiguous.

response to tk:

Forth

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.

Portability

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.

Forth and standardization

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".

Formal methods and Dijkstra

I read through many of Dijkstra's papers recently. I have to agree with much of what he has said.

The skills to write good mathematical proofs and good programs are the same. And also, from experience, my math classes have been far more valuable than my computer science classes (with some exceptions). He said computer science students should be diciplined in mathematics and I think he is right.

Also he has said some things about elegance and simplicity. In math generally the more elegant and simple proofs are the ones that are taught. One math teacher of mine would give solutions. Somtimes people would turn in ten pages of proofs for an assignment. When he handed out his solutions the proofs fit on exactly one page. Programming problems also admit many solutions, and we should try to find the most elegant simple method of solving them.

Formal methods could be useful in programming, but not as a mechanical device to automatically check the correctness of your program. The key I think is developing highley modular programs. It is easy to check the correctness of a short function, you can even do it mentally. When functions get long, that is when you must get out the pencil and paper and follow each step.

Also the simpler a program is, the easier to check it's correctness. Often the problem we are addressing is one of our own choosing. Redefining the problem can often lead to simpler programs, and ones which are much easier to verify. This is a tremendous advantage which is often ignored in writing programs.

tk

Glad to stop. Our debate was turning more into an argument. I like debates, but not arguments.

Also I like to say that I don't care what programming language people use. I would much rather create than criticize. My remarks on C are mostly prompted by current attempts to parse it, which have taken far more work than I would like.

tk I await you remarks reguarding colorForth.

You seem to use whatever version of C suits you argument. K&R C and standard Cs do not have integration of machine code. Therefore languages like GNU C must implement them as a hack extention. This is not what I call clean integration. colorForth allows machine language integration by design. This is the whole purpose of the colorForth macros.

On compactness, fine let us choose a implementation then compare. I choose colorForth, I await you choice of C implementation.

On interactive development, I didn't state that colorForth has a debugger. Interactivety is achieved through a extremely tight edit/compile/test cycle, and entry points to every word.

Where did I seperate a computer language from it's implmentation? Look at ObjectiveCaml for a typeded infix language which is much cleaner than C, and even beats C on occasion in performace.

Please show me the abuguity in the colorForth specification. Are you comparing this to C? Many paragraphs of the C specification say the handling of a certain construct is implementation defined, how much more ambiguous can you get?

I have some advice for you tk, try implementing a parser for the C language. You said this was "quite tractable", lets see it. I think if you did this, you might actually understand how bogus the design of the C language is. You might also understand my abhorrence for it.

For me, I try to avoid design disasters where I can. I try to avoid projects which have such a great inertia. I like software that is small, fast, and nimble; changable. Software should be built to last, but not built to stay. Free software has many examples of software built to stay. Mozilla, gcc, Linux, Gnome, KDE, are all built to stay, if they last it is not because of design elegance but because they are unmovable.

My quote of the Tao:

In pursuit of knowledge,
every day something is added.
In the practice of the Tao,
every day something is dropped.
Less and less do you need to force things,
until finally you arrive at non-action.
When nothing is done,
nothing is left undone.

26 older entries...

New Advogato Features

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!