Forth

How does expressing the opinion that Forth code should be kept small and manageable mean that it applies to everything else as well?

I am stating my opinions, as are you. What qualifies YOU to make these assertions?

I've retired from 45 years as a real-time embedded softy, electronics degree specialising in computers and communicaiton, one year spent on instrumentation design for attaching to PDP11s.

? I have run a Forth software shop since 1981, so on

I year's experience repeated 36 times?

Straw Man, and a non sequitur. I had not mentioned any other languages by name

I had agreed with you on that point. You complain of repetition whilst doing it yourself.

As, perhaps are all assembly languages.

A few years back, probably 16, I produced a BrainFuck interpreter in VB6, just for fun, just as Forth is for fun but is not a reputable language for large scale professional projects.

A language needing extensibility, for example, adding case / switch / select statements is not reputable. Doing such things renders you as a language developer and not someone concentrating on the job in hand.

Most "extensibility" is nt different to other environments whereby subroutines and objects are defined as necessary.

No, RPN, nothing to do with the data stack. But you do highlight another assembly language feature not seen in reputable languages when the programmer has to be consciously aware of both the data stack and also the return stack.

An untyped language? Error prone for all. BCPL's right values and left values were replace by pointers in C.

Untyped languages are problems for all; and such untypiness is a marker for an assembly language.

? If

An interesting side step. IMHO, most HLL programmers are unaware of machine functions such as stacks, and the reason for such HLL is to move away from the machine towards the application.

I too, as a contractor, have been involved with companies where there was no existing software organisation, and in my case, the teenage son of the MD produced the software in hex machine code typed into A Softy PROM programmer. That you are now supporting their product suggests that they still do not have reputable professional softies.

When you keep repeating about the 1M4 lines of code, you make a fool of yourself by claiming that others' repetition is tedious.

Physician, heal thyself! :-)

There are other Forth apps, ancient and

That's not really the issue; the issue is the understandability and maintainability of code. FORTH, being an assembly language, and, untyped as you have highlighted, is error prone.

I dunno about fashionable, but I have fond memories of PDP8 assembly language which is not an indication that I would suggest ot today.

Good projects with good code can be easily read and understood by almost everyone, so you suggest that FORTH is not good.

Tool chains can be useful, but are NOT essential for, eg, C.

C with makefiles and text editors, not really a toolchain, worked well on many projects.

Taking this back to the original query, I suggest that Tcl is a good choice for a second language after Python.

FORTH is for hackers who cannot be bothered to learn the separate usage of editors, compilers, linkers and loaders.

But it can be fun in small doses, but with no other programming background, a year's experience with FORTH would be 1 weeks experience repeated 50 times.

I can be even more specific. On x86, 'kernel' is just 4 (four) processor instructions. The rest can be treated as 'library'.

Isn't it based on Forth?

ISTR that on the PDP11, it was just a single instruction ...

JMP @(r0)+

CASE .. OF .. ENDOF .. ENDCASE is in the spec. It is even in _Thinking Forth_ by Brodie and that goes back to '84.

Actually working with a DSL (domain-specfic langauge), and using Forth can be seen as developing and working with a DSL, is often the best way to attack a problem.

It doesn't, but the original number (1000) was ridiculous and treated as such.

IMHO all code should be kept as small as possible and manageable. What's wrong with that?

Stephen

I'm not familiar with PDP11. Four instructions I was referring to was complete NEXT statement from my simple Forth system. Single instruction versions that I've seen on Z80 were basically jumps to NEXT statement which was kind of outside of the rest of Forth (and which was still bigger than one instruction). I guess it all depends on which registers are used and which instructions available for the programmer.

Threaded code is all but obsolete in modern Forths. Most modern Forths generate optimised native code.

Stephen

Yep it has a lot of similarities - and deliberately so. If you know some forth you can immediately get up and running and work out a lot of what is going on. However it is when you go beyond the basics where you start to see differences. You often end up using different idioms but then I never really used Forth in anger.

I'm sure you'll have bureaucrats lining up to take a swing at that one. But being one of those who is less obsessed with feathering his own nest, I'm inclined to follow Albert Einstein's advice: "Everything should be made as simple as possible, but no simpler."

You should study the PDP-11 instruction set. The first time I disassembled code that did stuff like this, I was dazzled by its elegance. The Z80 doen't come anywhere near.

Given the amount of unpleasantness you throw around, I just choose to ignore you. You may have valid points or you may not. I'll just never know.

Stephen

That's called trolling Gareth, please stop.

-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. |

I am reminded by this of the rants about Perl being only fit for scripting and obfuscated hackery, whereas in fact it can be used to write well structured, intentional and highly readable code. I've not used Forth enough to know for sure but I would be surprised if the same weren't true for Forth. There are very few languages that force you to write code that's hard to read.

Mea culpa, my bad. Nevertheless a bad example has not nullified the comment.

Can you give an example of a domain that is not adequately covered by HLLs with their subroutine / procedure / function extensions or their object concepts?

Straw Man.

It is some years since dabbling with FORTH on X86, but ISTR using SI as the pointer to the current brick, when the kernel code (actually added to the end of each primitive operation becomes just 2 instructions ...

LODSW JMP AX

How do they cope with program modifying code, your extensibility and the BUILDS> DOES> construct (In Loeliger's version)?