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 476027
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Why not in Forth?
by Alfman on Sat 4th Jun 2011 20:53 UTC 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

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

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

But while reading "Starting Forth" you surely noticed, where I copy the above from? ;)
I understand that statement, that using Forth words, instead of coding in assembly, usually overall size of your code is smaller, when programming in Forth. I think, it depends on quality of macroassembler you can use, quality of Forth compiler, which you're comparing to - and, of course, on your skills both as assembler- and Forth-coder.

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?

No. Actually, programming in Forth is rather "designing one's own problem-specific language". Forth is the basis. Then instead of using ready-available high-level function (which you'll find in langs like Python), you're designing your own higher-level language using Forth words.

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.

Of course, it's not that easy to measure it. Since I'm Forth-newbie (learning it about year for now), you may be interested in asking these questions on comp.lang.forth, where you'll meet several experienced Forth-programmers, coding in Forth more than 20 years.

Reply Parent Score: 1

RE[5]: Why not in Forth?
by Alfman on Sat 4th Jun 2011 23:36 in reply to "RE[4]: Why not in Forth?"
Alfman Member since:
2011-01-28

"But while reading 'Starting Forth' you surely noticed, where I copy the above from? ;) "

Yes.

"...using Forth words, instead of coding in assembly, usually overall size of your code is smaller, when programming in Forth."

We're still talking about compiled x86 code? Honestly I don't understand the logic, but no matter.


"No. Actually, programming in Forth is rather 'designing one's own problem-specific language'...instead of using ready-available high-level function"

This is fine for programming algorithms, and it's probably fine for OS work. However I'd be worried about leaving typical web developers to write their own functions. I imagine this results in a lot of duplicate code between libraries.


"Since I'm Forth-newbie (learning it about year for now), you may be interested in asking these questions on comp.lang.forth, where you'll meet several experienced Forth-programmers"


Thank you for answering my questions. The language seems to have an almost universal quality to it - I think you'll know what I mean by that.

Reply Parent Score: 2