Linked by Conrad Voorsanger on Thu 2nd Jun 2011 16:28 UTC
Original OSNews Interviews OSNews sat down with Ian Seyler, the Founder and Lead Programmer at Return Infinity, the maker and sponsor of Baremetal OS, a 64-bit OS for x86-64 based computers written entirely in Assembly. Editor's note: We'd love to do similar interviews with the people behind other alternative or hobby OS projects. If there's a project that you'd like to learn more about, let us know.
Thread beginning with comment 475952
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Why not in Forth?
by Alfman on Fri 3rd Jun 2011 23:55 UTC in reply to "Why not in Forth?"
Alfman
Member since:
2011-01-28

You know there are so many languages these days, it's become difficult to keep track of them.

For example, I already have trouble remembering the substring functions between javascript, c, php, perl, .net, mysql, plsql... very rarely do I use others.

What does forth offer as a compelling reason to learn/use it?

It may be good, but these days languages have way too much overlap and the choice is seemingly arbitrary.

Reply Parent Score: 2

RE[2]: Why not in Forth?
by Zbigniew on Sat 4th Jun 2011 11:52 in reply to "RE: Why not in Forth?"
Zbigniew Member since:
2008-08-28

> What does forth offer as a compelling reason to learn/use it?

You didn't read anything like "Starting Forth"? OK, here you go:

Forth is fast. High-level Forth executes as fast as other high-level languages and between 20 to 75% slower than equivalent assembly-language programs, while time-critical code may be written in assembler to run at full processor speed. Without a traditional operating system, Forth eliminates redundancy and needless run-time error checking.

Forth compiled code is compact. Forth applications require less memory than their equivalent assembly-language programs and consume less power (important for hand-helds and portable gadgets!) Written in Forth, the entire operating system and its standard word set reside in less than 8K bytes. Support for a target application may require less than 1K bytes.

Forth is transportable. It has been implemented on just about every mini- and microcomputer known to the industry. Most microcontrollers and DSPs, even tiny ones, also have a Forth implementation.

Forth has been known to cut program development time by a factor of ten for equivalent assembly-language programming and by a factor of two for equivalent high-level programming in C or Java. Productivity increases because Forth epitomizes "structured programming" and because it is interactive and modular.

Reply Parent Score: 1

RE[3]: Why not in Forth?
by Alfman on Sat 4th Jun 2011 20:53 in reply to "RE[2]: Why not in Forth?"
Alfman Member since:
2011-01-28

Zbigniew,

"You didn't read anything like "Starting Forth"? OK, here you go:"

No, I never had reason to before. I am looking at it now. It'd take me a while to get used to, but I can see how the stack based approach translates very easily to CPU stack.

"Forth compiled code is compact. Forth applications require less memory than their equivalent assembly-language programs and consume less power (important for hand-helds and portable gadgets!)"

Something doesn't seem right about this. Either forth is emulating a more compact byte code than x86, or it's executing native x86 code. I don't understand how it can be both smaller and as efficient as assembly, can you elaborate?


"Forth is transportable. It has been implemented on just about every mini- and microcomputer known to the industry. Most microcontrollers and DSPs, even tiny ones, also have a Forth implementation."

Portability is huge, however in my experience platform specific APIs hinder portability more so than the language itself. Does forth have a standard API for things like networking, name resolution, databases, threading, graphics, etc?

From my initial reading, the forth language doesn't specify these things but I could be wrong.

"Forth has been known to cut program development time...for equivalent high-level programming in C or Java."

I'm sure this is true for many cases. But what about compared against ruby, or python, C#, or even something like haskell?

The question is difficult to answer (at least for me) because I don't have the time to implement the same program in a dozen different languages to compare the relative difficulty.

Haskell/Prolog have a very unique capability to run many functions backwards (given the output, it will enumerate all possible inputs).

Forth's reverse polish notation stands out, but it's not immediately obvious to me that it's a better way of thinking about code. If I had more experience with it, maybe I'd change my mind.

In terms of simplicity, there is no contest, the trivial nature of RPN blows everything else out of the water.

In terms of technical superiority, I don't know so much. Java also uses a similar stack driven implementation under the hood.

I might like it once I got used to it. But, realistically it's difficult to justify spending time to become fluent in forth when employers aren't asking for it.


Edit: I wanted to say that I do agree with you that it looks like it would be a natural fit in an operating system context. It does does seem more suitable than the other languages I brought up. Particularly for algorithms.

Edited 2011-06-04 21:01 UTC

Reply Parent Score: 2