Slashdot Mirror


Chuck Moore Holds Forth

A little while ago you asked Forth (and now colorForth) originator Chuck Moore about his languages, the multi-core chips he's been designing, and the future of computer languages -- now he's gotten back with answers well worth reading, from how to allocate computing resources on chips and in programs, to what sort of (color) vision it takes to program effectively. Thanks, Chuck!

FFP, Combinator Calculus and Parallel Forth
by Baldrson

In his 1977 Turing Lecture, John Backus challenged computists to break free of what he called "the von Neumann bottleneck". One of the offshoots of that challenge was work on massive parallelism based on combinator calculus a branch of mathematics that is far closer to Forth's formalism than parameter list systems (which are more or less lambda calculus derivatives).

The prolific Forth afficionado Philip Koopman did some work on combinator reduction related to Forth but seems not to have followed through with implementations that realize the potential for massive parallelism that were pursued in the early 1980s by adherents of Backus's Formal Functional Programming paradigm. Given recent advances in hierarchical grammar compression algorithms, such as SEQUITUR, that are one step away from producing combinator programs as their output, and your own statements that Forth programming consists largely of compressing idiomatic sequences, it seems Backus's original challenge to create massively parallel Formal Functional Programming machines in hardware are near realization with your new chips -- lacking only some mapping of the early work on combinator reduction machines.

It is almost certainly the case you are aware of the relationship between combinator reduction machines and Forth machines -- and of Backus's challenge. What have you been doing toward the end of unifying these two branches of endeavor so that the software engineering advantages sought by Backus are actualized by Forth machines of your recent designs?

Chuck Moore: What can I say? Backus did not mention Forth in his lecture. He probably didn't know of it then. Yet Forth addresses many of his criticisms of conventional languages.

He thinks a language needs or benefits from a formal specification. I grew up worshiping Principia Mathematica 'till I learned how Goedel refuted it. The result is that I distrust formal representations. For example, the ANSII Forth standard does not describe Forth, but a language with the same name.

Yes, I am struck by the duality between Lisp and Lambda Calculus vs. Forth and postfix. But I am not impressed by the productivity of functional languages. Even as research tools, they have failed to live up to their promise. By that I mean to do something with computers that I couldn't do more easily in Forth.

I designed the memory for the c18 to occupy the same area as the processor. This means small, fast and smart. c18 can respond to a bus request by fetching from its memory, accessing off-chip or performing a calculation. The 25x avoids the von Neumann bottleneck by making up to 27 memory accesses at the same time (2 off-chip). And its multiple buses do not substitute a network bottleneck for a memory one.

Standard code will be in the ROM of each computer. How this is customized in RAM and the computers assigned tasks is left to the ingenuity of the programmer, not a compiler. Automatically generated or factored code has never impressed me. Nor has automatic place and route for circuit boards or silicon. They are both an order-of-magnitude from human performance. Because humans understand the problem, judge the results and cheat as required.

Marginalizing of the blind
by Medievalist

When I built my first Internet node, the web did not yet exist, and one of the amazing things about the Internet was how friendly it was to the blind.

Now, with some computer experts estimating that over 50% of the Internet is incomprehensible to braille interfaces, and most computer operating systems devolving to caveman interfaces ("point at the pretty pictures and grunt") we seem to be ready to take the next step - disenfranchising the merely color-blind.

I realize that colorforth is not inherently discriminatory, in that there are a great many other languages that can be used to do the same work. The web is also not inherently discriminatory, because it does not force site designers to design pages as stupidly as, for example, Hewlett-Packard.

Would you care to comment on the situation, speaking as a tool designer? How would you feel if a talented programmer were unable to get a job due to a requirement for colored sight?

CM: I'm amazed at how effective blind programmers can be. I rely so strongly upon seeing the code that it's hard to imagine listening to it. Yet I know it can be done. Not being color-blind, it's hard to appreciate the degree of information loss. But it's less than being blind.

My goal is to develop tools that augment my abilities. If others can use them, fine. It would be foolish to lose an opportunity to explore or excel just to conform to some equalitarian philosophy. Too often our culture seeks the lowest common denominator.

20-20 vision is required for fighter pilots. I have no qualms about requiring color vision for programmers. Everyone does not need to be a programmer.

But in fact, color is merely a property of words that helps to distinguish them. As is intensity, size, font, volume and tone. I'm sure colorForth will be translated into these other representations. I, myself, will be exploring spoken colorForth. (As soon as I can decipher PC sound cards.)

Massively Parallel Computing
by PureFiction

The 25X system reminded me of IBM's Blue Gene computer, where a large number of inexpensive CPU cores are placed on a single chip.

The biggest problem in dealing with a large number of small cores lies in the programming. I.e. how do you design and code a program that can utilize a thousand cores efficiently for some kind of operation? This goes beyond multi-threading into an entirely different kind of program organization and execution.

Do you see Forth (or future extensions to Forth) as a solution to this kind of problem? Does 25X dream of scaling to the magnitude that IBM envisions for Blue Gene? Do you think massively parallel computing with inexpensive, expendable cores clustered on cheap dies will hit the desktop or power-user market, or forever be constrained to research?

CM: Forth is a massively pragmatic language: do whatever you can to solve a problem. Its strength is in the ease of violating whatever rules it has. The 25x is similarly pragmatic. I don't know how to program it yet, but I'm confident I can. It's just another level of factoring.

The parallelism provided by the 25x has a different slant from other parallel architectures. The computers are not identical. I expect many will have different ROM and different interface to the real world. This asymmetry is a powerful clue as to how applications will be factored.

A 10x10 array of 25x chips is an easy board to build. At 50 Watts, it needs as much power as a notebook. That's 2500 computers providing 6M Mips. I can't imagine programming them any other way than Forth.

The advantage of Forth in this kind of context is that it scales. Forth is the machine language, Forth is the high-level language, Forth is the task-control language, Forth is the supervisory language. Each of these has a different vocabulary, but they share syntax, compiler and programmer skills.

Back to the array of 25x chips. Each chip could be on a vertical and horizontal serial bus with 10 others. A half-duplex bus requires a computer to manage, so that accounts for 200 computers. Now whatever the application, data must be provided. Say 1GHz Ethernet. Data (and program) is received, distributed and crunched. The assignment and coding of computers follows the data flow. Results are routed back to Ethernet, or displayed or whatever. It's a nice programming problem, well within the ability of a human to organize.

Will this ever reach the mass market? I don't know.

The direction of 25x Microcomputer...
by Midnight Ryder

The 25x concept looks like it could really a damned interesting idea. But one of the questions in my mind is where you want to head with it? Is this something that is to be used for very specialized research and scientific applications, or is this something that you envision for a general 'desktop' computer for normal people eventually?

Secondly, if you are considering the 25x for a desktop machine that would be accessible by people that aren't full-time geeks, what about software? Forth is a lost development art for many people (It's probably been 10 years since I even looked at any Forth code) and porting current C and C++ application would be impossible - or would it? Is there a potential way to minimize the 'pain' of completely re-writing a C++ app to colorForth for the 25x machines, which could help to speed adoption of a platform?

CM: At this stage the 25x is a solution looking for a problem. It's an infinite supply of free Mips. There's no obligation to use them all, or even very many. But they can effectively be used to eliminate hardware. To bit-bang what would otherwise need a controller. So if you want video or audio or radio or ...

The first applications will doubtless be embedded. These offer greater volume, less software and less market resistance than a general-purpose computer. I see 25x reaching the desktop as dedicated appliances rather than universal golems.

I'm not interested in recoding C applications. My experience indicates that most applications are hardware-dependent. The 25x is as large a change in the hardware environment as I can imagine. This changes the program so much it might as well be rethought and recoded. The most efficient way to do that is Forth.

Forth is a simple, interactive language. Its learning curve is steep with a long tail. You can be productive in a day/week. This depends only on how long it takes to memorize pre-existing words. Good documentation and management helps mightily. I'd rather train programmers than fight code translators.

That said, there are those who look at the mountain of existing applications and want to mine it. C to Forth translators exist and with some pre/post editing could produce code for the c18 core. How to distribute the application among 25 tiny computers would be a good thesis.

Quick question
by jd

I have often conjectured that multi-threaded processors (ie: processors that can store multiple sets of internal states, and switch between them) could be useful, as the bottleneck moves from the processor core to communications and dragging stuff out of memory.

(If you could microcode the "instruction set", all the better. A parallel processor array can become an entire Object Oriented program, with each instance stored as a "thread" on a given processor. You could then run a program without ever touching main memory at all.)

I'm sure there are neater solutions, though, to the problems of how to make a parallel array useful, have it communicate efficiently, and yet not die from boredom with a hundred wait-states until RAM catches up.

What approach did you take, to solve these problems, and how do you see that approach changing as your parallel system & Forth language evolve?

CM: The 25x could implement a multi-thread application nicely indeed. Except that most applications expect more memory that a c18 core has. Whereupon memory remains the bottleneck.

It's important to choose problems and solutions that avoid using off-chip memory. Even so, with 25 computers to support, I expect that every memory cycle will be utilized. The computer controlling memory can be smart about priorities and about anticipating requirements. For example, it could guarantee enough access to support display computers.

And the nice thing about memory-mapped communication is that a computer need not be aware of its environment. It's an ordinary Forth program accessing data asynchronously. Delays are invisible, as is synchronization. Of course, due care is required to avoid lock-up loops.

These conjectures are fun. But in a year we'll have real applications to review. And a much better appreciation of the advantages and drawbacks of so many tiny computers.

Programming languages...
by Midnight Ryder

This one would probably require a bit more time to answer than you probably have available, but a quick rundown would be cool: Where do you see programming languages headed -vs- where do you think they SHOULD be headed?

Java, C#, and some of the other 'newer' languages seem to be a far cry from Fourth, but are languages headed (in your opinion) in the proper direction?

CM: I've been bemused with the preoccupation of new languages with text processing. I've been accused of not providing string operators in both Forth and colorForth. Indeed, I haven't because I don't use them. Editing a file to pass on to another program never struck me as productive. That's one reason I chose pre-parsed source, to break the dependence upon strings and text processors.

Languages are evolving, as evidenced by the new ones that arise. But as with natural evolution, the process is not directed. There is no goal to approach nor any reward for approaching it. But whatever progress you might perceive, I don't. New languages seem only to propose new syntax for tired semantics.

These languages are all infix. Which is extraordinarily clumsy for anything but arithmetic expressions. And even those are comfortable only because we learned them in Algebra 101. Do you remember the learning curve?

Does everyone really think that 50 years into the computer age we have hit upon the ultimate language? As more and more C code accumulates, will it ever be replaced? Are we doomed to stumble over increasingly bloated code forever? Are we expecting computers to program themselves and thus save civilization?

I'm locked in the Forth paradigm. I see it as the ideal programming language. If it had a flaw, I'd correct it. colorForth uses pre-parsed source to speed and simplify compilation. This solves a non-problem, but it's neat and worth exploring. At least it proves I haven't gone to sleep.

What about memory protection?
by jcr

From the web pages, I don't see any mention of access control.

Can this processor be used in a multi-user, general-purpose mode?

CM: If you had a chip, you'd physically control access to it. It doesn't make sense for another person to share your chip. He can get his own. Certainly an individual c18 has too little memory to multi-task. And I doubt 25 computers could run 25 tasks.

But the 25 computers can certainly perform more than one task. They have to share resources: communication buses, off-chip memory and interfaces. Access is negotiated by the computer in charge of the resource. There is no hardware protection. Memory protection can be provided by the access computer. But I prefer software that is correct by design.

Communication with other computers, via internal or external buses, is subject to the usual problems of scheduling, routing and authentication. Internally, at least, my goal is to minimize delay rather than attempt protection. I anticipate spectacular crashes while software is developed. (Have you ever crashed 2500 computers?)

Where is forth going?
by JanneM

I learned forth early on in my programming career; it was very memory and CPU efficient, something that was important on early microcomputers. It was also a great deal of fun (though far less fun to try and understand what you wrote a week earlier...). Today, even small, cheap microcontrollers are able to run fairly sophisticated programs, and it is far easier to cross-compile stuff on a 'big' machine and just drop the compiled code onto the development board.

Forth has (in my eyes) always been about small and efficient. Today, though, embedded apps are more likely to be written in C than in forth, and the "OS as part to the language" thing isn't as compelling today as it was in the eighties. Where is forth being used today, and where do you see it going in the future?

CM: Forth is being used today as it always has been. In resource-constrained applications. I think they will always exist. I'm creating some with the tiny c18 computers in the 25x. I imagine molecular computers will be limited when they first appear.

Personally, I don't mind losing a mature market that can afford abundant resources. Such applications aren't as much fun. But Forth isn't restricted to small applications. Even with huge memories and fast processors, small, reliable programs have an advantage.

The major project cost has become software, to the dismay of managers everywhere. On-time, bug-free software is the grail. Forth doesn't guarantee it, but sure makes it easier. Will this ever be convincingly demonstrated? Will management ever value results over procedures?

The currently popular language is selected by uninformed users. The only thing in favor of such democratic choice is that it's better than any other. But why would anyone want to debug 1M lines of code instead of 10K?

What's the next Big Computational Hurdle?
by DG

Now that sub-$1k computers are running in the GHz range, it seems that all the computational tasks on a common desktop system are not processor-bound.

3D, rendered-on-the-fly games get well over 30 frames per second at insanely high resolutions and levels of detail. The most bloated and poorly-written office software scrolls though huge documents and recalculates massive spreadsheets in a snap. Compiling the Linux kernel can be done in less than 5 minutes. And so on.

It seems that the limiting speed of modern computers is off the processor, in IO. What then, do you forsee coming down the pike that requires more processor power than we have today? What's the underlying goal you intend to solve with your work?

CM: Memory is cheap. I don't mind wasting memory as long as it's not full of code that has to be debugged.

Likewise, Mips are cheap. The trick is to find productive ways to waste them. A Pentium waiting for a keystroke isn't very clever.

So here's a huge pool of Mips. What can you do with them? Voice recognition comes instantly to mind. Image recognition close behind. The brain deploys substantial resources to these tasks, so I suspect a computer must.

IO is indeed a bottleneck, but not in principle. If you can't get data from the camera to the computer, combine them. Put the image recognition algorithms in the camera. Analyse, reduce, compress data at the source. Meanwhile, it helps to have multiple paths off-chip.

revolutionary
by rnd

What is the most revolutionary (i.e., it is scoffed at by those in control/power) idea in the software industry today? Explain how this idea will eventually win out and revolutionize software as we know it.

CM: Forth! But then I haven't been out looking for revolutionary ideas. I like the phrase Baldrson used above: compressing ideomatic sequences. If you do this recursively, you obtain a optimal representation. I see no way to get a more compact, clear, reliable statement of a problem/solution.

Forth clearly revolutionizes software as most know it. It could lead to efficient, reliable applications. But that won't happen. A mainstay of our economy is the employment of programmers. A winnowing by factor 100 is in no one's interest. Not the programmers, the companies, the government. To keep those programmers busy requires clumsy languages and bugs to chase.

I don't have to be glib or cynical. Those are facts of life. Society must cope with them. But I don't have to. Nor you. There are niches in which you can be creative, productive, inspired. Not everyone can be so lucky.

Forth as intermediate language
by Ed Avis

Many high-level languages compile into C code, which is then compiled with gcc or whatever. Do any use Forth instead? I understand Forth is a stack-based language: doesn't that present problems when compiling for CPUs that mostly work using registers?

CM: I remember my shock at learning that Fortran compiled into Assembler, that then had to be assembled. A language that can be translated into another is clearly unnecessary. Truely different languages cannot be translated: C into Lisp.

Forth would make a fine intermediate language. But why have an intermediate language? It introduces another layer of confusion and inefficiency between the programmer and her computer. Macros were invented to support compiling directly to machine code.

Stacks are a compiler-friendly construct. Every compiler has to use one to translate infix notation to postfix. If this stack solution has to be assigned to registers, it's an extra step. Forth uses stacks explicitly and avoids the whole subject.

Register-based CPUs have more problems than just the complexity of their compilers. Their instructions must contain register addresses, which makes them longer and programs bigger. And it is rare that every register can be used in every instruction.

Moreover registers need to be optimized. After assigning system registers, performance depends on how well the remaining registers are handled. Compilers can optimize infix expressions better than humans. But such expressions are no longer the preferred means of doing arithmetic. DSPs and super-computers integrate difference equations.

Design guidelines encourage code with many subroutine calls each with only a few arguments. This is the style Forth employs. But it plays havoc with optimization, since register usage must be resolved before each call. So apart from being unnecessary and difficult, optimization has no effect on good code.

211 comments

  1. NEXT anyone by eadint · · Score: 0

    whatever happened to next i though that was going to be the end all . 100% object oriented. ect ect. why not just work with whats there. im tired of having to scramble and learn new languages. hey why don we make perl OOP i mean true OOP not that bolted on crap. linux G4 perl/OOP NEXT hey what a deal or maybe clawhammer if they can get their act together

  2. The Blind by Kallahar · · Score: 3, Interesting
    "Now, with some computer experts estimating that over 50% of the Internet is incomprehensible to braille interfaces, and most computer operating systems devolving to caveman interfaces ("point at the pretty pictures and grunt") we seem to be ready to take the next step - disenfranchising the merely color-blind."

    This brings me back to the BBS days. One of the best people in the area was a blind judge. He used a text->speech program which allowed him to do everything on the BBS that everyone else did. Since the BBS's were all text-only anyway the interface was easy. Nowadays we have so many sites that are design-centric that I can't see how people with disabilities get around.

    I always strive to keep my sites simple and clean (like slashdot) so that the site can be more easily used by anyone, anywhere.

    This isn't to say that flash, etc. shouldn't exist, but I don't think that they belong on a business-oriented site.

    Travis

    1. Re:The Blind by reynaert · · Score: 1
      I always strive to keep my sites simple and clean (like slashdot) so that the site can be more easily used by anyone, anywhere.

      I can tell you never looked at Slashdot in Lynx.

    2. Re:The Blind by crucini · · Score: 2

      I find slashdot highly usable in Lynx. What is your specific complaint?

    3. Re:The Blind by Anonymous Coward · · Score: 0
      Well, in the old days of HTML, design and markup were one and the same. I don't see that Slashdot has progressed beyond that. Not that I'm like those WaSP assholes - of course the option should be kept, but the Slashdot does use older style markup that by its' nature is design-centric. They use I tags rather than Q tags. Slashdot hasn't used a stylesheet, ever.

      (and yes, I could select the light version and use my own stylesheet - but the markup is still using font tags and I and B which makes it difficult for me to override)

  3. Re:Stephen King, author, dead at 54 by dmorin · · Score: 0, Offtopic

    No, this guy posts this a few times a day. Has been doing it for weeks. I don't know why he thinks it's funny.

  4. I imagine it this way by bliss · · Score: 0

    Being blind really ruines most of your life. At least from what I am able to determine. Generally I can't see how you can do anything but stay on disability without some really magical help

    --
    The death of one man is a tragedy; the death of a million is a statistic --Joseph Stalin
  5. Incomprehensible content by heatsink · · Score: 5, Funny

    "Now, with some computer experts estimating that over 50% of the Internet is incomprehensible to braille interfaces"

    Isn't this because over 50% of the Internet is porno?

    1. Re:Incomprehensible content by kaxman · · Score: 1

      It has to be way more than that! It's everywhere, in every single part of the internet!

      --
      Everyone on slashdot has a journal.
    2. Re:Incomprehensible content by Ghoser777 · · Score: 2

      That, and probably because half of them also don't look right in links. I can't imagine how difficult it must be for a blind person to try to navigate sites with multiple frames and poor info ordering. I mean, there's no big candy-coated indicators for braile users to look for when they're scanning a website via a braille interface. But web designers probably don't take this into account because their managers usually just want to see cool designs that they can see and that are easy to navigate for them (aka usually people who can see).

      F-bacher

      --
      James Tiberius Kirk: "Spock, the women on your planet are logical. No other planet in the galaxy can make that claim."
    3. Re:Incomprehensible content by jd · · Score: 2

      Probably right. In which case, it's incomprehensible to any device based on logic.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    4. Re:Incomprehensible content by Anonymous Coward · · Score: 1, Funny

      ?

      Why can't logical devices comprehend porn? The reason people look at porn is because it turns them on. We'll define this as "good." Then it's only logical to conclude that if a logical device understands what's good, then it can understand porn.

    5. Re:Incomprehensible content by Anonymous Coward · · Score: 0

      Isn't this because over 50% of the Internet is porno?


      Maybe this is a shortcoming of the braille display hardware, pr0n should be translatable to a tactile display.

    6. Re:Incomprehensible content by battjt · · Score: 1

      I have a blind friend with a subscription to Playboy. It is delivered in braile.

      Joe

      --
      Joe Batt Solid Design
  6. Re:Stephen King, author, dead at 54 by kaxman · · Score: 0, Offtopic

    Well. What the hell am I supposed to do now??? He didn't finish his goddam dark tower series. I'm sad, but dammit... grrrrrr...

    I really enjoyed many of his books, but he should have focused on his, imho, best series of books.

    kaxman

    --
    Everyone on slashdot has a journal.
  7. Forth is the Language of Robot AI by Mentifex · · Score: 1

    The language that Chu Moo created for the control of telescopes in astronomy became so valuable for use in personal robotics that Mind.Forth for robots has resulted at the http://sourceforge.net/projects/mind/ website where more than three hundred Open Source AI projects are rushing to introduce real artificial intelligence. Mind.Forth has a companion version in MSIE JavaScript at http://mind.sourceforge.net/ -- with Tutorial and hard-copy Troubleshoot print-out options.

  8. Chuck is not going to be a useful visionary by watanabe · · Score: 3, Insightful
    Chuck is an unabashed Forth zealot. I guess this is fine; I'm sure Forth is great. But, I get the feeling he is so focused on the details (Commenting that programs don't need to read text to do something useful? Hello? How was this slashdot interview pulled from a database and sent to my web browser?) that I feel like reading stuff from him will only be interesting if I want to know something about Forth. This, compared to Neal Stephenson, say.


    I even get the impression that Chuck would be happy that I noticed this about him. It just makes me think that there will be no revolution coming from the Forth camp. Which, I hadn't really expected, anyway. But, I'll cross it off my list of possible revolution starters, anyway.

    1. Re:Chuck is not going to be a useful visionary by hearingaid · · Score: 2

      Linus is an unabashed Linux zealot. I guess this is fine; I'm sure Linux is great. But, I get the feeling he is so focused on the details that I feel like reading stuff from him will only be interesting if I want to know something about Linux.

      Yes, the comparison applies. Chuck Moore wrote Forth in the beginning. Of course he loves it: writing a programming language (at least a useful one) is work, and you wouldn't do it except because you really, really wanted to.

      Put it another way: If Dennis Ritchie were to be interviewed on /. would you be shocked if the C programming language were mentioned from time to time?

      --

      my old sig used to be funny, but then slashcode ate it and now it's not funny anymore

  9. Compression by donglekey · · Score: 4, Insightful

    One of the things that can never get enough power is compression. Right now the next generation of image and video compression looks like JPEG 2000 and Motion JPEG 2000. I have tested it and it seems like a miracle compression, it consistently works at least 4x better than jpeg compression. Apply that to video and you have something incredible but very VERY expensive. He said it was a solution looking for a problem, and there it is. I think that HDTV video disc standards are leaning toward mpeg4 which would be a mistake in my opinion. Motion JPEG 2000 would be much more forward thinking if someone could pull it off. I say go for it Chuck.

    More immediatly, using a 25x chip in a digital camera to compress large pictures to JPEG2k could save lots of space and more importantly, quality. Seems like a perfect mariage to me!

    1. Re:Compression by cruelworld · · Score: 2

      Mpeg4 is not Divx!!

      MPEG4 is an incredibly complicated scene graph compression scheme. Currently people are merely using it a transport stream format with mpeg1 video compression.

      A real mpeg4 encoder has to be content aware, and right now that's beyond our abilities(and hardware).

    2. Re:Compression by donglekey · · Score: 1

      Can you give me some links to read? I guess I have made this generalization and I am sure others have as well.

    3. Re:Compression by Christopher+Thomas · · Score: 2

      One of the things that can never get enough power is compression. Right now the next generation of image and video compression looks like JPEG 2000 and Motion JPEG 2000. I have tested it and it seems like a miracle compression, it consistently works at least 4x better than jpeg compression. Apply that to video and you have something incredible but very VERY expensive. He said it was a solution looking for a problem, and there it is.

      Actually, you'd almost certainly be better off just building dedicated hardware optimized for JPEG/MPEG compression, like you already see in the hardware decoder cards for DVD. These either implement common computation-intensive parts of the CODEC algorithms in hardware, or use DSPs to implement them in firmware using hardware that's geared towards signal processing.

      Running on a general-purpose device, even a parallel one, won't get you these benefits.

    4. Re:Compression by plastik55 · · Score: 2
      Actually, you'd almost certainly be better off just building dedicated hardware optimized for JPEG/MPEG compression, like you already see in the hardware decoder cards for DVD. These either implement common computation-intensive parts of the CODEC algorithms in hardware, or use DSPs to implement them in firmware using hardware that's geared towards signal processing.

      Running on a general-purpose device, even a parallel one, won't get you these benefits.

      Uhm, a DSP is a general-purpose parallelized device.

      It's not like their adders and multipliers are any faster then those in modern processors. The only real difference between a DSP and a CPU is that DSPs have typically embraced parallelism in hardware (VLIW, multiple cores on a chip, pipelining) to a greater extent than contemporary CPUs, at the necessary expense of backwards compatibility with earlier models.

      25x looks to me like it could be a GREAT chip to do common DSP tasks like filtering or block discrete cosine transforms on.

      --

      I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!

    5. Re:Compression by tjb · · Score: 1

      As a DSP programmer, I'm inclined to agree.

      However, I haven't looked at the 25x that closely (basically, just what was in this article). The big bottle neck for alot of DSP tasks (most notably, filtering), is that you need a ton of on-chip, non swappable memory, because an adaptive FIR requires being able to read and write lots of coefficients very quickly.

      If they have enough on-chip memory to support large coefficient tables and enough on-chip code space to run the code at full speed, they could indeed be very useful in this regard. If not, perhaps a licensed version giving these capabilities could become widely used.

      Tim

    6. Re:Compression by Christopher+Thomas · · Score: 2

      Running on a general-purpose device, even a parallel one, won't get you these benefits.

      Uhm, a DSP is a general-purpose parallelized device. It's not like their adders and multipliers are any faster then those in modern processors. The only real difference between a DSP and a CPU is that DSPs have typically embraced parallelism in hardware (VLIW, multiple cores on a chip, pipelining) to a greater extent than contemporary CPUs, at the necessary expense of backwards compatibility with earlier models.

      We seem to be using the term "general-purpose" differently.

      The 25x chip is an array of more-or-less independent cores, optimized for a general-purpose instruction set and geared towards SISD integer instructions, with each processor running its own instruction stream with its own control flow.

      A generic DSP chip is a single-instruction-stream core optimized to do things like dot products, multiply-accumulates FFTs, and/or various other signal-processing-specific operations in parallel (SIMD-style) in hardware.

      Ask a DSP processor to play chess, and it'll crawl.

      Ask it to perform frequency-domain feature extraction or to do geometry transformations for rendering, and it'll work at blinding speed, because much of the control flow and register shuffling and memory shuffling that you'd have for these tasks with a general-purpose chip doesn't have to be performed.

      A DSP's instruction set and chip hardware are geared towards a narrow class of applications (signal processing), and as a result it does these tasks (and pretty much only these tasks) extremely well.

      (Note to purists: I'm considering a stream of VLIW instructions to be a stream of "single" instructions for purposes of this thread, because you don't have independent control flow in the multiple instructions per clock being executed. This is an arbitrary terminology distinction on my part.)

    7. Re:Compression by plastik55 · · Score: 2
      The 25x chip is an array of more-or-less independent cores,

      You mean like Texas Instrument's TMS320C80 DSP?

      optimized for a general-purpose instruction set and geared towards SISD integer instructions, with each processor running its own instruction stream with its own control flow.

      So it seems like it can do everything a DSP can vis a vis hardware-level parallelism, plus some things that are hard for SIMD-style DSPs. Which is faster, 25 SISD processors sharing an address space, or one SIMD processor which can operate on 25-ary vectors? Multiple SISD cores seem to win, I think, though they may be harder to program for.

      Ask a DSP processor to play chess, and it'll crawl.

      The main bottleneck in chess program is a game tree search. Tree searches are inherently parallelizable, and there are, in fact, very good algorithms for doing them on SIMD processors.

      --

      I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!

    8. Re:Compression by Christopher+Thomas · · Score: 2

      So it seems like it can do everything a DSP can vis a vis hardware-level parallelism, plus some things that are hard for SIMD-style DSPs. Which is faster, 25 SISD processors sharing an address space, or one SIMD processor which can operate on 25-ary vectors? Multiple SISD cores seem to win, I think, though they may be harder to program for.

      I don't see how you support this conclusion.

      I agree that multiple SISD cores are more _flexible_. That isn't the issue.

      If you're doing, say, a dot product on multiple SISD cores, you have to deal with several instructions dedicated to control flow.

      If you're doing the same dot product on a SIMD core, you don't have any loop overhead.

      Heck, even if you're just doing a MAC operation, the example holds. Which would make best use of processor capabilities - issuing a multiply and then an add, or issuing one operation with data flow built into the hardware?

      I'll place my speed bets on SIMD and hardwired data flow, thank you.

    9. Re:Compression by Captain+Oblivious · · Score: 1
      You had me at HELO


      +1, Clever.

    10. Re:Compression by donglekey · · Score: 1

      Thanks! SMTP jokes are so hard to come by.

  10. What I like about Chuck Moore by Angst+Badger · · Score: 5, Insightful

    The thing I have always liked best about Chuck Moore is that, whether you agree with him or not on a particular point, his ideas are always interesting and original. He's not afraid to follow his own judgment wherever it leads, and while he may perhaps end up following more blind alleys than a conventional thinker, it's people like him who will also make the most breakthroughs. In this day of C++/Java/XML/insert-other-orthodoxy-here, it's good to have someone like Chuck Moore around to remind us that computing can still be exploratory and experimental, and that you can still make a living without following the herd.

    --
    Proud member of the Weirdo-American community.
    1. Re:What I like about Chuck Moore by blamanj · · Score: 2

      In this day of C++/Java/XML/insert-other-orthodoxy-here, it's good to have someone like Chuck Moore around

      I fail to see how replacing today's orthodoxy with Forth orthodoxy is any great step forward. Differently languages have different expressive purposes. Would you rather code a web-log report tool in Perl or Forth? Moore side steps the problem by saying that text-processing problems don't appeal to him. That doesn't invalidate the existance of such problems.

      I think Forth has it's place. I've used it and found it effective for certain problems. But to say
      I remember my shock at learning that Fortran compiled into Assembler, that then had to be assembled. A language that can be translated into another is clearly unnecessary
      borders on stupidity. An assembler simply translates into binary, why not skip both steps and bring back the panel switches a la the MITS Altair? Basically, Moore has simply found an assembly language for a virtual machine that works for him. He called it Forth, and is now spending his time building hardware that matches that virtual machine.

  11. talk about colorForth by n8willis · · Score: 1
    I'll tell you one thing: he sure has Forth-colored glasses on....


    I'm not bashing Forth. I think zeal can be a healthy thing. But, you know, zeal about a concept, not about one isolated tool/approach.

    Nate

    --
    -- Watch the REAL Jon Katz.
    1. Re:talk about colorForth by Anonymous Coward · · Score: 0

      forth _is_ a concept.

      this is why you will never see real object
      oriented forth (rather than OO tacked on
      forth ); forth does not need OO, it
      _supercedes_ object orientation.
      it has all the advantages of OO without
      the excess complexity.

  12. Hmmm by Reality+Master+101 · · Score: 5, Insightful

    Forth clearly revolutionizes software as most know it. It could lead to efficient, reliable applications. But that won't happen. A mainstay of our economy is the employment of programmers. A winnowing by factor 100 is in no one's interest. Not the programmers, the companies, the government. To keep those programmers busy requires clumsy languages and bugs to chase.

    To be honest, to me this invalidates everything else he said. If you have to depend on a conspiracy to figure out why your pet language is not universally adopted, then you are not living in reality.

    I used Forth a long time ago. In fact, I advocated using Forth for the game company I worked at because I liked its simplicity and compactness. But I realize now that the practical measure of a language is how easy it is to maintain it... and Forth is not that language.

    It kind of reminds me of APL zealots (yes, there used to be those, and there probably still around in hiding). They claimed much of the same things... that APL should be the language that everyone uses (I remember someone trying to convince me that APL would be a great language for an accounting system). They would NEVER admit that APL was hard to maintain.

    I think this guy needs to pull his head out of the clouds and realize that there just might be reasons other than conspiracy that Forth is not more widely used. Forth had its time in the sun, and it was eventually rejected.

    --
    Sometimes it's best to just let stupid people be stupid.
    1. Re:Hmmm by spoggle · · Score: 1

      I agree with you to an extent, but Forth hasn't been rejected at all!

      Forth is in broad use for very low-level embedded stuff - doesn't every Sun computer have Forth embedded in it. FreeBSD uses Forth in it's boot process, and I'm certain that there are others...

    2. Re:Hmmm by Viadd · · Score: 3, Funny

      They would NEVER admit that APL was hard to maintain.

      But you don't have to maintain an APL program. If, for instance, there was a bug in the operating system kernel, and it were written in APL, you would just re-write it. How hard is it to rewrite one line of code?
    3. Re:Hmmm by Reality+Master+101 · · Score: 1

      I agree with you to an extent, but Forth hasn't been rejected at all!

      I should have said that it's been rejected as a "general purpose language". I think Forth has a lot of value in embedded applications.

      --
      Sometimes it's best to just let stupid people be stupid.
    4. Re:Hmmm by Anonymous Coward · · Score: 0

      "
      To be honest, to me this invalidates everything else he said.
      "

      To be honest, to me you are a douchebag troll whore.

    5. Re:Hmmm by William+Tanksley · · Score: 4, Insightful

      To be honest, to me this invalidates everything else he said. If you have to depend on a conspiracy to figure out why your pet language is not universally adopted, then you are not living in reality.

      Read again. He did NOT claim any form of conspiracy; he simply identified common interest. There IS a common interest in all those sectors in staying employed.

      At the same time, there's a more powerful common interest at stake: making money. It's better to make money than to stay employed (in a corporation which refuses to change to a more efficient concept, and which will therefore soon lose business).

      So it's clear to me that Chuck's analysis is simplistic. But so is yours -- at least he's correctly identified a problem.

      The real problem with Forth is that it achieves its successes by being fundamentally different. The theory behind Forth is totally at odds with the theory behind all other languages, with the exception of Postscript and Joy. And until the last couple of years, nobody had done ANY work on understanding that theory, and from that understanding coming up with simple ways to explain what makes a Forth program "good" or "bad".

      Thankfully, we now have some work done on that, and I believe that the clear result is that all modern Forths are screwy. They encourage writing code which is bad, and therefore hard to maintain. This isn't the fault of Forth; it's the fault of the vocabulary Forth now has. The success of C wasn't due to the language (although it was good, it was only a minor improvement over previous languages); it was the teaming of the language with the library and runtime (AKA Unix).

      Work is ongoing... See the concatenative languages group for more discussion and a very informative link.

      As for APL... We have one APL "zealot" (your word) on the concatenative languages list. He's an excellent help; he can see right through many of the trivial differences in syntax to the problem actually being solved. There's no doubt that APL is a great language, and provides a marvelous "transform", converting a problem from one domain (its native domain) to another domain (the array programming domain) in which it can sometimes more easily be solved. It's like a laplace transform -- a wonderful tool for problem solving. One doesn't maintain a laplacian transform when the problem changes; one simply reworks the math.

      Forth is different; in Forth you don't transform the problem into a form which fits the language; instead, you transform the language into a form that fits the solution domain.

      -Billy

    6. Re:Hmmm by dbremner · · Score: 1

      It kind of reminds me of APL zealots (yes, there used to be those, and there probably still around in hiding). They claimed much of the same things... that APL should be the language that everyone uses (I remember someone trying to convince me that APL would be a great language for an accounting system). They would NEVER admit that APL was hard to maintain.

      Nowadays most of us APL zealots have moved onto J, K, or A+ all of which have most of the traditional procedural primitives, for, while, do, if, etc. There are many programming tasks where maintenance is not an issue but speed of development is, for example, rapid prototyping. Structured and Commented APL is not hard to maintain if written by a competant programmer.

      --

      Life is a psychology experiment gone awry.
    7. Re:Hmmm by Animats · · Score: 2
      If you have to depend on a conspiracy to figure out why your pet language is not universally adopted, then you are not living in reality.

      Good point. Forth has been around for a long time, and it's never really caught on. I've written a few thousand lines of it myself, for an embedded application. It's not that there's any big opposition to it, or that people can't understand it; it's that it just isn't all that great.

      Big arrays of little machines aren't that useful either. That approach has been tried; the hardware can be built, but few problems fit that model well. The ILLIAC IV, the Hypercube, the BBN Butterfly, and the Connection Machine all fit that model, and they were all dead ends. The two extremes of that spectrum, shared memory multiprocessors and clusters of networked machines, are both useful. Nothing has been found in the middle that's equally useful.

      The trouble with stack machines is that they have a worse Von Neumann bottleneck than register machines. Everything has to go through the top of the stack. It's probably possible to get around that with a superscalar architecture. (The FPU in x86 machines is a stack architecture, yet all modern implementations are able to get a few instructions going simultaneously.) But Moore would rather have lots of dumb processors than superscalar ones.

    8. Re:Hmmm by ansible · · Score: 2

      The trouble with stack machines is that they have a worse Von Neumann bottleneck than register machines. Everything has to go through the top of the stack.

      Hmmmm.... I wonder about that. If you designed a CPU for Forth (or another stack-based language), you could have something where the first, say, 10 elements of the stack are in registers, and the rest in memory. As the stack grows, the bottom elements are moved off into main memory. Vice versa for shrinking. If done cleverly, there wouldn't be much need for copying data around.

      Of course, I'm sure someone's already thought of this...

    9. Re:Hmmm by William+Tanksley · · Score: 2

      The trouble with stack machines is that they have a worse Von Neumann bottleneck than register machines. Everything has to go through the top of the stack.

      At the same time, though, because you don't have a register file, you don't have to have an instruction decode stage. As a result, your instruction cycle time goes down.

      The cycle time needed for these machines is truly amazing. I built one back in college, and outperformed every other chip in the class.

      -Billy

    10. Re:Hmmm by elmegil · · Score: 1
      He effectively said there was a conspiracy to perpetrate bugs, which there isn't. Beyond that, what the other poster said makes a lot of sense. I like Forth too, and have tried to do some personal project in it. But I find that when I inevitably get distracted, and return to the projects, trying to re-read the code and figure out where exactly I was is damn near impossible.

      This is not to say that you can't write code in other languages that is just as incomprehensible, but I find that I can pick up a perl script I wrote 2 years ago and read it right away. I can't do that with Forth. It would take a lot of effort, and continuous programming (which I don't do in perl either) to remain fluent enough in Forth to do that. And since I only have these intermittent projects written in it....it's not worth the hassle.

      Like it or not, Forth is not the most easily maintained language out there, and there are languages that do lend themselves more easily to long term maintainability.

      --
      7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
    11. Re:Hmmm by bentini · · Score: 1

      Oh? Really? You think you could do that?
      Learn about CRISP by Ditzel et al. from Bell Labs. Damn near 20 years ago, amazingly efficient stack based RISC processor.

    12. Re:Hmmm by William+Tanksley · · Score: 3, Informative

      He effectively said there was a conspiracy to perpetrate bugs, which there isn't.

      He most certainly did NOT say that. He said that there is a common interest in keeping to the current ways of doing things, and further that the current way is less efficient than his way. His first statement is obviously true; he doesn't infer from this that there's any conspiracy, nor does he need to. His second statement is not obviously true, and in fact I believe it misses the point. It may be true that his way is actually more efficient, but the costs of converting everything to work his way would be very high indeed. When you add in the fact that the theory behind Forth isn't completely understood and is only beginning to be explored, it's very clear that now isn't the time to switch to Forth, and even more clear the 1980 was worse.

      This is not to say that you can't write code in other languages that is just as incomprehensible, but I find that I can pick up a perl script I wrote 2 years ago and read it right away.

      What can I say? You know Perl, and you know how to write clear code in it. Try reading a hardware engineer's Perl code (i.e. someone who didn't grow up writing software), and see how far you get.

      I can't do that with Forth.

      Odds are that you can -- I certainly can, and I don't have an immense amount of experience with Forth. You simply have to realise that Forth is different, and you have to learn how those differences affect the ideal coding style.

      For example, you're used to a vertical code layout:

      function1
      function2
      function3

      In Forth, the ideal code layout is horizontal:

      function1 function2 function3

      You're also used to keeping your routine size down to a page or two -- any bigger, and it gets too hard to maintain, and any smaller and the parameters take up too much space to type and too much time to pass to the function. In Forth the ideal routine size is about 50 characters.

      In both Perl and Forth, you can write unit tests to check your code. In Forth, you're encouraged to keep them in the same source file, and run them as part of compilation. There are tools to help -- one of my favorites defines the words "testing", "{", "--", and "}".

      testing addition
      { 3 4 + -- 7 }
      testing distributive property of addition
      { 3 4 5 + + -- 3 4 + 5 + }

      Include a section like that after every word definition, and update it regularly whenever you try to use the word in a different manner, and you'll have a much easier time maintaining the word when it has to be changed.

      (I'm not claiming that unit testing is new to Forth, although Forth was one of the first languages to use it heavily as part of the language. Perl and Python in particular can be used very effectively for unit tests, since they're interactive.)

      Anyhow, my point is that the rules for programming in Forth are very different than those for other languages.

      -Billy

    13. Re:Hmmm by wjw · · Score: 1

      have something where the first, say, 10 elements of the stack are in registers, and the rest in memory.

      Usually in Forth you won't put more than few elements on the stack. In fact one of Chuck's processors had stack only 5 cells deep.

      While some software Forth systems give you 64 or more stack cells, it is advocated that good Forth program won't use more than 10 or 15.

    14. Re:Hmmm by Anonymous Coward · · Score: 0
      Read again. He did NOT claim any form of conspiracy; he simply identified common interest.

      Maybe "conspiracy" wasn't quite the best word, but he certainly did suggest that there was some ignoble ulterior motive that prevented people and organizations from adopting Forth. That's enough to consign him to the realm of kookdom, in my eyes.

    15. Re:Hmmm by Grit · · Score: 1

      I think the benefits of Forth in terms of "thinking different" could just as easily be applied to other languages such as Perl, Scheme or ML. Each language has its own idioms and ways of approaching problems. Most of the points I've heard in favor of Forth boil down to "it's small", "it uses postfix", and "it forces you to write small functions." None of these seem particularly convincing to me.

      I really can't understand what's so appealing about postfix notation as opposed to prefix or infix. (Despite what Chuck Moore says, most modern languages are actually a combination of the two, which does give Forth some edge in purity, especially for people who don't like parentheses.)

    16. Re:Hmmm by William+Tanksley · · Score: 2

      You're largely right. The lessons you learn in Forth can sometimes be applied to C and Scheme. But in spite of the lesson we've all heard, that all languages are essentially the same, practical experience shows that they're NOT. Refactorings which are easy in Java are horribly painful in C (because of the lack of classes, for example). Code which looks natural in C looks bad in Java.

      The reason? Java uses object orientation. C doesn't.

      So does Forth have anything that C doesn't? Yes. In fact, Forth has a characteristic which permeates the entire language and which is shared by only a few other languages: I call that characteristic "concatenativity". Let me explain.

      The languages you're used to are probably all "applicative": you apply parameters to functions using the syntax of the language. In Forth parameters are nonexistant as far as the language is concerned; there is no application operator, implicit or explicit. Instead, a Forth program is defined as the concatenation of a series of primitive operations on a stack. Mathematically, this could be modelled as having "Forth words" be functions of one input and one output, and a "Forth program" be the composition of the functions, in the order of their appearance.

      But that's all windy and theoretical. I have a more useful definition of what it means for a language to be "concatenative", and it's the reason I chose that name. A language is concatenative if the concatenation of any two valid programs is a valid program, and if the splitting of any valid program along token boundaries produces two valid programs.

      Suppose you have the program "2 3 + ." (add two and three and display the result). Split it any way you like: "2 3" is a program which leaves two integers on the stack, and "+ ." is a program which takes two integers, adds them, and displays the result.

      Thus we see that your statement "Forth forces you to use small functions" isn't quite true. You can write functions as large as you want; the language doesn't care, and I've never heard of an implementation which would have any problems. The trick is that in Forth, if your definition gets too big, you can simply cut part of it out (arbitrarily), give that section a name, and call that name from your code. Bingo -- you've just performed a complete refactoring "Extract Method". And there was no trace of danger -- no need for a refactoring browser.

      If you've survived my exposition this long, congrats. Sorry. :-) Check out the Joy page for a possibly more survivable introduction.

      And BTW, you list the claim "Forth is small" as a dubious advantage of Forth. Yet I would say that's a definite advantage. Forth is small because it uses Forthlike implementation techniques; it's easy to manually compress a Forth application by refactoring its methods. Forth is small, and your application in Forth can also be small.

      -Billy

    17. Re:Hmmm by osu-neko · · Score: 1
      Refactorings which are easy in Java are horribly painful in C (because of the lack of classes, for example). ...

      The reason? Java uses object orientation. C doesn't.

      This I have to object to. Object oriented programming is a design methodology, not a language feature. It's programmers that use object orientation or not. You can write non-OOP programs in Java, and you can write OOP programs in C. I learned OOP under C, in fact. The computer I was using at the time didn't have any C++ compilers available for it. Not that it matters -- C can easily support classes, (single) inheritence, and polymorphism, and the syntax isn't that far off from C++. When a C++ compiler became available for that machine, I translated many of my C programs to C++. The biggest change was removing the explicit "this" parameter from function declarations (since C++ does the exact same thing but does it implicitly), a task I easily accomplished with find and replace.

      Anyhow, to make a long story short, if someone is doing it the "horribly painful" way in C rather than the easy way they would have done it in Java, that's their fault, not the C language's fault. If an object oriented solution would work best, then code an object oriented solution, for crying out loud! I'm starting to think OOP classes at universities ought to be taught in C -- there are too many confused people that think if a language doesn't have explicit syntactic-sugar for OOP concepts, they can't use those concept in the language. I can't ever stress this enough: OOP is a design methodology, not a language feature!

      --
      "Convictions are more dangerous enemies of truth than lies."
    18. Re:Hmmm by Animats · · Score: 2
      Of course, I'm sure someone's already thought of this...

      Yup. Burroughs B5000, circa 1960, a stack-machine mainframe. An elegant design, and far, far ahead of its time. A stack-machine shared memory symmetrical multiprocessor with paging and tagged memory in 1960. Reasonable performance for its day, and a successful product; banks used them heavily for years. The B5000 was followed by the B5xxx, B6xxx, and B8xxx product lines, with compatible architecture, and the product line continued until well after the merger with UNIVAC to form Unisys. Definitely the most succesful of the stack machines.

    19. Re:Hmmm by Anonymous Coward · · Score: 0

      Whoa there cowboy, I see no mention of a conspiracy in the original post. You don't need a conspiracy in the standard sense to keep an entrenched technology entrenched.

      If I was to say to my manager "I know of a [language,os,whatever] which will increase my productivity 100 fold, but it's something that you probably don't understand or have never even heard of" the answer "you must be out of your freaking mind" does not mean there's a conspiracy.

      "Standanrd" languages are here to stay (for the forseeable future), regardless of their merits. Chuck's point is that he has no managers to convince so he does what he feels is good/fun/whatever.

      As for your comment "Forth had its time in the sun, and it was eventually rejected", isn't that what has happened to nearly every new technology that comes along? Look, the current programming paradigm is going to change eventually, no matter how important you think your current skills are (they're not - in the long term). But it will take a long, long time and we need brilliant minds like Chuck to help discover what the new paradigm will be.

    20. Re:Hmmm by fusiongyro · · Score: 2, Interesting

      Read again. He did NOT claim any form of conspiracy; he simply identified common interest. There IS a common interest in all those sectors in staying employed.

      According to this logic, we would never have moved to C from assembly language.

      Daniel

    21. Re:Hmmm by William+Tanksley · · Score: 2

      According to this logic, we would never have moved to C from assembly language.

      Yes, taken strictly and applied to all cases, it means that. But only a great fool would do so. You are clearly not a great fool; therefore, I cannot take the glass in front of you. Sorry. I mean that I can't assume that Chuck meant that generality.

      C is not a huge step up from assembly language is bug-freeness. It's an improvement in consistency of code, and it makes structure easier to discern, but there's a reason it's called "portable assembly".

      -Billy

    22. Re:Hmmm by William+Tanksley · · Score: 2

      OOP is a design methodology, not a language feature!

      OOD is a design methodology. OOP is how you implement that. And although you can do OOP in a non-OOP language, OOP is also most definitely a language feature.

      If you code OOP in a language which doesn't support it, you'll have to obfuscate your solution with OOP implementation.

      -Billy

    23. Re:Hmmm by Captain+Oblivious · · Score: 1
      It kind of reminds me of APL zealots ...would NEVER admit that APL was hard to maintain


      I was once given an APL program to analyze and report back on its function. I studied it for days before I realized that it wasn't a program at all - someone had left a cage unlocked and a monkey had spent an hour pounding on the keyboard.

    24. Re:Hmmm by BruceMcF · · Score: 1

      If you can't maintain the Forth you wrote, you wrote poor Forth. As with any other language, you have to follow the rules of writing readable Forth if you want to write readable Forth.

      Of course, a lot of perfectly good Forth from earlier days appears to be maintainable, since they were in "blocks" with companion "shadow blocks" that are indispensible to reading the source. To simplify to a modern Forth source as a normal text file, you should be able to answer yes to each of the following (not an exhaustive list):

      (1) Is each forth word preceded by one or more comment lines of explanation of WHY it is used and, if context-dependent, in what context?

      (2) Does the name of each word evoke the reason it is used?

      (3) Is every colon definition accompanied by a stack comment showing the state of the stack before and after use of the word?

      (4) Is your average colon definition seven words or less?

      (5) Have you designed your basic implementation words so that it is unecessary to manipulate the stack when using your public interface words together?

      (6) Have you tested each word before putting it to use in the file?

      If you have all of those things, you should be able to open the file up with a decent editors text editor, look at the use of the public interface wordset, and work your way back in the file to the point where you need added capability, and search through the file to find the bits and pieces of existing capabilities that need extending.

      I recently opened up a long (64K) source file that I put aside a year and a half ago, and every point where it is hard to read is a point where I broke two or more of the rules above. And since I mostly followed the rules, it was much easier than I thought it was going to be to get back into it and make a substantial change to the way things were done.

    25. Re:Hmmm by BruceMcF · · Score: 1

      The way some double stack processors (that is, return stack and data stack are seperate) do it is to spill half the stack on overflow, and refill on underflow. Others spill and refill on demand ... the last stack item is spilled out for overflow, and the stack is refilled a cell at a time on underflow.

      See Koopman's book, Stack Machines, a New Wave ... give a collection of trade-offs, and a processor approach that places less demand on hardware than CISC and RISC processors, its not surprising that most alternative approaches have been implemented.

    26. Re:Hmmm by BruceMcF · · Score: 1

      That's an important point. You don't need a pipeline if you can execute an instruction in the time it takes to read the instruction, as with most hardwired stack processors, or in two with most microcoded. And without a pipeline, and with operand-free operands, you can implement interupts as simply a hardware procedure call, without pipeline latency or management overhead.

      Of course, that's just ordinary state of the art in stack machines, and not leading edge asynchronous stuff like Chuck is doing.

    27. Re:Hmmm by Grit · · Score: 1

      Thanks for your coherent and insightful answer. I hadn't thought about Forth in quite that way, although it's been a long time since I played around with it. One could view unix piping as a concatenative programming language by defining "tokens" correctly...

      Naturally, this behavior doesn't come without cost. With Forth (and Joy) it seems to me the cost of not having any arguments is that you can't do any type checking. Indeed, wouldn't any large Forth project have to document what "arguments" a word expects? I'm not convinced us poor humans can deal with all the power at our fingertips. :)

      I think that one _could_ probably build a type-inference system into Joy. Basically all types would be parameterized--- rather than "int" it would be "stack of type X with int on top".

    28. Re:Hmmm by William+Tanksley · · Score: 2

      Thank you very much for your kind words!

      Yes, Unix piping is in a sense concatenative, although unix command lines definitely are not.

      Until just recently, everyone seems to have thought as you do about type checking. Including myself. To our surprise, Dr. Becher, while trying to write a simple memory handler for an complex embedded system, wrote a complete, strong, polymorphic, static typing system (with plenty of room for dynamic types). Amazingly, this system required absolutely no syntax changes or compiler modifications; the resulting language is unmistakably Forth! (Although in practice, you want to redefine all words so that they can use the typing, and the result of THAT is not ANSI standard Forth.)

      How he did it is amazingly simple, efficient, and natural; check it out at his homepage.

      His system appears to have some limitations compared to a generic concatenative language (for example, a word can't have a variable stack effect); however, I've come up with a simple solution which makes his system have the full abilities of any other concatenative language. I haven't written it up because right now, my prototype requires a small runtime component, and I'm sure that I can make it entirely static (so that it'll be comparable to Becher's system).

      Someone else has also designed an ML-style inferencer for a Joy-like language, but I'm not aware of it actually having been built. At any rate, I have some doubts about its usefulness; Becher's system is so simple and elegant that I don't think I want all the complexity and overhead of ML type inference for the tiny advantage of sometimes not having to declare types.

      However, earlier you state that "this behavior doesn't come without a cost." Your specific example was incorrect, but in general you're correct. There's a time to use applicativity, and a time to use concatenativity. Every computer scientist should know Forth and understand concatenativity, but every computer scientist should also know the other, different languages.

      I simply find concatenativity interesting because I've never studied it before.

      -Billy

  13. Intriguing by jd · · Score: 2
    The replies are fascinating insights. It's a pity he didn't spend more time on each one, but he DOES have a "paying" job & real life, too. I guess that kind-of limits people on the time they can spend on an interview.


    This is NOT a critisism, though, more wishful thinking. What was said was fascinating, and there is a lot there to think over. Doubly so, since it IS just the tip of the iceberg.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:Intriguing by PurpleBob · · Score: 2

      If you look at his web page, you will see that Chuck is always very terse. I think this is a side effect of working with Forth so much; he carries his style over into English.

      In the documentation for ColorForth, for example, he often describes a feature with a single sentence and moves on.

      --
      Win dain a lotica, en vai tu ri silota
    2. Re:Intriguing by jd · · Score: 2

      Then I guess I'll thank God he doesn't speak with a LISP. The parentheses would drive me nuts. (Hmmm. I'm ALREADY nuts. Maybe I wouldn't be too badly effected, then.)

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  14. Marginalizing the Blind by skroz · · Score: 5, Interesting
    I have no qualms about requiring color vision for programmers. Everyone does not need to be a programmer.
    Well thanks, Chuck. I'm not completely blind, but close enough that your colorForth is inaccessable, as is most web content. Thanks for telling me that I don't have to be a programmer. Guess what? I want to be, buddy. And while I don't think I'm the best coder that ever walked the earth, I think I can get the job done. But thanks to people with dismissive views such as yours, it's becoming harder and harder every day to do what I enjoy: coding. It's bad enough that most developers don't consider the needs of people with disabilities, but to hear someone who has considered then DISMISSED those needs is truly disheartening.
    --
    -- Minds are like parachutes... they work best when open.
    1. Re:Marginalizing the Blind by donglekey · · Score: 2

      Not everything can me made accesible to everyone and that is his point. He isn't going to rethink his design because some people can't see well. He didn't mean that blind people shouldn't program, he meant blind people don't need to program forth. He said that he knew lots of good blind programmers.

      I do a lot of 3D animation. Why don't you go after Alias|Wavefront or Newtek for not making their products accesible to the blind. Your lack of sight is an obstacle that you will have to overcome, and it will limit you in some things. Just accept it. You can't use color forth, its not a big deal. You probably shouldn't become a photographer, animator, cinemetographer or airline pilot. Def people won't become sound engineers. That's just the way it is and people aren't going to limit themselves because someone somewhere might be offended. That's how we get politicians not progress.

    2. Re:Marginalizing the Blind by Modab · · Score: 1
      Please observe what he said:
      I'm sure colorForth will be translated into these other representations. I, myself, will be exploring spoken colorForth. (As soon as I can decipher PC sound cards.)



      This man is simply saying that he wrote colorForth for his needs. He would not write code that he would not use. Why should he? It is refreshingly frank and honest. Someone else who is color blind can write code for themself.
      He is not against people with disability, but he is not your shepherd, and you are not a sheep.

    3. Re:Marginalizing the Blind by William+Tanksley · · Score: 2

      You're taking him badly out of context. His Colorforth is indeed inaccessible to you, but as he's repeatedly stated, color isn't the important things -- he mentions tone, font, and emphasis as alternatives here.

      He's only working with color right now, because that's what he needs; why should he do extra work to solve a problem nobody has? Hire him (or have him hire you), and he'll find a way for you to use ColorForth.

      -Billy

    4. Re:Marginalizing the Blind by CrosseyedPainless · · Score: 2

      Just accept this: he's gratuitously adding the requirement for color vision to programming. Would you be so accepting if someone added an unnecessary and mostly worthless requirement to your job description, one you physically can't acquire, and then said, "Oh well, not everyone needs to be able to do that job, anyway."?

      No, the inability to use colorforth is not a big deal. In fact, given the total irrelevance of any Forth to the world, it's no deal at all. My objection is not to colorforth, but to you and Chuck's "Fuck'em" attitude. That's far more offensive than an unused, needlessly colorized computer language. But, I'll take your advice and just accept it.

      --unoffical spokesman, Colorblind Computer Programmer's Association

    5. Re:Marginalizing the Blind by noc · · Score: 1
      I agree with you that it's his attitude and the offensive "well, not everyone needs to be a computer programmer" comment that's the problem.

      His actions on the other hand, I have no problem with. He's trying to come up with a better system for himself: encoding meaning in the color of words. He pointed out himself that this same meaning could be given to things like typeface, volume, etc. It would be a problem if he came up with inaccessableForth, which gave him a slight productivity gain, then started advocating its use at the exclusion of people perfectly capable of computer science, just not his language. It would be possibly justifiable if he (and everyone using his system) got an order of magnitude productivity increase, IMO.

    6. Re:Marginalizing the Blind by LazyDawg · · Score: 1

      He said shortly afterward that color is just his own method for distinguishing different types of code, that you can change the font or face to distinguish different colors too. But yeah, saying that blind people don't have to be programmers is mean :)

      --
      "Look at me, I invented the stove!" -- Ben Franklin
    7. Re:Marginalizing the Blind by benedict · · Score: 2

      A deaf guy produced Rahsaan Roland Kirk's excellent album "The Inflated Tear."

      (Kirk, btw, was blind.)

      --
      Ben "You have your mind on computers, it seems."
    8. Re:Marginalizing the Blind by Anonymous Coward · · Score: 0

      Don't be a crybaby. He developed his programming environment based on his needs, and his wants. He's not imposing ColorForth on you. On the contrary, you would have to go out of your way to use it.

      Your entitlist attitude is pathetic, and it disgusts me. I'm glad you're not a programmer at my shop, because I'd probably end up doing your work for you.

      I don't have slog up conceptual wheelchair ramps just because you have different needs. Why should I inhibit myself because of your deficiency, when there are multiple routes to the same goal?

    9. Re:Marginalizing the Blind by wjw · · Score: 1

      Chuck's statement reflects Forth philosophy - don't try to make something more universal than it needs to be. Abstraction kills efficiency. You can't write code that runs on two different platforms without sacrifying performance. And Forth is about using every "mips" available. Some with user interface.

      Color is used in ColorForth as attribute - by using color you denote function of word that you write - whether it is word to be defined, part of definition, statement to be executed or a comment. And as others have pointed out, you can use smell or tone or font typeface instead of color.

      On the other hand, Chuck's ColorForth implementation will choke on my hardware, uses extremanlly big screen font and worse-then-dvorak keyboard layout. I think it is not intended for widespread use - more a testbed for interesting ideas.

    10. Re:Marginalizing the Blind by Kristopher+Johnson · · Score: 1

      If you had bothered to read the paragraphs above and below the one that bothered you, you would notice that he said

      - He is amazed at the capabilities of blind programmers.

      - He designed colorForth to augment his own capabilities, and not to conform to others' capabilities.

      - He is interested in non-visual versions of "color" Forth, including speech.

      I don't think he DISMISSED the needs of the blind in any way.

      -- Kris

    11. Re:Marginalizing the Blind by Anonymous Coward · · Score: 0

      Grow up. So, your vision is limited, get over and on with it. You are less distracted by color and graphics, and can focus on words, I do not hold that ability against you, do not hold his use of color against him. Moore has spent his life in the pursuit of increased programmer bandwidth. He has explored almost every possible human neural channel in this effort. For years he used a 4 button KEYBOARD to see if that made him more productive. My own disability, Multiple Sclerosis, prohibits my use of such "Chord style" keyboards. I envy your ability to use such devices, and HONOR the efforts of inventors like Moore to reexamine the orthidoxy of this absurd QWERTY keyboard I am forced to peck this into. Let us end this absurd whining thread on what is an otherwise interesting topic. In 5 years when you use voice to interface to your digital world, you may well rely on the efforts of Charles Moore. I have trained, hired, and provided tools to over 10,000 programmers. Trust me, with your additude toward life, programming is probably not for you anyway. Move on.

    12. Re:Marginalizing the Blind by ZvlvLord · · Score: 1

      He DID NOT say that EVERYONE should have no qualms about requiring color vision for programmers !!!! He ONLY said that HE HAD NONE. Do you code in Forth ?? If yes, you do not need COLOR to code in Forth. Apart from ColorForth, most Forthes do not use color ( you do not need a color monitor to code with those Forthes ) So chill your horses cowboy... *smile*

  15. fanatics by spoggle · · Score: 1

    I get very uncomfortable around fanatics like Chuck - I've been an engineer for a long time and I usually find that anyone with only one tool is going to try and redefine all problems to be fixable with that tool. I've used Forth for years, but I also use C/C++, Perl, Lisp, etc. Each tool for a different problem. Forth has a well-defined and useful niche (it's longevity proves that), but it's far from something that 99% of us will ever use.

    That said, his processor is really cool looking - wish I had some to play with. I can think of a lot of problems that could be solved with these and Forth. But I think that the fanaticism here will put off many backers...

    1. Re:fanatics by Anonymous Coward · · Score: 0

      I agree, all fanatics must die.

      But you know how the old adage goes : "If the only tool you have is a cruise missile, every problem looks like Nagasaki".

    2. Re:fanatics by arkanes · · Score: 1

      I guess we get a Forth entry in the "Programming languages as hammers" list...

    3. Re:fanatics by Anonymous Coward · · Score: 0

      "
      I get very uncomfortable around fanatics like Chuck
      "

      I get very uncomfortable around douchebag troll whores like you.

    4. Re:fanatics by William+Tanksley · · Score: 2

      The most important part of Forth isn't a tool -- it's a concept. And most of you HAVE used it, although you deny it; most of you use the concept which powers Forth every time you print something. The same concept that powers Forth also powers Postscript.

      -Billy

    5. Re:fanatics by P.+Legba · · Score: 1
      I get very uncomfortable around fanatics like Chuck - I've been an engineer for a long time and I usually find that anyone with only one tool is going to try and redefine all problems to be fixable with that tool.


      Chuck Moore's genius is not that he redefines all problems to be fixable with his tool, but that he redefines his tool to fix all problems, or builds new tools from scratch.


      The man has created a programming language and then created an OS to run the CAD system he created for designing hardware to run his programming language natively. Maybe you think this is reinventing the wheel; but if you need the wheel to work in a particular way, then maybe it needs reinventing.


      P.

    6. Re:fanatics by spoggle · · Score: 1
      The man has created a programming language and then created an OS to run the CAD system he created for designing hardware to run his programming language natively. Maybe you think this is reinventing the wheel; but if you need the wheel to work in a particular way, then maybe it needs reinventing.


      Didn't say he wasn't a genius - I would agree with this. But genius sometimes leaves the majority of us wondering what the hell he's talking about.


      You can do amazing things with almost any language - you could rewrite emacs in VisualBasic, and I'm sure that there are people out there who would find this the best course for them. Chuck knows and loves Forth, so if he wanted to rewrite emacs, he'd do it in Forth. That's cool for him.


      The real applicability of a language shows in it's successes - Chuck says it in his answers, Forth is not successful as a general purpose tool, but is very succesful as a component at the very low levels.

  16. Color Vision and programming by Jeremy+Erwin · · Score: 2
    cm said " 20-20 vision is required for fighter pilots. I have no qualms about requiring color vision for programmers. Everyone does not need to be a programmer."

    I would disagree. While the Free Software Foundation, for instance, does not explicitly condone "programming regardless of skill"-- contributing to gcc does require some aptitude, free software allows anyone to program--without regard to financial means, or the willingness to sign NDA's.

    Before color forth, color vision was not a prerequisate for programmers. Why should it be now? (Why are boldface, italic, and roman not appropriate analogues for red green and yellow, anyway?)

    1. Re:Color Vision and programming by Anonymous Coward · · Score: 0

      Yup, he can't use color coding for his language because you can't see color. So what if it makes him more productive.

      A 386 was required for running software! Why is it now? (says the owner of new software)

    2. Re:Color Vision and programming by William+Tanksley · · Score: 2

      (Why are boldface, italic, and roman not appropriate analogues for red green and yellow, anyway?)

      They are, of course -- he said they were. He's using color now because that's what he started with; you can't deny that it's easier to work with than multiple typefaces.

      -Billy

  17. Designing the software first, then the hardware by On+Lawn · · Score: 2

    This guy designing the language and the chip is interesting to me.

    Its mentioned in the technical manual for the Enterprise 1701-D that the software was designed long before the hardware. This seems unnatural considering the ease with which you can change software compared to hardware but there are advantages.

    EROS for example is a OS that is struggling to apply some really cool ideas becuase there is not enough hardware support for its permission paradigm. Alternatively, it took MS over 10 years to implement all the hardware features built in to the 486 for OS's to use (not just the 32bit bus).

    3d libraries are being written in hardware code now, after the attempt to do it in software couldn't handle the massively parallel nature and speed requirements. Now there are crypto cards that simularly add hardware designed functions to prop up where software is slow.

    So what I wonder is, is it really so unfeasable or unreasonable to design the software first and then the hardware?

    1. Re:Designing the software first, then the hardware by Fredflintston47 · · Score: 1

      It makes complete sense to explore the problem space using software, and only when you know what you're talkign about implement the solution in hardware.

      When designing and trialing a trouble tracking system from teh ground up, do you immediately start programming to get a web interface to handle it?

      No! You start with a paper-based system that is amazingly flexible, get the process right, and *then* you can automate it

      --
      Go, Springboard, Go!
  18. big fourth talk - where's the beef? by Anonymous Coward · · Score: 0

    He repeatedly goes on about how fourth is so much more compact and efficient than c, pascal, and java.

    Can he show a system with 1mm+ lines of fourth?

    Don't give me the bs about rewriting a 1mm+ c program with 10k lines of fourth. How about taking a 25mm+ line c application and rewriting it in 1mm+ lines of fourth?

    Can he show a system such as a 500 concurrent user database written enterly in fourth?

    Maybe he should change is stock ' fourth is best programming language ' answer to 'fourth is bets embedded, small system language '.

    I can already hear his answer 'why would I want to have a 500 concurrent user database system?'

    Is the web server, os, etc which serves his home page written in fourth?

    1. Re:big fourth talk - where's the beef? by Anonymous Coward · · Score: 0

      "
      He repeatedly goes on about how fourth is so much more compact and efficient than c, pascal, and java.
      "

      Do you want him to lie?
      and BTW, the spelling is "Forth".

      the rest of your arguments are either
      incomprehensible or bullshit. you mar the
      name 'anonymous coward'. douchebag troll
      whore.

    2. Re:big fourth talk - where's the beef? by numbnutz · · Score: 1

      The Raytheon Arline terminal systems of the early 80s were written in Forth with thousands of concurrent users hitting a shared database. Federal Express and other distributed databases with portable wands had thousands of concurrent users. By the end of the year, the majority of systems sold with UNIX pre-installed will boot with the "appropriate technology" OpenBoot that is Forth. All current Macintosh systems boot from Forth in ROM. There are thousands of more examples such as these. Postscript is Forth, The Java Virtual Machine is indistinguishable from a Forth token interepreter. You really ought to get out and about more. To learn more about Forth, a reasonable online source is: http://www.forth.com/Content/History/History2.htm# 2.2

  19. So right by Ghoser777 · · Score: 2

    If he ever refused to hire somebody based on their inability to see color, I bet he'd lose in Court, lose bad too.

    Chuck would have to prove that the ability to percieve colors in MANDATORY to coding, which it is not. It's understandable that people in wheel chairs don't run marathons, because a prerequisite to running is having legs. The only prerequisite for programming is a brain that contain knowledge of the language and some way to relay thoughts. There's braile keyboards for th second, and I'm assuming the previous poster has a brain.

    If guys are successfully sueing Hooters to be able to work there (actually I haven't heard about this ina while, does anyone have an update?), then blind programmers could defintey when this case.

    F-bacher

    --
    James Tiberius Kirk: "Spock, the women on your planet are logical. No other planet in the galaxy can make that claim."
    1. Re:So right by Anonymous Coward · · Score: 0

      I think you misunderstand. It is required to see color to work with a language that requires color. It's not required for you to see color for languages that do not.

      If you disagree, don't use colorForth. Stop trying to make everyone else need a braile keyboard to get THEIR work done.

    2. Re:So right by Genom · · Score: 2

      If he ever refused to hire somebody based on their inability to see color, I bet he'd lose in Court, lose bad too.

      If it was for a generic programming job, I'd agree. For a generic job in *any* field, I'd agree.

      If he was hiring for a specific job, which involved programming in a language where color was a key element, it could be a stated requirement that the applicant be able to see color.

      In that case, I think he'd prevail -- simply because it's a stated requirement.

      The same as if there was a manual assembly line job that involved seperating piles of red and green items that were otherwise identical - I think that the job would, in part, require the applicant to be able to distinguish red from green.

      In a generic setting, the ability to see color has no relevance to programming -- but in certain niche fields or jobs, it might.

      As for the original poster - I'd be put off too, if I was in your situation. But it would only be a minor setback. Perl, C, and a myriad of other great languages don't require color vision (or any vision at all - although it might be hard to produce GUI apps without sight)

    3. Re:So right by Ghoser777 · · Score: 2

      Italics, bold, underline, superscript, subscript, etc could all be use as substitues for colors. This is not unreasonable.

      F-bacher

      --
      James Tiberius Kirk: "Spock, the women on your planet are logical. No other planet in the galaxy can make that claim."
    4. Re:So right by The+Panther! · · Score: 1

      If he ever refused to hire somebody based on their inability to see color, I bet he'd lose in Court, lose bad too.

      I applied for a job at Motorola back in '93. They had two open positions, one in the wafer fab and another in the test department. The fab meant wearing bunny suits and dealing with etch chemicals; the test department meant endless boredom and $2/hr less. I wanted the money, but I could not get the job because I am severely color blind (11/13 color plates failed) and it requires acid green scale reading to determine chemical grades.

      The morale of the story? Yes, you can "discriminate" between your employees based on their aptitudes, skills, and physical abilities if they come in direct conflict with their ability to perform the specified job. There's nothing illegal about it, and in most cases, is completely sensible.

      I was still miffed about the pay differential, though, and my inability to do the job that paid more. Such is life.

      --
      Any connection between your reality and mine is purely coincidental.
  20. Trinary by Water+Paradox · · Score: 3, Interesting

    Looks like my question was too far out there to get moderated up. Perhaps it's a lame question. I believe it's a solid question, so I'll pose it again, maybe some of you have comments:

    A trinary computer system is based on architecture which is much more efficient than binary, especially for moving large numbers around. Since you are designing your own processors, have you considered the possibility of building (and coding on) a trinary system? It seems like trinary eclipses the revolutionariness of even colorForth, by taking us into a whole nuther dimension of architecture...

    -WP

    --
    information is immaterial
    1. Re:Trinary by Christopher+Thomas · · Score: 2

      A trinary [trinary.cc] computer system is based on architecture which is much more efficient than binary, especially for moving large numbers around.

      Actually, to the best of my knowledge, trinary systems (and other systems with a radix other than 2) are not vastly more efficient than binary.

      Trinary logic is more complex to design than binary and requires more transistors. There's no substantial design time or area saving.

      If you're doing math, you'll also have larger roundoff errors using a radix larger than 2.

      Back in the olden days, computers were built to work in base 10 or base 16, or to work with multiple logic levels per line, but for these and other reasons, they finally converged on base 2 with two-level signalling.

    2. Re:Trinary by Anonymous Coward · · Score: 0

      Let's see, we could have hi, low and off? There used to be tri-state logic, but it was still binary; the third state was for reduced load.

      Yes, it's a good idea, and you would think that someone would be plugging away at it, but I've never heard even a rumor.

    3. Re:Trinary by Gordonjcp · · Score: 1

      There used to be tri-state logic, but it was still binary; the third state was for reduced load.



      There still is; the third state is not for reduced load, but to indicate that the output is neither high nor low, but has nothing useful to say (usually /ChipEnable is high)

    4. Re:Trinary by Water+Paradox · · Score: 1

      You may want to look again at trinary.cc; especially notice the accuracy of how a three-based counting system handles numbers bigger than 17.

      Trinary calculations are more like nature, and the calculations of fractions are more accurate than binary. The problem with roundoff errors you mentioned is offset by the fact that you don't have to roundoff so much, because trinary is better with moving larger numbers than binary.

      I didn't say it was the Windows of hardware design. I think it's fascinating, and something that real geeks might be interested in.

      The decision to move to binary, made in the late 1940s, was made at a time when memory switches were the size of a grain of salt, and if you listened closely, you could hear them clicking on and off... Yeah, I suppose I would choose a simple structure then, too.

      -wp

      --
      information is immaterial
    5. Re:Trinary by Water+Paradox · · Score: 1

      No. Why think about trinary systems with binary limitations? Use the third position to indicate something which is quality-based, instead of quantity-based. On, Off, and Vector. On, Off, and RSN. On, Off, and Quality. On, Off, and God. You can use your imagination to come up with ideas which are not limited to blacks and whites; give it some color, have more fun with it.

      On, Off, Purple.

      -wp

      --
      information is immaterial
    6. Re:Trinary by Ian+Bicking · · Score: 2
      I get the impression that this is 0, 1, 2 trinary. I think it would be interesting with -1, 0, 1 trinary numbers. I.e., if A=+1, Z=-1, and 0=0:

      1=A (1)
      2=AZ (3+-1)
      3=A0 (3+0)
      4=AA (3+1)
      5=AZZ (9+-3+-1)
      6=AZ0 (9+-3+0)
      7=AZA (9+-3+1)
      8=A0Z (9+0+-1)
      9=A00 (9+0+0)

      I don't know if this would be helpful, but it would certainly be interesting. And +1, 0, -1 seems less artibrary than a normal base-3 number system. It's intrinsically signed, too, since, for instance, ZZA=-11.

    7. Re:Trinary by Christopher+Thomas · · Score: 2

      You may want to look again at trinary.cc; especially notice the accuracy of how a three-based counting system handles numbers bigger than 17.

      I've read your page, and I'm having trouble seeing what you're getting at with this.

      If you're arguing that you can express more numbers with fewer digits, I would argue that this is of marginal use. You still have to manipulate your numbers, and as far as I can tell from your schematics, trinary arithmetic and logic circuits are not smaller (in silicon area) than binary circuits that could handle a comparable number of possible values.

      You might be able to save a bit of chip area by requiring fewer routing traces, but not very much, as you'd still require a similar number of control lines, and the number of data lines is reduced by only a factor of ln(2)/ln(3) = 0.63.

      Trinary calculations are more like nature, and the calculations of fractions are more accurate than binary. The problem with roundoff errors you mentioned is offset by the fact that you don't have to roundoff so much, because trinary is better with moving larger numbers than binary.

      This is pretty much the same effect as you noted in your previous point - you can represent more values with fewer digits (just with a different mapping than with integers). However, I again point out that this doesn't buy you much - the logic to _manipulate_ numbers to a given precision isn't any smaller, and might even be larger (I'd have to spend a little while mucking about with schematics to give you an exact transistor count for each).

      I didn't say it was the Windows of hardware design. I think it's fascinating, and something that real geeks might be interested in.

      It most certainly is fascinating. I've bookmarked your page, and might even try soldering together a trinary CPU together for fun at some point. However, I still do take issue with your claim that it's "more efficient" than binary, as I feel that the metric you're using to assess efficiency isn't a very realistic one (as discussed above).

      Thanks for the link, though. Your site was an interesting read.

    8. Re:Trinary by Water+Paradox · · Score: 1

      First, I need to be clear: It's not my page. It's a page I found while browsing the Internet for the concept, and found that it has the best information yet. For example, D G Leahy has some interesting work with trinary calculations, way over my head.

      I'm clear to say that it is not my page for this reason: the engineer who commented on Chuck Moore's 'fanaticism' which made him uncomfortable (another post on this same topic), has exactly the kind of attitude that keeps true innovation from gaining ground. He uses the tools designed by fanatics only after they have become popular, yet actively expresses "discomfort" because of the work of a fanatic in process.

      Associate a brilliant idea with a 'fanatic' and the idea will not be considered seriously for a long time. Yet where else do brilliant ideas come from?

      That being said, I pointed people to trinary.cc because I find it interesting. Somebody named Steve Grubb seems to have put it together.

      As to your other points; I see they are valid, and that the way to let other people consider a trinary system is not to rely on loaded words like "efficient."

      As for me, I've been studying trinary logic in a form that has nothing to do with computers, and find it to be, in practice, more efficient and more stable than binary logic. Thus my attraction to the idea of building a trinary system in the first place. While the actual hardware (routing traces, whazzat?) is presently beyond me, the concept of thinking with three strands of thought rather than two is compelling to me.

      For instance, I have been diagnosed as a person with bipolar illness. Given some thought, I realized that the name "bipolar" comes from a whole mindset that is itself bipolar, or categorical.

      I prefer the term "tripolar" because it is more accurate in description--not only of my personal experience, but of what other people see me going through. Sometimes I'm manic. Other times I'm depressed. Is that all? No, actually, most of the time, I'm pretty 'normal' and that plateau is entirely lost in the nomenclature for "bipolar disorder."

      I hope this helps explain what I mean by more efficient. It may require the same amount (or more) hardware to implement, but it will create an assembly language which is fundamentally different than binary systems.

      Of course, we can overlay binary concepts on the trinary system, and I'm sure others will do that.

      As for me, I'd like to start with the raw CPU you mentioned, built with a soldering iron, and design programming concepts upward from there, putting aside all binary concepts. I've a hunch we'll find that trinary systems are roughly the same as binary at the hardware level, but much more liberating at the software level. And that's what I'm interested in. I'll build my own hardware to get to that point, if I have to... and that's why I'll get to that point, even though I know little about hardware.

      Thanks for listening.

      --
      information is immaterial
  21. Re:Stephen King, author, dead at 54 by Water+Paradox · · Score: 0, Offtopic

    Probably similar to the reason I think it's very funny that YOUR post could accurately be applied to the content of many slashdot posters. :-)

    --
    information is immaterial
  22. i can't believe you! by Anonymous Coward · · Score: 0

    i can't beleive you douchebag morons who upvoted
    this troll whore! oh wait, i forgot you moderators all worship perl, so its okay to say "(any.language.but.perl.here) sucks!"

    1. Re:i can't believe you! by Anonymous Coward · · Score: 0
      uhhhh...
      1. Chuck does kinda come off here as a "if the only tool you have is a hammer" zealot.
      2. at least he doesn't feel the need to force Forth down our throats, though.
      3. Lisp, APL, Forth & Perl are just as well suited for writing unmaintainable code.
      4. I like ordered lists, they make me look like I have a coherent thought process, and therefore am better than most slashbots.
    2. Re:i can't believe you! by Anonymous Coward · · Score: 0

      this is sincerly one of my favorite post for a long time. great laugh here, thx :-)

  23. You don't _have_ to use ColorForth to code w/Forth by Svartalf · · Score: 2

    There's tons of other Forth dialects that actually meet his criteria of being a true Forth- and they run under every OS out there from DOS all the way to Linux.

    ColorForth is his implementation of his idea of what Forth should be for him. If you can use it, fine. If not, find another Forth- I'm sure there will be other implementations that code for the x25 CPU at some point. People aren't using Strostroup's implementation of C++ or K&R's implementation of C either- for that very reason.

    Go hit Taygeta Scientific's website for implementations of Forth that you can try out. For Linux users, I suggest BigForth from Bernd Paysan, BTW- it's a native code generating implementation with some GUI support that shows some promise for making usable apps, etc.

    --
    I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
  24. However... by jd · · Score: 1, Offtopic
    It was later discovered that he gets resurrected in the sequel, due out tomorrow.


    DUH! This troll has been around for a while. Why can't the terrorists have blown them up, instead? At least it would have produced one positive outcome.


    Please, if you read a public weblog, like Slashdot, K5, etc, you are going to get a LOT of bogus "reports", trolls, spam, hate-gunk, etc. When reading, the important thing is to look at the source, and even if the source is "trustable", see if there's anything confirming the claim elsewhere.


    I'll use myself as an example. Before the karma cap, I had reached 720 points, with a typical increase of around 10 karma/week. At first glance, that's a fairly respectable total. On the other hand, when you realise I can easily reach a figure of around 40 posts in a week, a more accurate picture emerges. An average of one point of karma for every four posts, which works out to two points for every eight posts.


    In other words, for all my "impressive" total, I was still only writing stuff that people found to be interesting, useful AND verifiable, only one time in eight. That leaves seven times in eight that my information is either of little worth or just plain wrong.


    So, if I can be wrong 7 times in 8, so can anyone else. THAT is why you need to verify. If you can't find two genuinely independent sources who say the same thing, then you probably want to treat the information with suspicion. Ideally, you want three or four, before accepting even a single thing.


    Of course, there are going to be real innovative thinkers, who see things that others can't. But you still should check. In this case, you might want to find out their reasoning and see if it makes sense. The old adage that "truth is beauty" is usually worth keeping in mind. Crick & Watson "discovered" DNA by simply building models until they had one that was beautiful. Actually figuring it all out never crossed their minds.


    The same is true with any "innovative" thinking. Where you just can't check the reasoning, don't have the time, or knowledge necessary, simply look to see if it has an inner beauty. If it does, there's probably -something- to it. If it doesn't, it's most likely waaay out there.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:However... by Anonymous Coward · · Score: 0

      what the hell are you talking about?

      misplaced post I guess.

    2. Re:However... by Anonymous Coward · · Score: 0

      I dunno, the acclaim of the great body of your peers would brand you as understandably mediocre, not brilliantly insightful.

      Albert Einstein was severly bitchslapped for years until the world finally caught up with him.

      Apparently what you should look for is some poor schlub that occasionally gets a few positive moderations, but must of the time is stomped under foot by the tyranny of the slashbots. Like me!

  25. this guy is on crack by jasno · · Score: 2, Insightful

    "There is no hardware protection. Memory protection can be provided by the access computer. But I prefer software that is correct by design."

    That statement alone should point out that this guy has no clue about real world software design. People make mistakes, big ones, and they're not always caught in the debug cycle.

    He sounds like a real smart guy, who's written alot of cool things ON HIS OWN. Once you break out of the individual 'hacker' environment and have to teach and share with others, alot of this stuff falls apart...

    --

    http://www.masturbateforpeace.com/
    1. Re:this guy is on crack by Anonymous Coward · · Score: 0

      "
      That statement alone should point out that this guy has no clue about real world software design.
      "

      That statement alone should point out that you
      have no clue about how not to be a douchebag
      troll whore.

      "
      People make mistakes, big ones, and they're not always caught in the debug cycle.
      "

      And then they get fixed. I suggest you get 'fixed', douchebag troll whore.

    2. Re:this guy is on crack by tb3 · · Score: 2
      I agree. His comment sounds similar to a comment I heard an OS/2 zealot make years ago. He was talking about the single-threaded nature of Presentation Manager and said that if everyone wrote perfect programs PM would never lock-up. I asked (rhetorically) how likely he thought that was. I'm still waiting for an answer.


      Honestly, have you ever seen anything but the most trivial program that was "correct by design"?

      --

      www.lucernesys.comHorizon: Calendar-based personal finance

    3. Re:this guy is on crack by William+Tanksley · · Score: 2

      He's worked with a lot of teams as well. Memory protection is NOT a way to get bugs out of your system (that's STUPID; there's no protection inside a process); rather, it's a way to emulate an air-gap between programs (in other words, for security). When you have multiple processors for that cheap, it's far more secure to just set up a seperate processor.

      -Billy

    4. Re:this guy is on crack by sigwinch · · Score: 2
      When you have multiple processors for that cheap, it's far more secure to just set up a seperate processor.
      Let's see, how many processes do I have running?

      $psax|wc-l
      82

      So I'm supposed to have 82 processors on account of having 82 processes that might become runnable at any moment? What about shell servers with hundreds of simultaneous users? Lack of memory protection is just ludicrous, it's so not-real-world it isn't even funny.

      And as far as being more secure, that's ludicrous too. A functioning MMU is just as secure.

      --

      --
      Kuro5hin.org: where the good times never end. ;-)

    5. Re:this guy is on crack by Kalani · · Score: 1

      I asked (rhetorically) how likely he thought that was. I'm still waiting for an answer.

      Why are you waiting for an answer if it was a rhetorical question?

      --
      ___
      The ends are ape-chosen, only the means are man's. -- Aldous Huxley
    6. Re:this guy is on crack by William+Tanksley · · Score: 2

      Your incredulity shows your almost unspeakable insularity. Your use of a Unix-based, system-specific command to provide evidence against me is solid proof of that insularity.

      Not all the world is a desktop or workstation. Not all systems run Unix. This will ALWAYS be true, because Unix isn't appropriate for most systems.

      Yes, lack of memory protection is entirely inappropriate for systems with a variable number of multiple users. But it's entirely appropriate for users with multiple systems. Chuck's chip is supposed to cost $1 in production quantities. One dollar for 25 processors. I tell you one thing for sure: I'm not sharing mine with anyone else. I may even buy the x36 or x49 or x64. Chuck thinks he might even be able to stretch it up to 100 chips on a side, for ten thousand processors on one chip (although the resulting chip will be as big as a Pentium III).

      What would you run on this? I see you're wanting to run Apache and Beowulf. I think that's stupid; those are designed for desktops. I'd want to run neural networks and simulated annealing. I'd want to build a wristwatch which can transcribe to ASCII all speech which it hears, with identities for the seperate speakers. I'd build a PDA which recognises commands and takes dictation subvocally (in other words, it reads lips).

      The applications for this kind of power and speed are astounding -- even with only 256K of memory and 18-bit processors.

      Ah, I bet you didn't notice that, did you. 18 bit! 256K address space! Total. ALL of the processors share that 256K. That's tons of elbow room for a fixed-purpose system (although not enough for many algorithms; reimplementing Deep Blue will have to wait until Chuck simulates at LEAST a 24-bit chip).

      Seriously, can you see any point in memory-protecting a system with a total of 256K of memory?

      -Billy

    7. Re:this guy is on crack by sigwinch · · Score: 2
      Your incredulity shows your almost unspeakable insularity. Your use of a Unix-based, system-specific command to provide evidence against me is solid proof of that insularity.
      I also design logic for FPGAs and design systems that incorporate microcontrollers. I am fully aware that there is a place for simple chips that pack a lot of bang for the buck, and that the software/firmware/logic for them is narrowly tailored for specific jobs.

      So it is valid under some circumstances to say "an MMU is not good". However, Chuck Moore makes all sorts of statements like that one *as general laws*, which really squicks me. E.g., this page which says "The word */ multiplies by a ratio, with a double-length intermediate product. It eliminates the need for floating-point." Eliminates. Not "eliminates fp when you have a known and small dynamic range", but "eliminates". This has got to be one of the stupidest things I've ever seen. Another example: This is Chuck "Yes, that's all it takes." Moore's IDE driver. Puh-leeze. It's the "Hello World" of IDE drivers. It does *nothing*. No DMA. No locking for running on SMP machines. No autodetection and adaptation to drive capabilities. No workarounds for chipset bugs. No blacklisting of drives that are buggy. If you want to play in the real world, you need code like this (the Linux IDE driver).

      Look at this page where he says "With the huge RAM of modern computers, an operating system is no longer necessary, if it ever was." Idiocy, written by a person who has never designed a system of significant complexity. RAM has *nothing* to do with whether an operating system is needed: it has everything to do with complexity. E.g., the only sane way to use floppy, IDE, SCSI, flash, CD-ROM, and network-mounted drives in the same system is to have a generic drive-access layer. Then you'll add a generic removeable drive layer to support things like CD-ROMs and flash drives that might suddenly disappear. If you want to support tons of hardware and software, you have to have an operating system.

      This page is *full* of idiocy. "Don't try for platform portability. Most platform differences concern hardware interfaces. These are intrinsically different. Any attempt to make them appear the same achieves the lowest common denominator. That is, ignores the features that made the hardware attractive in the first place." Except, of course, for the usual case where the hardware has an upgrade that is easy to turn on and use, and which hardware is available is not known until runtime.

      --

      --
      Kuro5hin.org: where the good times never end. ;-)

    8. Re:this guy is on crack by numbnutz · · Score: 1

      Rather than Crack, silicon appears to be his crystal of choice. Actually, Chuck Moore's position is that "real world software design" is seriously flawed because it encourages modular complexity well beyond the "seven plus or minus two" cognative limits inherent in humans. He prefers a more atomic, hieracally testable approach where reuseable, tested and trusted code fragments converge on the solution through ascending scope. A revolotionary concept, given the current "real world software design" hedgemony. Newton, Pasteur, Darwin,and Einstein had similar ideas. Remember, this man wrote his own CAD system from scratch (all bits set with his hands) that has produced the physical masks (pixel maps) that have been used to fabricate the dice for his processors. After writing assemblers for more instruction sets than any man alive, he has spent the last 20 years coding in silicon.

    9. Re:this guy is on crack by Anonymous Coward · · Score: 0
      Try to have an open mind. Not all systems need to be of the C/Unix variety.


      You give an example of Linux IDE code. It is true the colorForth example is simplistic, and I can't comment on it's robustness. However the philosphy of colorForth is that you only keep around the absolute minimum code needed. So for a particular set of hardware you only have the code that drives that hardware. Linux needs the code for all possible possible devices because of the static nature of C, and failing to boot from the hard disk is not an option. Therefore Linux must support all options and continue to expand as new hardware and new incompatabilities arise.


      colorForth in contrast is a dynamic system. Source code is the native representation, and object code is recompiled on demand. Compilation takes no discernable time. Theorectically a colorForth system should be able to reconfigure itself to meet the demands of the system at boot. Non-essential device drivers and applications can be downloaded from a network to suit the user's needs.


      In addition to this fact, programs written in colorForth are naturally much more compact. Forth lends itself to factoring much better than other languages, which can lead to the most compact solution for a given problem. The entire colorForth system is less than 64k! While it is still possible to write bad code (as is true for any language), you will not see this in core of colorForth as it is written by the creator himself. Stylistically you don't see this level of quality in the Linux kernel.


      A lot of your reply is based on the assumtion that colorForth is a static system. You will see that most of your concerns disappear with realization that colorForth is a dynamic system.

    10. Re:this guy is on crack by BruceMcF · · Score: 1

      First, for low priority threads, you can compile them in a bullet-proof Forth that does not allow access to memory it has not allocated or alloted. That will take care of a good number of 80-plus process right away.

      Second, for high priority threads, you have processes that own their own processors ... and own their threads. A direct connection that multiplexes memory access coming from processor #5 to the fifth 256K bank is harder hardware memory protection than traditional hardware memory protection.

      Of course, Chuck said this, but he said it in very few words, so people used to reading fast are likely to miss it.

  26. Re:till your country gets flattened by Anonymous Coward · · Score: 0
    like smart bombing?

    oh, the bravery of being out of range...

  27. EROS by kip3f · · Score: 2, Interesting

    I don't know where your comment about EROS comes from. EROS stands for Extremely Reliable Operating System, and has cool stuff like transparent persistence for all programs and a pure capability security system. EROS was built from the ground up to run on commodity Intel boxes. The OS is not ready for prime time because it is being re-written in C (from C++). It is GPL'ed, and it has mucho potential.

    --
    ****Gfx Scrollbar Special case hit!!*****
    1. Re:EROS by On+Lawn · · Score: 2

      You are very right. One of my favorite features is that it doesn't use a "file-system" per-say. I assure you that although I'm not active on the mailing list, I've been monitoring it since 1997.

      My comment comes from Jonathan Shapiro's comment about his own OS sometime about when it was GPL'ed. In short he mentioned that hardware had a lot of catching up to do with his OS.

      I believe it came in response to a thread on how to deal with the "capabilities" (I'm assuming you know how they use that term) of modems and other peripherals. I remember the quote going something like "It will take years for hardware to see a need and implement it."

      As another note, if you look at the v2.0 logs you will notice a long essay on why he is finnaly implementing a malloc. Essentially becuase of, [...drumroll...] braindead hardware design.

  28. goatse.cx new homepage by Anonymous Coward · · Score: 0

    We, at Goatse.cx, mourn the unprecedented loss of life on Tuesday, September 11, 2001.
    __________________________________________________ _______________

    [ the receiver ] [ the giver ] [ feedback ] [ contrib ]
    __________________________________________________ _______________

    Let it be known terrorists, YOUR ASS IS NEXT!

  29. Re:Stephen King, author, dead at 54 by Rudeboy777 · · Score: 1

    As others have pointed out, this is a notorious troll. However, I'm a big Dark Tower fan too and didn't know about this until 2 weeks ago (maybe you haven't seen this either?) It's the prologue to his next Dark Tower book. Sounds like a really cool story too, although like the last one, it won't advance the main plot too much.

    --

    From hell's heart I fstab at /dev/hdc

  30. You often don't need anywhere near as many lines.. by Svartalf · · Score: 2

    1+ million line programs do NOT mean useful complexity- in fact, one should question the application that actually needs that many lines of code. Furthermore, many people lump the lines of code together in a system, artificially inflating the numbers- almost a "my system's bigger and better than yours" competition.

    Also of note is that few people have attempted to make a "500 user concurrent database"- ever. Have YOU ever written one? If not, why are you wasting your time posting here when you should be out flogging your product in competition with the likes of IBM, Oracle, etc.? I'm pretty sure if someone wanted to, they COULD make one in Forth (as there HAS been relational databases written in Forth...)

    And his answer would be right for that- he doesn't need one for the problems he's solving. Doesn't mean someone else couldn't do it- it just means someone hasn't come along using Forth to do the task in question.

    And in answer to your webserver question, it's very likely that nobody coding in Forth has gotten around to doing a Webserver as most of the people using Forth are doing embedded systems that don't have network connectivity, etc. If there was one, he might be using it.

    Just because nobody's using it for that task doesn't mean that your choice is better for the task or that the language in question is poor for the task. Icon, a string and symbolic programming language from one of the inventors of Snobol is an ideal (as in, much better than C or C++) language for making compilers- nobody's using it because it's not well known and everybody and his dog follows the crowd and uses what everyone else is using.

    --
    I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
  31. APL Accounting System by kgrgreer · · Score: 1

    I've seen a complete accounting system written
    in APL. I've also seen a complete banking system
    also written in APL and deployed across tens of
    small finanical companies and hundreds of sites.
    Both worked well.

    1. Re:APL Accounting System by Anonymous Coward · · Score: 0

      The question is not whether you can, it's whether you should.

    2. Re:APL Accounting System by humblecoder · · Score: 1
      I worked in the insurance industry for a number of years, and apparently APL is quite popular in insurance applications because of its compact handling of vector and matrix arithmetic. While powerful, I found that APL programs were very frustrating to understand and to maintain. Because of APL's compact and cryptic syntax, it took a lot of time and effort to figure out what a particular routine was doing. Combine that with a lack of good documentation, and you had a recipe for disaster!

      APL makes C programs look downright verbose. At least in C you can make a program readable if you try. In APL it is downright impossible!!!

    3. Re:APL Accounting System by Anonymous Coward · · Score: 0

      People say the same sort of thing about Perl. I've heard VB and COBOL "developers" say the same sort of thing about C.

      Thing is, if you spend as long learning APL as people spend learning C (and it helps if you've actually got an APL keyboard, though they're damn near impossible to find these days), then most APL programs will look quite readable and sensible, particularly if you were already a mathematician or engineer.

      What you learn first has a great influence on what you think of what you learn next.

      Excessive commenting is BAD, in my book, the code, to someone who knows the language, should be documentation in itself. APL's symbols were easy for me to understand, since they're mainly derived from symbolic algebra most people learn in high school.

      When I'm coding in C, I follow a simple rule: One block comment per function. If I find myseld putting in other documentation, then my variable names and structure are probably not clear enough.

      Java javadoc actively encourages similar practice for methods and classes, and since java class names are always long and descriptive, you are seldom tempted to put in any comments that javadoc wouldn't pick up on - basically, in Java, if you're writing more commentary than javadoc normally picks out, then you're over-commenting, and your code itself probably isn't clear enough.

  32. A man who doesn't care... by Midnight+Ryder · · Score: 4, Insightful

    After reading the results of the interview, I really like Chuck Moore. Why? Simple - he's got a language he likes and develops further for his needs when nessisary, and when it comes to what everyone else thinks, he doesn't care!


    That's not nessiarily a bad thing, in some ways. How different would colorFourth be if, for instance, he stopped to consider the effect on color blind or blind people trying to use the langauge? What about if he stopped to concern himself deeply with how to get colorFourth to become accepted as a mainstream language?


    Instead, he concentrated on creating something he felt was the perfect language for him - not really for anyone else. There's something very admirable about that. Seems like projects these days (I mean Open Source projects in particular - commercial projects obviously tailor to as many people as possible) end up giving up part of thier original focus to instead appeal to a much broader audience within thier application style grouping. He doesn't care about how (x) implemented (y) - if it doesn't fit the applications he's been working on, then he ain't adding it in.


    On the flip side, that means that colorFourth, for instance, isn't going to get a whole lotta acceptance. His comment about blind programmers struck me as callous, but, what the hell - it pretty much comes down to being 'his personal language'. If that's how he treats is, then yeah, to program in colorFourth (Chucks personal language) then you have to either learn to adapt it yourself (font changes for color blind people, or possibly tonal changes for those who have the source read to them by text to speach programs.)


    But the one comment that struck me as wrong was his thinking that the reason more people don't use it is a matter of conspiracy. *SIGH* No, Chuck - if you build a language and tailor it pretty much completely for yourself, well... who the heck is gonna really care that much since you dont?


    --

    Davis Ray Sickmon, Jr - looking for something to read? Check out my three free novels at MidnightRyder.org

  33. Quibble about lambda and parallelism by alispguru · · Score: 2
    The lambda calculus is not inherently sequential, and languages based on the lambda calculus can be massively parallel in execution, just by using simple tricks like evaluating the arguments. The ideas have been floating around for decades - they boil down to:

    Functional, side-effect-less programs and primitives

    Parallel evaluation of arguments

    Parallel evaluation of mapping primitives

    See here for a recent reference.

    --

    To a Lisp hacker, XML is S-expressions in drag.
    1. Re:Quibble about lambda and parallelism by osu-neko · · Score: 1
      Functional, side-effect-less programs and primitives

      A side-effect-less program is a program that doesn't do anything. Fun research tool, but actually useful programs cannot satisfy this requirement, and thus lambda calculus returns to being effectively sequential...

      --
      "Convictions are more dangerous enemies of truth than lies."
    2. Re:Quibble about lambda and parallelism by Anonymous Coward · · Score: 0

      Wouldn't it be more sensible to just use the Pi-calculus? After all, (a) It was designed specifically for handling concurrency in mathematical terms, and (b) The lambda calculus is an "easy" special-case derivation from it? There's even a programming language, Pict, that is to Pi-calculus as ML is to the Lambda calculus...

    3. Re:Quibble about lambda and parallelism by Dwebb · · Score: 1

      Has the Pythagorean Theorem ever been useful to you or anyone else? I thought so. It's a math equation that, when solved for one variable, is a math function and is therefore side-effect-less. And it definitely DOES something -- it calculates the distance between two points on a grid -- but somehow without imperatives.

      Furthermore, many of the C/C++/Java functions you write are side-effect-less, and yet are still useful to you.

      Don't be fooled by the widespread belief (at least in the software world) that a language must contain imperative statements in order for it to "do something."

      Everything can be expressed functionally. You just have to realize that everything has inputs and outputs. The computer science world just hasn't brought a pure functional language to the mainstream yet. But they're making progress. See Haskell (http://www.haskell.org) and Clean (http://www.cs.kun.nl/~clean/) for the two best examples I'm aware of. The Clean team has even built an IDE for Clean, in Clean itself. Now that's what I call "doing something."

      As for the Lambda Calculus being sequential, I don't understand why you'd say that, or how you'd come to that conclusion from your previous statements. The LC is as sequential as the functions that are composed out of it, which is to say, highly parallelizable. It's up to the implementer to decide how much parallelization to do.

    4. Re:Quibble about lambda and parallelism by Dwebb · · Score: 1

      The Lambda Calculus is certainly the path to parallel programming, as well as programmer productivity and reliable software. Too bad many (most?) programmers have never heard of it.

      I'd like to hear Mr. Moore make a similarly succinct statement of how Forth programs can be parallelized.

  34. Well.. by mindstrm · · Score: 2

    Boldface, Italic, and Roman *ARE* appropriate analogues, he already made reference to that.

    Also.. I think what's he's saying is, why should everything on earth cater to the lowest common denominator? It shouldn't.

    You don't need 20/20 vision to fly a plane. if you want to work for the Air Force in particular, to fly their jets, you have to have perfect vision. Period.

    So.. if you want to work with Color Forth, as he implemented it, you need to be able to see colors. I fail to see how this is bad.

    Everything relating to computers does not need to be built for the lowest common denominator.

    1. Re:Well.. by Jeremy+Erwin · · Score: 2

      Hmm.
      I don't really think that designing a language to be accessible to the blind or the color blind is catering to the "lowest common denominator".

      Theoretically, the main requirement for a programmer is a brain. Everything else is secondary. One can argue that a fast computer is nice, and good compilers are also helpful.
      Vision really doesn't enter into it.

      ColorForth is a personal language designed to fit the personal quirks of its creator. That personal fit also makes it less useful as a universal language.

      As for the jet fighter analogy-- it is much harder to design a jet fighter that can be flown both effectively and safely by a nearsighted pilot. that it is to design a computer language accessible to the color blind.

    2. Re:Well.. by BruceMcF · · Score: 1

      Excellent argument. However, since it is based on a false premise, the conclusion does not stand.

      As people have been saying repeatedly, there is absolutely nothing in the design of ColorForth that requires color. Rewrite the editor and you can have a "ColorForth" that uses richtext or tone of voice or whatever. With 100% identical precompiled source in the original format.

      The language is in fact accessible by design. The pilot implementation is not accessible, but if you toss out everthing that is accessible by design because it wasn't accessible in its first pilot implementation, how much of modern technology will you be left with?

  35. Not everyone has to be a programmer by justinstreufert · · Score: 1
    20-20 vision is required for fighter pilots. I have no qualms about requiring color vision for programmers. Everyone does not need to be a programmer

    Yes, but the set of people who want to be programmers and the set of colorblind people are NOT the same.

    I am a colorblind programmer. I program in C, PHP, and Perl regularly. I have no qualms with users that, endowed with color vision, enhance their programming abilities by using colorized editors. My coworkers, who all use syntax highlighting, come to my black and white display and squint at the screen, almost unable to read the code displayed.

    However, the sentiment embodied here is truly ugly. I mean does this guy have any idea how frustrated potential fighter pilots feel when they are struck down by their imperfect vision? If you want to fly a plane to defend your country and ideals, the inability to do so caused by an imperfection beyond your control would be devastating.

    There are a myriad of alternatives. Even within Forth it would be possible to represent the structures currently shown as color with other types of highlighting. Moore, get a clue.

    Justin

    --
    "Why would God give us a waist if we wasn't supposed to rest our pants on it?" - Rev. Roy McDaniels
    1. Re:Not everyone has to be a programmer by Anonymous Coward · · Score: 0

      Chuck may have been a bit imperious in his commentary about colourblindness, but there's no reason to get your shorts in a knot.

      Instead, see it as a call to arms, if you see incentive enough to do so. If you understand enough about why Forth and more importantly, Color Forth is important, then you can change his color paradigm for another of your own choice - be that sound or font or grayscale or whatever you choose, as it appears you already do.

      But, if you don't see the value in his paradigm, then it is not worth shouting about. Pursuit of your own paradigms and your unique attributes is a more worthwhile action than demeaning the tightly focused actions of others. By such action, there is even a chance you show CM a constructive way forward, encompassing your own circumstances.

      FWIW,

      Arnim.

  36. Jon Katz journalism?? by Anonymous Coward · · Score: 0

    ___....---"""".
    ." ". J \
    / \ o i
    i i i
    i__ _ i N i
    " "\\ i i
    || i i
    __.// i _ . - "i
    \ i- " i
    i ii K i
    \ / i i
    "._.--"i a i
    i i
    i t i
    i _i
    i z _.-"
    i _.-"
    i-"

    SCREW YOU KATZ

  37. Forth is relevant? prove it! by studboy · · Score: 1

    I admire Forth, it's a fascinating language. But would I consider it for a project, even an embedded one? No way!

    "Languages are evolving, as evidenced by the new ones that arise. But as with natural evolution, the process is not directed." Mr. Moore notes. He missed the fact that evolution *is* directed -- anything that survives, flourishes. LISP, Forth, and C have a very long history, but the C-style syntax has completely dominated the development of new languages, including C# and Java. Why? Because it's easier read, easer to write, easier to develop with.

    When I have C questions, I have gazillions of code samples to borrow and learn from. (cf: http://www.codecatalog.com/ ) There are multiple sites devoted to Perl. PHP. When developing with Forth I get a "not invented here" kind of thing: each of the few, small libraries available is customed to a specific home-grown flavor of the language. Yes, I can write my own this or that, but *why*?

    I'm interested in amateur robotics, for which Forth might be perfect. But what do I see? Nearly 100% of robots are written in 1) assembly, 2) BASIC, or 3) C. Assembly is of course specific to each chip, and totally nonportable. BASIC is readable, but only somewhat reusable: each flavor of BASIC is incompatible. C immediately rises to the top -- even if I have to write all the libraries myself, the *language* doesnt change from underneath me.

    Mr. Moore's inventions deserve attention for their audacity in completely upsetting the status quo. If his approach is superior, if he is uninterested in the other 100% of the software world to follow, fine. But where are are all of Moore's beautiful chips? Applications? Where are people using Forth on other machines?

    Show me!

    - j

  38. They took the fun out of Forth by Waffle+Iron · · Score: 2
    I recently downloaded GNU Forth out of curiosity. I hadn't played around with it in over a decade, but I always thought it was a lot of fun to program in Forth.

    I soon noticed what looked like a cool new feature: named function parameters. You can now access stack slots by name instead of always juggling the parameters with operations like DUP, ROT, SWAP, etc.

    After using this new capability, though, I realized that much of the fun of writing Forth code is figuring out clever ways to juggle the stack. Using named parameters makes the language kind of boring, combining C's explicit memory management headaches with the performance questions of an interpreted language.

    I guess I just never got deep enough into the Forth ways to take much advantage of the magical "extend the language with itself" capabilities. OTOH, Lisp can do some of these tricks and provides automatic memory management.

    Oh well, my favorite language this year is Ruby, anyway. It brings together a lot of good concepts from other languages in a nice way that's easy to understand; it even has a little bit of the extensibility that Forth exhibits.

  39. Compiling to threads by Windrip · · Score: 1

    PDP-11 BASIC+2, VAX FORTRAN (and probably other languages from DEC) were compiled to threads of the language run-time system. VAX/Alpha object language is a stack-oriented language.

    Threads are an enormously powerful tool for compiler writers. They allow one to emit consistent sequences (idioms) from a "ridiculously" easy front end.

    At run-time, the loader transfers control to the familiar indirect loop, which gnaws through the "object" code.

    One of the pure charms of programming was to see the PDP-11/VAX/Alpha FORTH inner interpreter.

  40. WTF?!! by Anonymous Coward · · Score: 0

    Why the hell are all you low UID slashoids coming out of the woodwork and mouthing off all of the sudden? I tell you, it's worse than a plauge of trolls -- at least the trolls are occasionally amusing. Now pipe down before we carpet troll you like Bush II is gonna do to Afghanastan!

    1. Re:WTF?!! by BruceMcF · · Score: 1

      Is it surprising that there would be a number of Forth users of one sort or another on slashdot? Don't forget that Forth was a public domain language/operating-systems for a lot of personal computers down to Commodore 64's, Apple II's, and TRS-80's. And that forth is part of the Gnu stable of languages.

      We mostly stay quiet and read, but its just not possible to read some of the nonsense people come up with about Forth and stay quiet!

  41. Re:You often don't need anywhere near as many line by Phaedra · · Score: 1

    A Forth web-server can be found at http://www.jwdt.com/~paysan/httpd-en.html.

    Sorry, I can't get past the lameness filter for links because I'm stoopid.

  42. Re:Forth is relevant? prove it! by mirko · · Score: 2, Insightful

    > Forth is relevant? prove it!

    Forth is everywhere.

    Look in the Solaris kernel repository, there are even Forth source code.

    The Java virtual machine is a specific Forth-like implementation.

    Even Postscript looks like Forth enough to claim its legacy.

    You should rather demostrate us that this obviously useful language does *not* exist, instead of trolling...

    --
    Trolling using another account since 2005.
  43. Maintaining APL is not hard, just learned by Jayson · · Score: 1

    I am not speaking directly about APL, but more about its successors: J and mostly K. I used to think it was hard to stare at a page of K, but after programming in it for a few months, I find it very hard to look at Java code. Code compaction allows the programmer to get the big picture in one page of code. I do not need to constantly flip between multiple pages of code to determine what it happening. I have found myself not using bookmarks or tags in code. Just as you became trained to stare at C-like statements, you also become trained to look at APL/J/K sentences.

    There are some very powerful ideas in the APL family. The ability to read code like prose, where each symbol on the screen has an english equivalent (e.g., the "," operator is pronounced join). I was very sceptical when my roommate showed me one of these languages, K, but soon we were deubugging incredibly complex functions but just speaking the phrases aloud. For example, in K:

    x is the default first argument to a function
    x is is used here as a vector
    x is pronounced x

    + is pronounced plus
    / is pronounced over
    # is pronounced count
    % is pronounced divide

    "(+/x)%#x" is pronounced "plus over x, divide count x"

    Even more powerful is how idioms are built from this. This is what is referred to as building your vocabulary:

    "+/" is also pronounced sum
    "(+/x)%#x" is then pronounced "sum x divide count x"

    the whole construct is is really average.

    : is pronounced is or gets
    * is pronounced times

    "weighted_average:{(+/x*y)%+/x}"
    is pronounced "weighted_average is sum x times y divide sum x".

    Yes, you can abstract it away as a function in this very simple example, but the point is more of how powerful idioms can be and how you build your vocabulary, especially, when interacting with people across the room. Compare this to the C equivalent:

    [not shown; censored by lameness filter; wtf?]

    I am very new to this whole APL/J/K thing, so things are probably a bit off.

    In the C-like languages idiomatic exblockquotessions are not nearly as clear. I only have a 19" monitor, so I use K to make my monitor a JumboTron.

    -j
    1. Re:Maintaining APL is not hard, just learned by osu-neko · · Score: 1
      Uh huh. People always complain about such and such programming language being "too hard to maintain", and when pressed they say it's "too hard to read the code". I get this from a couple of my coworkers a lot, since I code a lot of stuff in LISP-derived languages. I used to find this puzzling, since LISP is a heck of a lot cleaner and clearer than the C++ they favor. But I figured it out:

      Any language you actually use is easy to read, understand, and maintain. Any you don't use as often is harder to read, understand, and maintain. It has nothing at all whatsoever to do with the language, it has to do with the user.

      Except Smalltalk, of course. That really is hard to read or maintain. ;)

      Jokes aside, though, I always find criticisms of any language as "hard to read" or "hard to maintain" curious. It's obvious that the critic in question simply isn't familiar with enough different languages to have realized this is never a valid complaint against a language, it only speaks of your own unfamiliarity with it...

      --
      "Convictions are more dangerous enemies of truth than lies."
    2. Re:Maintaining APL is not hard, just learned by WNight · · Score: 2

      Well, I think you can do things in any language that make it harder to read, regardless of the skill of the developer.

      For instance, put a space around entire concepts

      Instead of "x/y+r^2" do "x/y + r^2", it's like using paragraph breaks in english text.

      And then there's regexps, they're built on small parts, but when you get into something complicated (like removing c++ and c style remarks, in the same expression) it starts to look at little greek. This is, imho, because the same series of characters, in a slightly different order, can mean something else.

      Like how [abc^] is a|b|c, but [^abc] is !(a|b|c). Combine that with a really long expression, especially when you're using $1 type reference to things you already found.. Ugh.

      (\/\/|\/*) Really, what does that do?

      But, that can be aided incredibly by how you write it as well, especially with the x (?) flag, to let you use whitespace (in Perl, at any rate).

      Anyways, a bit OT, but I needed to gripe. :)

  44. How about a few applications... by Svartalf · · Score: 2

    An international airport in Saudi Arabia...
    The collision avoidance system on the Space Shuttle...
    The first pocket language translator...
    Numerous Atari console games...

    Some of these used a Forth implementation for a given CPU, one of them uses a special chip that was built by Harris Semiconductor, the RTX2000, one of the first Forth chips.

    Forth is not used not because it's worse or not-useful. Forth is not used because it's so different from just about everything else developed to code for computers.

    --
    I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    1. Re:How about a few applications... by Anonymous Coward · · Score: 0

      Those applications are ancient (70s - 80s). How about something recent?

  45. Have you ever crashed 2500 computers? by Anonymous Coward · · Score: 1

    no, but give me a week to learn visual basic and i could try.

    1. Re:Have you ever crashed 2500 computers? by Anonymous Coward · · Score: 0

      Heck, just give me 2500 Windoze machines and I'll show you the money ;)

  46. Dear Wacko: @# +1 ; Informative #@ by Anonymous Coward · · Score: 0

    If this is all you have to do with your time,
    perhaps, you can take that big joint you are smoking illegally in your parents' swimming pool, and stuff it where the sun doesnt shine. I'll
    let you use what little brain cells you have left to figure out where the sun does not shine.

    Alternatively, you could read some of Jon Katz's articles at Slashdot. That will anesthetize you more than marijuana.

    Thank you and have a LSD-induced weekend.

    Woot_spork

  47. Re:Stephen King, author, dead at 54 by Anonymous Coward · · Score: 0

    Now it's (score : -1, redundant)! At least one moderator has a sense of humor!

  48. Re:You often don't need anywhere near as many line by Anonymous Coward · · Score: 0

    He strongly advocates using only forth to an extreme degree.

    Be wary of individuals who do not practice what they preach.

    I've used c to build a 500 concurrent user db and used c++ to build a 100+ concurrent user distributed system. Been there and done that.

    Line counting means counting semicolons or other tokens.

  49. regarding compiling to Forth...Python? by claud9999 · · Score: 1

    My understanding is that the bytecode language of Python is very stack based/rpn-like...It'd be a curious exercise to compile Python to Forth instead (Fython?)

    Also, for more Forth-like fun, check out MUCKs, MUDs with an internal Forth language. (I spent far too much time hacking the internals of what would later become DaemonMUCK, almost ruining my college career...:)

    1. Re:regarding compiling to Forth...Python? by osu-neko · · Score: 1

      I hadn't heard that, but I'm not surprised. I've been working on compiling an interpretted LISP-like language I have, and halfway through designing the compiler I realized it was producing code that was very, very Forth-like. At the time I attributed this to the fact that the only compiler I'd written before was for a Forth-like language, but in retrospect I think it's just a very natural way to express this sort of thing...

      --
      "Convictions are more dangerous enemies of truth than lies."
  50. Fuck the moderators today by Uttles · · Score: 1

    And the horses that rode in on you

    --

    ~ now you know
  51. A 'flaw' with Forth... by melatonin · · Score: 1
    Every once in a while I hear 'Forth = cool' come up, and having not known much about it, have done a little searching and for whatever reason lost interest. I was more determined this time, and I have come to understand the 'cool' factor. Heh, factor. Anyway...

    I was going through A Brief Introduction to Forth, and in its section on Factoring, I came across this:

    Good Forth programmers strive to write programs containing very short (often one-line), well-named word definitions and reused factored code segments. The ability to pick just the right name for a word is a prized talent.

    good god, I would suck at this language. How many times have I named variables, even functions, 'foobar,' or otherwise named stuff with some combination of those letters? I've always wondered what names I might end up dooming my children with... I've even used raboof a few too many times to spice things up :(


    --
    Moderators should have to take a reading comprehension test.
    1. Re:A 'flaw' with Forth... by Anonymous Coward · · Score: 0
      Even now, about 20 years after my first Forth program (and now writing Java stuff) I keep a copy of Roget's Thesaurus handy... so much about programming right is finding the right way to think about the problem, and language is a big part of that.

      A really well factored program (any lang, not just Forth, afiak) should look almost like a custom scripting language for the task at hand at the highest level, using the power of words you chose originally.

      Of course, using Forth, you actually can go that extra step and rewrite the compiler to suite compilation of your new task oriented language.

  52. Balanced Ternary in Knuth by Jayson · · Score: 1

    Yes, it is called a Balanced Ternary and it is in the seminumerical volume of Knuth. It is very interesting because it provided some interesting ways of parallelizing arithematic at the bit level (i.e., you can borrow the your neighbors value when subtracting -- I think this is how it goes). Anyways, it is by far the elegant representation that I have seen.

    -j

  53. Nonsense. by jcr · · Score: 2

    >he's gratuitously adding the requirement for color vision to programming.

    He's doing nothing of the kind. He's using color in ONE particular programming environment, which you may use or not use as you see fit. Get over yourself.

    (Or, you could abandon programming altogether, since it gratuitously requires the use of hands to type the code.)

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
    1. Re:Nonsense. by Captain+Oblivious · · Score: 1
      Or, you could abandon programming altogether, since it gratuitously requires the use of hands to type the code.


      I would vigorously protest your thoughtless remark, but since I have to type this with my nose it would hurt too much.

  54. Chuck Moore should apologize by alienmole · · Score: 2

    Others have defended Moore based on other statements he made on the subject. But I, too, noticed the statement "everyone does not need to be a programmer", and think it is unforgivable. The only thing that could mitigate it is an apology from Moore.

    1. Re:Chuck Moore should apologize by Captain+Oblivious · · Score: 1
      I, too, noticed the statement "everyone does not need to be a programmer", and think it is unforgivable.


      Even the grammar is offensive, unless he truly wanted to say "no one needs to be a programmer," which is how it parses. I presume he meant to say "not everyone needs to be a programmer."

    2. Re:Chuck Moore should apologize by Water+Paradox · · Score: 1

      An apology would mean that he didn't mean it. He meant it, or he wouldn't have said it.

      It is you who have taken it out of context, misunderstood what he was saying, and demands an apology for something he did no wrong in doing.

      I demand an apology from you.

      :-)

      --
      information is immaterial
  55. This is different? by StrawberryFrog · · Score: 2
    Forth is different; in Forth you don't transform the problem into a form which fits the language; instead, you transform the language into a form that fits the solution domain.

    And how is this different from OO?

    I realise that Forth has little in common with C++ or Java, but the whole point of OO is that you can define new types that model the solution domain. So in Forth you define new 'words' that model the solution domain, and this is so very different?

    --

    My Karma: ran over your Dogma
    StrawberryFrog

    1. Re:This is different? by William+Tanksley · · Score: 2

      Very good question. This is fundamentally different from OO. For example, Forth is not an OO language, but if your problem fits OO, you can easily tranform Forth into OO. Forth isn't aspect-oriented, either, but again, it can be made so.

      In Forth you don't merely define new types that model the solution domain; rather, you define a new _language_ in which the solution domain can be expressed naturally.

      A common and desired result is that the solution portion of your program (as opposed to the part in which you're defining your language) can be read by an expert in the solution domain who knows NOTHING about computers. Nothing; not even how to read pseudocode. The final result may look like English; more often it looks like the formal terms appropriate to the solution.

      Forth people are proud of their almost total lack of syntax; even so, sometimes the problem requires syntax. In those cases too Forth has been extended; there are at least two Fortran/BASIC style parsers, and one general-purpose parser generator.

      -Billy

  56. C to Lisp by Anonymous Coward · · Score: 0

    Symbolics had a C to Lisp compiler for their Lisp machines... nothing is impossible to someone with enough time :-)

  57. Re:Forth is relevant? prove it! by iggie · · Score: 1

    Don't forget that every time you boot a Mac (or other Open Firmware hardware) you use a nice Forth interpreter rather a brain-dead BIOS.

  58. Missing the point, perhaps? by PinkHeadedBug · · Score: 2, Insightful

    Many of the more negative comments I'm seeing seem to be missing one or two points about the Forth programming environment (we call it that since it's more than just a language).

    Since he lacks feature xxx his ideas aren't relevant: Many of the comments in this regard seem to stem from an assumption that unless a programming environment includes support for multiple protected users, protected memory, protected devices, protective APIs, and so on, it cannot be a relevant environment. What I'd like some of you to consider is that, on the contrary, there are many more programming applications which simply don't require those mechanisms. Sure, they're great to have, when you need them. Your microwave doesn't require multiuser support; your watch doesn't require protected memory; set-top boxes don't require CORBA bindings; CCD firmware doesn't; engine management, FedEx barcode scanners, and so on. The list is nearly infinite, and can extend all the way up to your desktop, if you want. Certainly, we all know many many environments where those tools help us get our work done, but that doesn't invalidate the environments where they aren't needed. Think beyond your desktop; every CPU in the world doesn't have to be running Netscape. Implement what you need or want, throw the rest away.

    Progamming isn't for everyone: Some of you are turning this into a real strawman. Come on, you don't really believe Chuck is dissing someone who wants to program but has a challenge (such as blindness), do you? Re-reading the interview should show you that he has an interest in other representations of programming environments (other than text based ones). Furthermore, Chuck himself has poor eyesight. Thus, he's created his own programming environment that uses very large characters and uses color to replace punctuation, thus saving him precious screen real estate. If anything, you'd see he embodies the attitude, "Change the system to match your wants." I believe with a little thought that it should be obvious that he isn't seeking to exclude people with different abilities.

    // boba

  59. explination and example of what colorForth is! by Anonymous Coward · · Score: 0
    He said in the interview that you could use visual cues other than color. All the colors do is eliminate some of the syntax clutter of languages. Traditionally it would look like this:

    : newword forth love if honk then ;
    executed-right-now
    : nextword to be defined ;

    In color forth it's:

    newword forth love if honk then
    executed-right-now
    nextword to be defined

    in this case instead of color I used bold to mean "define this word and start compiling" and italics to mean "execute this word when you see it". Non-highlighted words would be compiled into the previous defintion.

    That's ALL there is to colorForth (aside from a couple more colors). It would be TRIVIAL to have alternative cue for visually impaired programmers and I'm surprised CM didn't comment on that immediately. I think CM was off the mark in his comment but I don't think he intended it the way it came across.

    I spent my previous three years as a Forth programmer (now I'm in a C++/Tcl project) and I was ashamed as a programmer to see how close-minded many programmers were. Forth may not be the ultimate language but it has a LOT to teach about the art of computer programming.

    Most of Forth's critics cannot even tell you BASIC facts about the language, it's mainly just fear and ignorance. Very bizzare coming from a group that usually prides itself on it's diversity.

  60. That was screwy... by samantha · · Score: 2

    There is more than 100 times the currently produced software per annum that is needed and desired. So, if you did make programming 100 times more efficient you wouldn't be in danger of putting any programmers out of work except for those who could not adapt to the more efficient methods.

  61. Re:You often don't need anywhere near as many line by forthy · · Score: 1

    I've written a web server in 200 lines of Forth (runs on GNU Forth, is part of the gforth-0.5.0 package). It's not an overfeatured web-server like Apache, it doesn't do SSL, doesn't allow any other language for server-side scripting than Forth, but I don't need that. If you want Apache, you can have Apache. Read more about it in http://jwdt.com/~paysan/httpd-en.html

    --
    "If you want it done right, you have to do it yourself"
  62. Don't confuse Chuck and Forth by BruceMcF · · Score: 1

    Whether or not there will be any revolution coming from Chuck depends on whether someone uses one of his chips to start a revolution.

    But don't confuse Chuck and Forth. Chuck has pursued his own very personal and eclectic path. If you are wondering how you are going to fit a SAX-like event driven XML parsing into a low resource microcontroller, search for JenX. Using Forth as a CGI server is even easier, at least in a Linux environment with gforth (Gnu Forth).

    The impression I have from comp.lang.forth is that when most serious Forth programmers hear from Chuck, they stop, say, "that's very interesting" and then go back to doing what they normally do, whether that is embedded work or work in a PC environment.

  63. Read again: its only the colour blind ... by BruceMcF · · Score: 1

    Chuck Moore says he has no qualms requiring colour vision. And youse Americans want him to apologise.

    I expect he means that if there was something intrinsic about colour in programming, he wouldn't have any qualms about making colour vision a requirement for programming.

    But whatever he means, he either has qualms or he doesn't. Claiming that he did when he doesn't would be that thing which used to be called a "lie".

    On the other hand, the whole thing is a complete storm in a teapot, because there is nothing intrinsic about colour vision, or even vision, in ColorForth. The foundation is in fact much more accessible to vision impaired than some "connector set" programming paradigms. It's all just names of things, with each name preceded by a token to indicate one of a limited set of possible states. Since eight states is 3 bits, you just need three distinct voice attributes: say, male/female, high/low pitch, strong/normal timber and you've got AuralForth. Or three rich text attributes and you have RichTextForth.

    But he's just one guy building his tools to build his tools as he goes. Since he says he's interested in voice recognition, and having AuralForth would be part of that for him, we might see AuralForth built. But someone was colour blind and wanted RichTextForth, he'd probably have to pay. From what I hear, Chuck's vision is none too good, and he's much more comfortable with displaying ColorForth in big blocky letters in different colours than he would be displaying them in bold, italics, and underline.

  64. Its hidden behind the scenes ... by BruceMcF · · Score: 1

    Since Forth at the moment is inside the little thingies that you sign for packages on for one of the major US delivery companies, manages the baggage system for some major airports, the European system for letting bank machines talk to each other, and provides the OpenFirmware pre-OS boot manager for Sun, IBM and Apple systems to help bring up new hardware faster, how can you possibly ask where people are using Forth on other machines?

    Clearly, the current ANS Forth standard does not include everything needed for a more sociable forth, but work is ongoing.

    And sure its got more presence in professional robotics than amateur robotics, but what about the Forth for Mindstorms?

  65. Forth is the only thing to webserve a light switch by BruceMcF · · Score: 1

    I'm not joking. See the discussion of the latest EuroForth conference in a recent Forthwrite at

    http://www.fig-uk.org

    It is, in fact, pretty easy to run gforth as a CGI server on a linux system ... what is impressive if using Forth to put the webserver into a lightswitch for a security system.

  66. Python for x25? Perhaps not such a great idea... by more · · Score: 1

    There are two main costs in executing Python code: evaluation of reasonably simple stack-based byte code and string hashing. Perhaps the byte code could be replaced with forth directly, but there is still a lot of processing that goes to hashing. So, how can we do fast (character string) hashing with the x25 - with lots and lots of different hash tables. The answer is - we cannot do it. There is probably not enough memory bandwidth to support the 25 processors all fetching hash data from the main memory. (Python code is roughly 50% evaluation, 50% hashing.)

    --

    -- Imperial units must die --

  67. Stop thinking SMP, start thinking workgangs by BruceMcF · · Score: 1

    There is no way that you would want to use all 25 processors all fecthing hash data from the main memory at the same time. You would organise the processors into work crews.

    And, after all, the main point of mass producing Minimal Instruction Set chips interconnected together on the same die is that if you aren't using all the processors at some point in the process ... so what! $1 a chip, it can be efficient for a few to be idling, just to provide low latency.

    Think of the x25 organised into 5, 5 processor work crews, with one evaluating and the other four doing the work with hashes (on the assumption that the hashing is harder work for the cores than the evaluation). And if there's a memory bottleneck, either in access or quantity, add more x25's with their own 256K memory.

    I reckon that's the notion of a cheap chip such as the X25 ... if you run into bottlenecks, apply more chips. Forth or a Forth-like language is going to be the assembly language of that kind of cheap chip, because you need operand free operations and seperation of datastacks and return stacks to sidestep the issues that drive you up CISC and RISC design paths.

  68. No worries mate, ... by BruceMcF · · Score: 1

    No worries mate. Just post your code on comp.lang.forth and say, "I can't come up with good names for a lot of these functions, suggestions welcome".

    If people are interested in what is accomplished, you'll have plenty of names to use once the smoke clears.

  69. "Blind" programmers by jmdrake · · Score: 1

    I find the blatent soundbiting in regards to Chucks comments regarding blind programmers to be utterly amazing. People have grabbed hold to one sentence with a pitbull grip and totally ignored the rest of what was said. Here are some statements that were ignored by so many.

    Chuck Moore : I'm amazed at how effective blind programmers can be. I rely so strongly upon seeing the code that it's hard to imagine listening to it. Yet I know it can be done.

    Also Chuck Moore : But in fact, color is merely a property of words that helps to distinguish them. As is intensity, size, font, volume and tone. I'm sure colorForth will be translated into these other representations. I, myself, will be exploring spoken colorForth. (As soon as I can decipher PC sound cards.)

    Someone suggested that Chuck should have "considered blind programmers" when designing colorForth. In truth colorForth in its current form could be more easily adapted to blind use than much of the Windows paradigm. There are bits encoded in the Forth words that change the color to red, green, blue ect. A computer could easily be programmed to simply say "red", "green", "blue" or even "defining", "compiling", "executing".

    Perhaps he might not have used the best or most PC choice of words, but the thought is "when experimenting with a tool I'm designing for myself, why should I be restricted by what best works for someone else?" I totally agree. ColorForth is just now being released to the public. Like many other tools that were developed in private and are in the initial phase of release it will take time before it fits needs of this or that particular user. But to focus online on its limitations is to be truly "blind".