Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I coded in 1985

blog.jgc.org

Post reply on HN
Print view View original

111–120 of 120 posts

Re: How I coded in 1985

#111

Post by robomartin »

kragen wrote: post #110
robomartin wrote: post #105

Earlier quoted context omitted.

You are not looking at Forth correctly. It isn't C, C++ or Java. It's a "raw" language that you should use to write a DSL. It's just above assembler yet many orders of magnitude faster to develop with. Even with your comment backwards it makes little sense. I have developed in nearly every language between typing raw machine code with a hex keypad and Objective-C (not to moly that O-C is at the opposite end of the sc…

Oh, I know that about the EDSL nature of Forth, and it's entirely possible that if I really knew Forth, my experience would be different. On the other hand, if you were right that Forth is many orders of magnitude faster to develop with than assembler, we'd see people writing HTML5-compliant web browsers in Forth in a few hours. (I'm figuring: 100 person-years for e.g. Chromium, multiplied by ten for assembly, divide…

Nope. Wrong again. Writing a browser isn't the right fit for Forth. Could you? Sure. Should you? Nope.

Forth is great to develop with but comes with liabilities if used on the wrong project. I remember a product a friend of mine did using Forth. High end embedded system with custom hardware all selling for tens of thousands of dollars per unit. When he started to look into selling the business Forth became a liability. Nothing wrong with it. Te code worked well and was mostly bug-free. The company bidding to acquire his business did not do Forth and saw it as an impediment. They, like a million others, did C. Ultimately he sold the company for $16 million with a requirement to translate the code base to C under contract.

Today I use C for any time I need to do embedded work. Having a foundation in a diverse range of languages means that you tend to use a language like C as a toolset to create an efficient development environment through domain specific libraries, data structures and data representation.

I rarely find the need to get down to Forth these days. It made a lot of sense with 8 bit resource-restricted microprocessors. Today you can have a 16 or 32 bit embedded processor for a few bucks and have it run at 25, 50 or 100MHz. Different game.

Re: How I coded in 1985

#113

Post by edw519 »

kragen wrote: post #72
edw519 wrote: post #5

That headline got me to thinking... Date: Monday, April 29, 1985 Age: 29 Location: Santa Ana, California. Company: electronics manufacturer setup: dumb black & green 24x80 14" CRT terminal Hardware: Honeywell mini OS: Honeywell proprietary DBMS: Pick (Ultimate Flavor) Language: BASIC App: Work Order Processing (I wrote from scratch.) Date: Monday, April 29, 2013 Age: 57 Location: Miami, Florida Company: aerospace man…

You're connected right now to a Pick system? From your point of view, how does Pick compare to the current wave of NoSQL databases, practically speaking? What are the advantages and disadvantages?

I haven't used NoSQL databases, so I don't have an opinion on that comparison. As for more traditional relational DBMSs (MySQL, Postgress, Oracle), there are many differences which could be considered either advantages or disadvantages, depending on who you asked. Examples:

  - level of normalization determined by programmer, not DBA
  - relationships (joins, etc.) enforced at program level, not schema
  - no typing (everything is a string)
  - DBMS performance is mathematically predictable & determined (hashing)
  - everything is variable length
  - anything can be multi-valued or multi-subvalued
  - No schema needed. Just code.

Re: How I coded in 1985

#114

Post by kragen »

edw519 wrote: post #113
kragen wrote: post #72

Earlier quoted context omitted.

You're connected right now to a Pick system? From your point of view, how does Pick compare to the current wave of NoSQL databases, practically speaking? What are the advantages and disadvantages?

I haven't used NoSQL databases, so I don't have an opinion on that comparison. As for more traditional relational DBMSs (MySQL, Postgress, Oracle), there are many differences which could be considered either advantages or disadvantages, depending on who you asked. Examples: - level of normalization determined by programmer, not DBA - relationships (joins, etc.) enforced at program level, not schema - no typing (every…

It sounds a lot like the benefits of one flavor of the NoSQL databases — thus my question. (Another flavor of NoSQL, stemming from BigTable, is more focused on horizontal scalability and partition-tolerance.)

Re: How I coded in 1985

#115

Post by kragen »

robomartin wrote: post #111
kragen wrote: post #110

Earlier quoted context omitted.

Oh, I know that about the EDSL nature of Forth, and it's entirely possible that if I really knew Forth, my experience would be different. On the other hand, if you were right that Forth is many orders of magnitude faster to develop with than assembler, we'd see people writing HTML5-compliant web browsers in Forth in a few hours. (I'm figuring: 100 person-years for e.g. Chromium, multiplied by ten for assembly, divide…

Nope. Wrong again. Writing a browser isn't the right fit for Forth. Could you? Sure. Should you? Nope. Forth is great to develop with but comes with liabilities if used on the wrong project. I remember a product a friend of mine did using Forth. High end embedded system with custom hardware all selling for tens of thousands of dollars per unit. When he started to look into selling the business Forth became a liabilit…

I'm still skeptical about this "many orders of magnitude" nonsense. Even on an 8-bit resource-restricted microprocessor, what could you write with Forth in a day that would take half a century with a team of 60 people in assembly? Or what could you write with Forth in ten minutes that would take you 60 years in assembly? I think you're talking nonsense and being condescending to try to cover it up.

And if almost all projects are "the wrong project" for Forth (which seems to be what you're saying, although I don't agree with it) then does it make sense to compare it to a general-purpose language like assembly? You make it sound like a DSL like SQL, not like a framework for all DSLs.

Re: How I coded in 1985

#116

Post by robomartin »

kragen wrote: post #115
robomartin wrote: post #111

Earlier quoted context omitted.

Nope. Wrong again. Writing a browser isn't the right fit for Forth. Could you? Sure. Should you? Nope. Forth is great to develop with but comes with liabilities if used on the wrong project. I remember a product a friend of mine did using Forth. High end embedded system with custom hardware all selling for tens of thousands of dollars per unit. When he started to look into selling the business Forth became a liabilit…

I'm still skeptical about this "many orders of magnitude" nonsense. Even on an 8-bit resource-restricted microprocessor, what could you write with Forth in a day that would take half a century with a team of 60 people in assembly? Or what could you write with Forth in ten minutes that would take you 60 years in assembly? I think you're talking nonsense and being condescending to try to cover it up. And if almost all…

You know. You are right. I don't know what I am talking about. Thanks for helping me sort that out. Good day.

Re: How I coded in 1985

#117

Post by kragen »

robomartin wrote: post #116
kragen wrote: post #115

Earlier quoted context omitted.

I'm still skeptical about this "many orders of magnitude" nonsense. Even on an 8-bit resource-restricted microprocessor, what could you write with Forth in a day that would take half a century with a team of 60 people in assembly? Or what could you write with Forth in ten minutes that would take you 60 years in assembly? I think you're talking nonsense and being condescending to try to cover it up. And if almost all…

You know. You are right. I don't know what I am talking about. Thanks for helping me sort that out. Good day.

I'm not accusing you of ignorance; I'm accusing you of talking nonsense, which is to say, writing a bunch of bullshit without regard to whether it's true or false. I'm sure you know perfectly well that you're talking nonsense, as does anybody else who's read this thread, and that's why you're responding with this kind of diversionary aggressive bluster.

But I find it disappointing, and I wish you'd engage the conversation at a rational level instead of bullshitting and sarcasm. It's a missed opportunity to share your knowledge — not with me, but with whoever else reads the thread in the future.

Re: How I coded in 1985

#118

Post by robomartin »

kragen wrote: post #117
robomartin wrote: post #116

Earlier quoted context omitted.

You know. You are right. I don't know what I am talking about. Thanks for helping me sort that out. Good day.

I'm not accusing you of ignorance; I'm accusing you of talking nonsense, which is to say, writing a bunch of bullshit without regard to whether it's true or false. I'm sure you know perfectly well that you're talking nonsense, as does anybody else who's read this thread, and that's why you're responding with this kind of diversionary aggressive bluster. But I find it disappointing, and I wish you'd engage the convers…

"I'm sure you know perfecly well that you are talking nonsense, as does anybody else who's reading this thread"

How do you expect me to answer something like that?

You don't know the language and are intent on having an argument with me about this?

When Forth is used correctly productivity gains become exponential (the limit being application dependent). So, yes, when used correctly you can go 10, 100 and even 1,000 times faster than assembler.

A good comparison would be to look at the productivity gains had when writing raw Python vs using a library such as SciPy. The productivity gains are orders of magnitude greater than the raw language. And, even raw python is orders of magnitude faster than writing assembler.

What I said was that [Forth] "It's just above assembler yet many orders of magnitude faster to develop with." and you seem to think this is nonsense. Well, you are wrong. What else do you want me to say. Go learn the language and we can have a conversation. Using it casually doesn't produce the same level of understanding you get from dedicated non-trivial usage. This is true of any language or technology.

I am not insulting or diminishing you. Perhaps you are taking it that way. Relax. It's OK to not know everything, I certainly don't and I've been designing electronics and writing software for a long time.

Here's a place to start:

http://www.ultratechnology.com/forth.htm

Here's a good Q&A:

http://www.inventio.co.uk/forthvsc.htm

If I have the time later tonight I might post a follow-up with an example of what development flow might be for, say, developing code for a multi-axis CNC machine.

Re: How I coded in 1985

#119

Post by robomartin »

robomartin wrote: post #118
kragen wrote: post #117

Earlier quoted context omitted.

I'm not accusing you of ignorance; I'm accusing you of talking nonsense, which is to say, writing a bunch of bullshit without regard to whether it's true or false. I'm sure you know perfectly well that you're talking nonsense, as does anybody else who's read this thread, and that's why you're responding with this kind of diversionary aggressive bluster. But I find it disappointing, and I wish you'd engage the convers…

"I'm sure you know perfecly well that you are talking nonsense, as does anybody else who's reading this thread" How do you expect me to answer something like that? You don't know the language and are intent on having an argument with me about this? When Forth is used correctly productivity gains become exponential (the limit being application dependent). So, yes, when used correctly you can go 10, 100 and even 1,000…

Te key argument behind this thread centered around my assertion that Forth can be orders of magnitude faster than assembler. That means 10, 100, 1000 --or more-- times faster to code a solution in Forth than in assembler.

I haven't done a any serious work in Forth in about ten years, so coming up with an example for this thread would have consumed time I simply don't have right now.

The reality is that ANY language is orders of magnitude faster than assembler. The idea that this assertion is being challenged at all is, well, surprising.

I happen to be working on a project that, among other things, makes extensive use of nested state machines. The main state machine has 72 states and some of the children FSM's have up to a dozen states. Writing this in C it takes mere minutes to lay down a bug free structure for the execution of the entire FSM set. It should go without saying that doing the same in assembler would take far longer and result in a mess of code that would be difficult to maintain.

Assembler has its place. I have written device drivers, disk controllers, motor controllers, fast FIR filters, pulse/frequency/phase measurement and a myriad of other routines across a number of processors all in assembler. These days I'd venture to say the vast majority of embedded systems are done in C. Coding is faster, far more maintainable and embedded optimizing compilers do an excellent job of producing good, tight and fast machine code. As much as I love and enjoy Forth this is one of the reasons I rarely use it these days.

I still think it is important to learn about TIL's as it adds a layer of thinking outside the box one would not otherwise have.

Re: How I coded in 1985

#120

Post by kragen »

robomartin wrote: post #119
robomartin wrote: post #118

Earlier quoted context omitted.

"I'm sure you know perfecly well that you are talking nonsense, as does anybody else who's reading this thread" How do you expect me to answer something like that? You don't know the language and are intent on having an argument with me about this? When Forth is used correctly productivity gains become exponential (the limit being application dependent). So, yes, when used correctly you can go 10, 100 and even 1,000…

Te key argument behind this thread centered around my assertion that Forth can be orders of magnitude faster than assembler. That means 10, 100, 1000 --or more-- times faster to code a solution in Forth than in assembler. I haven't done a any serious work in Forth in about ten years, so coming up with an example for this thread would have consumed time I simply don't have right now. The reality is that ANY language i…

I agree that learning about threaded interpretive languages is important, despite the fact you allude to that Forth compilers (at least those I'm familiar with) produce deeply suboptimal code.

I agree that writing in a high-level language is faster — quite aside from the availability of library functionality like hash tables and heaps and PNG decoders and whatnot, you have less code to write and to read, and less fiddly decisions about register assignment and memory allocation to make, possibly get wrong, and have to debug.

But that difference is a constant factor — it's not going to be even 1000, and it's never going to approach "many orders of magnitude", which was the nonsense claim I took most issue with. (Two or three isn't "many" in my vocabulary.) Typically I think it's about 10 to 30, which is nothing to sneeze at in the real world, but which would be insignificant compared to your absurd earlier claims.

You can get a "many orders of magnitude" boost — rarely — from libraries or static checking. Neither of these is Forth's strong suit.

Nested state machines are actually an interesting case — often by far the most convenient way to write them is with one thread per state machine. C by itself doesn't give you the tools to do that predictably, because you can't tell how much stack space you're going to need — it depends on your compiler and compilation options; assembly and Forth do. So it's one of the rare things that might actually be easier to do in assembly than in C. (But if you have some memory to spare, maybe setcontext() is plenty good enough.)

Post reply on HN