7 ms·

Levels of code in Forth programming (2002)

163 points by pointfree 7y ago

stallmanite 7y ago
This is really captivating. I think I’m inspired to finally dust off my of TI-Forth for the 99/4a
codr7 7y ago
Before I learned Forth, I was very comfortable in Common Lisp. Now I miss the convenience when writing Forth and raw simplicity when writing Lisp. I realize the problem isn't Forth, some people (such as the writer for example) are capable of pulling amazing feats for such a primitive tool. But as a result, the programming languages [0] I've designed since have all been part Forth and part Common Lisp. [0] https://github.com/codr7/cidk https://github.com/codr7/cidk
haolez 7y ago
Forth is pretty amazing. It really delivers on that old promise of “a language that will make you a better programmer in other languages”. However, from my experience, since there is basically no syntax, all Forth programs tend to be a DSL for the problem at hand. It’s almost like having to learn a new language ok each new project. It’s like a complete opposite of what makes Go great.
- adestefan 7y ago
  That is exactly what Chuck Moore wanted when inventing Forth.
  - haolez 7y ago
    I know. It’s a feature, but it makes it harder to share code (and Chuck Moore believes that sharing code is rarely worth it). Maybe he is right. His productivity is unbelievable :)
    - mr_crankypants 7y ago
      The more time I spend dealing with blowback from excess complexity being imported in the form of 3rd-party libraries that offer complicated solutions to simple problems, the more I think that Chuck Moore was very, very right on that point.
      - dTal 7y ago
        Ehh... the reductio of this argument is writing everything in assembler (libc? giant hunk of third party code right there). I surmise that, by comparison, the blowback you encountered was relatively minor.
        astrobe_ 7y ago
        No, not writing everything in assembler, this isn't about high or low level. It's about writing things yourself for what you actually need. Because most of the complexity comes from code (esp. libraries and drivers) trying to solve a larger problem than you actually have. That's the same reason why, when you follow that logic, you eventually write your own Forth. Not because it fun. Not because you want to learn about Forth or compiler. But because my Forth solves my problems the way I see fit, her Forth solves problems the way she wants, and your Forth is going to solve the way you want.
        markus_zhang 7y ago
        at least we can get rid of the bloated web apps once everyone begins to do so...but would it be possible if libaries are written in a way that it's easy to just integrate just a portion into existing code?
        mr_crankypants 7y ago
        The problem there is that most "libraries" are actually frameworks. The difference I'm drawing being, libraries just provide a mess of utility functions. Theoretically, even if your compiler won't strip the library stuff you don't need, you'd be able to take just the bits you need by copy/pasting a relatively small volume of code. And dropping the library would be a small change, that just requires finding replacements for the functions and classes you were using. Frameworks tend to involve some Grand Unifying Abstraction that you need to inherit from, and that gets imposed on your own code. Things tend to be so tangled together at a conceptual level that it's not really possible to use them in an a la carte manner. Migrating off of a framework tends to require more-or-less a rewrite of all the code that interacts with it. To take some Web examples: jQuery's more on the library side of things. D3 is more of a framework. React is very much a framework.
- petjuh 7y ago
  In a sense, any API that has its own functions and data structures becomes like a DSL. For example OpenGL feels like its own language, even when you write it in C or C++, or C#.
  - TeMPOraL 7y ago
    Moreover, in any nontrivial application, you have modules and layers of abstractions - and those boundaries are DSLs on their own. It's actually good to think of them as languages the client code will use to write its solutions in (SICP makes this point early in the book too). People are getting too hung up on the word "language", like it was something only the most experienced and smartest of programmers were allowed to build. Nope, programmers build new languages daily in their code; it's how you abstract things.
- kreetx 7y ago
  Are there any good but not too large codebases where someone new to Forth could get a feel of how it's done? I'm intrigued by building DSLs, but a university course a long time ago left a totally different impression.
  - pointfree 7y ago
    "Over the Shoulder 1 - Text Preprocessing in Forth" https://www.youtube.com/watch?v=mvrE2ZGe-rs https://www.youtube.com/watch?v=mvrE2ZGe-rs - Sam Falvo demonstrates writing a blog engine in Forth.
- jacquesm 7y ago
  I don't see the semantic difference between calling a subroutine or using a Forth word. 65 emit vs putchar(65); vs (print 'A') It's all the same to me.
elcritch 7y ago
Intriguing article. Just updated some Forth code for interfacing with an ADC on a sensor I’m building. Dealing with SPI/I2C and sensors/adc’s in Forth really is fantastic. The results in much more succinct hardware code IMHO than C or even higher level languages. Really Chuck Moore seems spot on when dealing with specific hardware. One example is a simple Forth word (macro) to convert 3 bytes into one 32 bit number integrates well into code for dealing with an adc chip. However I wouldn’t want to write while applications in Forth as dealing with stack swaps becomes annoying. Still writing your own Forth is pretty fun too. I did mine by basing C compiler XMacros which made porting to an Itsy M4 trivial (about 3-4 of work) [1]. Still there’s a few Forth’s for Arduino’s, Itsy’s, ESP’s [2] which are really fun as they enable repl style interactive programming with hardware while still being blindingly fast! 1: https://github.com/elcritch/forthwith https://github.com/elcritch/forthwith 2: https://github.com/zeroflag/punyforth https://github.com/zeroflag/punyforth
theamk 7y ago
> Portability is not possible. Real applications are closely coupled to hardware. Change the platform and all the code changes Some lessons simply did not age well.... Even in world of today's microcontrollers, which often have kilobytes of RAM and very different CPU styles, people still write mostly hardware abstracted code.
- lidHanteyk 7y ago
  Most code should be abstract, because the things that are specified are abstract. Some code needs to be closely coupled to hardware, but most code should only need to be closely coupled with other code.
- astrobe_ 7y ago
  It's the usually game of MPUs becoming cheaper or more stuffed for the same price because the demand allows to manufacture bigger batches, and the demand is to allow more portability by the means of more stuffed MPUs that allow more abstractions... But it's a miniature of the same tragedy as Node.js applications that consume ten times the resources needed just because it allows people to do more with more... In a logarithmic way.
- pointfree 7y ago
  > Portability is not important. Portability is not possible. Real applications are closely coupled to hardware. Change the platform and all the code changes. If it didn't, you wouldn't have changed the platform.
bcherny 7y ago
This is a really interesting read, and as someone who’s almost exclusively programmed in high level languages, this approach seems alien to me. A couple of questions: 1. Is it possible to write complex, modern applications (things like browsers, photo editors, etc. — things that would take millions of lines of Java or JS) using this style of programming? 2. What is “sourceless programming”? Where is a good place to learn more about it?
- madhadron 7y ago
  1. "This style" is kind of hard to pin down. If you mean Chuck Moore's dramatic minimalism, then, yes, but it won't resemble what most people in computing expect from a browser or photo editor. If you mean expressing the abstractions you want directly in the primitives you have without bothering about layers or even accepting the idea of higher vs lower levels, then, yes, certainly. It requires a lot of unlearning, though. 2. Sourceless programming was something Chuck Moore tried for a while where he designed a machine that was the virtual machine he wanted to program, implemented it in hardware, and then edited byte code directly for it. Later he stepped back and went to colorForth, which has the source/binary separation we are all accustomed to.
  - bcherny 7y ago
    Thanks for the reply! > but it won't resemble what most people in computing expect from a browser or photo editor. In the sense that an end user would interact with some low level API primitives, rather than a full GUI? I’d love more examples or metaphors, or maybe a link where I could learn more.
    - snazz 7y ago
      Chuck Moore’s software is somewhat famous for reducing the complexity of both the software itself as well as the requirements. In developing a web browser, he would probably eliminate all of JavaScript, the user interface, and most of CSS, and leave it to run only on a chip he designed for the purpose. His ideology is super cool, but isn’t what is expected of software like this. For instance, OKAD (chip design and simulation CAD package) is 500 lines of colorForth. Although it includes all sorts of fancy tools, he also applied his ruthless minimalism to the requirements.
nine_k 7y ago
To sum up Chuck Moore's quotations: you write code that takes all of the machine, and you got to write all of the code. If you have this, you can squash out all abstraction and build the ideal solution directly. This may hold true for small-scale hardware like controllers. They have a well-defined set of tasks, small enough to fit in your head. This means that you have a certain trouble sharing the code with your colleagues, making the bus factor of your project closer to 1, and lowering the usefulness of code reviews. This means that you have trouble sharing code with yourself in your next project. You become tightly coupled do the machine. This is, on one hand, liberating, you can do anything easily. But this is also limiting, because you spend your mental resources on optimizing for this particular machine. I personally think that deep optimization is something that the machine should do, they are better than humans at this most of the time. And humans should do want machines currently can't.
- Twisol 7y ago
  My takeaway was that you're always writing against a machine. The difference is whether you're writing against a physical hardware machine or an abstract virtual machine. OSes and VMs abstract over existing machines and present a virtual interface for the sake of portability, but they're still themselves machines. You're still coding against a machine, and you still have to spend time learning the vicissitudes of that machine. But you also have the impedance mismatch between the virtual machine you're developing against and the physical machines you intend the software to run on. All software abstractions are, to some extent, leaky.
- astrobe_ 7y ago
  > This may hold true for small-scale hardware like controllers. They have a well-defined set of tasks, small enough to fit in your head. People usually insist that software should be modular, so that you don't have to have millions of lines of code in your head when making a local change. That's what drove the procedural evolution and later the OOP evolution. So if you're a good boy/girl/etc. you write your million-LOCs PC application as modules that are manageable for (ideally) a single person. Then you need an extra programmer to glue the modules together. > This means that you have a certain trouble sharing the code with your colleagues, making the bus factor of your project closer to 1, and lowering the usefulness of code reviews. Where does Forth prohibit peer reviews and pair programming? If you have a bus factor of 1, it is because you don't want to pay the price of increasing it. It has nothing to do with Forth; plenty of projects in super-high hyper-readable projects have a bus factor of 1. > This means that you have trouble sharing code with yourself in your next project. Not really. It's easier to copy/paste/hack Forth code. The code is more compact for various reasons: point-free style makes it less verbose, you tend to factor more intensively and you code exactly what you need. > You become tightly coupled do the machine. This is, on one hand, liberating, you can do anything easily. But this is also limiting, because you spend your mental resources on optimizing for this particular machine. No, that's the other way. When you code e.g. for a little-endian, two's complement CPU then you don't have to worry about big-endian and sign magnitude. You are actually also optimizing programmer's cycles too. Being tightly coupled to the machine is what embedded programming really is about. Embedded programming is often about writing esoteric values at occult addresses in order to bang out bits on an SPI bus. Running a Python program on Debian on a rPI is not really embedded programming.
jwilliams 7y ago
Eons ago as an embedded programmer I came to respect Forth. I encountered numerous situations where using Forth led to a much smaller footprint (size in particular) -- Why? For exactly the reasons that Chuck Moore espouses here; you are writing a purpose-built VM from the hardware up. Even then I don't agree that portability/abstraction isn't important - it's got the potential to be an extremely reductionist position. Instead I'd argue it's incredibly expensive and should be treated as such.
- nickpsecurity 7y ago
  "Instead I'd argue it's incredibly expensive and should be treated as such." Using a cross-platform framework isn't incredibly expensive in time or performance cost. It's done by one-person projects and large businesses alike. There's issues but that's way overstating it. Then, there were 4GL's like Lansa and Windev that made it easier to do than creating non-portable, native applications. Those weren't used for performance-sensitive code, though. Mostly business apps.
  - jwilliams 7y ago
    I wasn't being specific enough - I meant expensive in the most general sense. e.g. An abstraction is a cost not only in terms of (potential) performance, but developer headspace, etc, etc. The right number of abstractions is very powerful. Too many any you'll sink under the weight of them.
wwweston 7y ago
>I was also researching AI in Forth, implementing ideas from LISP examples and doing expert systems and neural nets and mixing them and building robots. In the software I added a layer for an inference engine for English language descriptions of rule sets and a layer for the rules. I wrote a learning email report and conversation engine AI program and had it running for a few months. My boss could not distinguish it from me. That was my idea of AI, smart enough to do my job for me and get paid at my salary while I took a vacation. Is the author exaggerating here, or did they actually succeed at writing something that could pass whatever Turing test level his boss could offer? If it's the latter, what then-current knowledge would they likely have sourced?
- brokenkebab 7y ago
  I can't know what the author means, but the thing which is known as chatbots now is very old tech, in fact: https://en.m.wikipedia.org/wiki/ELIZA https://en.m.wikipedia.org/wiki/ELIZA (1966)
- ianamartin 7y ago
  He’s throwing shade on his former boss
MrEldritch 7y ago
Chuck Moore has always struck me as some kind of alien, not unlike the way stories about Von Neumann do - that this is a person who is, in his specialized field, capable of thinking in ways that I just can't, and achieving things that seem practically magical with it.
- gaze 7y ago
  You might be right... but I have the impression that if you talked to him, he'd tell you that you'd get similar milage by following his philosophy about program design. It's just that most people just can't stomach it.
pilmihilmipilmi 7y ago
Does anybody know what Chuck Moore does right now? I was following a while his posts on patent lawsuite but then he went quite.

163 points by pointfree 7y ago

This is really captivating. I think I’m inspired to finally dust off my of TI-Forth for the 99/4a

Before I learned Forth, I was very comfortable in Common Lisp. Now I miss the convenience when writing Forth and raw simplicity when writing Lisp. I realize the problem isn't Forth, some people (such as the writer for example) are capable of pulling amazing feats for such a primitive tool. But as a result, the programming languages [0] I've designed since have all been part Forth and part Common Lisp. [0] https://github.com/codr7/cidk https://github.com/codr7/cidk

haolez 7y ago

Forth is pretty amazing. It really delivers on that old promise of “a language that will make you a better programmer in other languages”. However, from my experience, since there is basically no syntax, all Forth programs tend to be a DSL for the problem at hand. It’s almost like having to learn a new language ok each new project. It’s like a complete opposite of what makes Go great.

adestefan 7y ago
That is exactly what Chuck Moore wanted when inventing Forth.
- haolez 7y ago
  I know. It’s a feature, but it makes it harder to share code (and Chuck Moore believes that sharing code is rarely worth it). Maybe he is right. His productivity is unbelievable :)
  - mr_crankypants 7y ago
    The more time I spend dealing with blowback from excess complexity being imported in the form of 3rd-party libraries that offer complicated solutions to simple problems, the more I think that Chuck Moore was very, very right on that point.
    - dTal 7y ago
      Ehh... the reductio of this argument is writing everything in assembler (libc? giant hunk of third party code right there). I surmise that, by comparison, the blowback you encountered was relatively minor.
      - astrobe_ 7y ago
        No, not writing everything in assembler, this isn't about high or low level. It's about writing things yourself for what you actually need. Because most of the complexity comes from code (esp. libraries and drivers) trying to solve a larger problem than you actually have. That's the same reason why, when you follow that logic, you eventually write your own Forth. Not because it fun. Not because you want to learn about Forth or compiler. But because my Forth solves my problems the way I see fit, her Forth solves problems the way she wants, and your Forth is going to solve the way you want.
        markus_zhang 7y ago
        at least we can get rid of the bloated web apps once everyone begins to do so...but would it be possible if libaries are written in a way that it's easy to just integrate just a portion into existing code?
        mr_crankypants 7y ago
        The problem there is that most "libraries" are actually frameworks. The difference I'm drawing being, libraries just provide a mess of utility functions. Theoretically, even if your compiler won't strip the library stuff you don't need, you'd be able to take just the bits you need by copy/pasting a relatively small volume of code. And dropping the library would be a small change, that just requires finding replacements for the functions and classes you were using. Frameworks tend to involve some Grand Unifying Abstraction that you need to inherit from, and that gets imposed on your own code. Things tend to be so tangled together at a conceptual level that it's not really possible to use them in an a la carte manner. Migrating off of a framework tends to require more-or-less a rewrite of all the code that interacts with it. To take some Web examples: jQuery's more on the library side of things. D3 is more of a framework. React is very much a framework.
petjuh 7y ago
In a sense, any API that has its own functions and data structures becomes like a DSL. For example OpenGL feels like its own language, even when you write it in C or C++, or C#.
- TeMPOraL 7y ago
  Moreover, in any nontrivial application, you have modules and layers of abstractions - and those boundaries are DSLs on their own. It's actually good to think of them as languages the client code will use to write its solutions in (SICP makes this point early in the book too). People are getting too hung up on the word "language", like it was something only the most experienced and smartest of programmers were allowed to build. Nope, programmers build new languages daily in their code; it's how you abstract things.
kreetx 7y ago
Are there any good but not too large codebases where someone new to Forth could get a feel of how it's done? I'm intrigued by building DSLs, but a university course a long time ago left a totally different impression.
- pointfree 7y ago
  "Over the Shoulder 1 - Text Preprocessing in Forth" https://www.youtube.com/watch?v=mvrE2ZGe-rs https://www.youtube.com/watch?v=mvrE2ZGe-rs - Sam Falvo demonstrates writing a blog engine in Forth.
jacquesm 7y ago
I don't see the semantic difference between calling a subroutine or using a Forth word. 65 emit vs putchar(65); vs (print 'A') It's all the same to me.

elcritch 7y ago

Intriguing article. Just updated some Forth code for interfacing with an ADC on a sensor I’m building. Dealing with SPI/I2C and sensors/adc’s in Forth really is fantastic. The results in much more succinct hardware code IMHO than C or even higher level languages. Really Chuck Moore seems spot on when dealing with specific hardware. One example is a simple Forth word (macro) to convert 3 bytes into one 32 bit number integrates well into code for dealing with an adc chip. However I wouldn’t want to write while applications in Forth as dealing with stack swaps becomes annoying. Still writing your own Forth is pretty fun too. I did mine by basing C compiler XMacros which made porting to an Itsy M4 trivial (about 3-4 of work) [1]. Still there’s a few Forth’s for Arduino’s, Itsy’s, ESP’s [2] which are really fun as they enable repl style interactive programming with hardware while still being blindingly fast! 1: https://github.com/elcritch/forthwith https://github.com/elcritch/forthwith 2: https://github.com/zeroflag/punyforth https://github.com/zeroflag/punyforth

theamk 7y ago

> Portability is not possible. Real applications are closely coupled to hardware. Change the platform and all the code changes Some lessons simply did not age well.... Even in world of today's microcontrollers, which often have kilobytes of RAM and very different CPU styles, people still write mostly hardware abstracted code.

lidHanteyk 7y ago
Most code should be abstract, because the things that are specified are abstract. Some code needs to be closely coupled to hardware, but most code should only need to be closely coupled with other code.
astrobe_ 7y ago
It's the usually game of MPUs becoming cheaper or more stuffed for the same price because the demand allows to manufacture bigger batches, and the demand is to allow more portability by the means of more stuffed MPUs that allow more abstractions... But it's a miniature of the same tragedy as Node.js applications that consume ten times the resources needed just because it allows people to do more with more... In a logarithmic way.
pointfree 7y ago
> Portability is not important. Portability is not possible. Real applications are closely coupled to hardware. Change the platform and all the code changes. If it didn't, you wouldn't have changed the platform.

bcherny 7y ago

This is a really interesting read, and as someone who’s almost exclusively programmed in high level languages, this approach seems alien to me. A couple of questions: 1. Is it possible to write complex, modern applications (things like browsers, photo editors, etc. — things that would take millions of lines of Java or JS) using this style of programming? 2. What is “sourceless programming”? Where is a good place to learn more about it?

madhadron 7y ago
1. "This style" is kind of hard to pin down. If you mean Chuck Moore's dramatic minimalism, then, yes, but it won't resemble what most people in computing expect from a browser or photo editor. If you mean expressing the abstractions you want directly in the primitives you have without bothering about layers or even accepting the idea of higher vs lower levels, then, yes, certainly. It requires a lot of unlearning, though. 2. Sourceless programming was something Chuck Moore tried for a while where he designed a machine that was the virtual machine he wanted to program, implemented it in hardware, and then edited byte code directly for it. Later he stepped back and went to colorForth, which has the source/binary separation we are all accustomed to.
- bcherny 7y ago
  Thanks for the reply! > but it won't resemble what most people in computing expect from a browser or photo editor. In the sense that an end user would interact with some low level API primitives, rather than a full GUI? I’d love more examples or metaphors, or maybe a link where I could learn more.
  - snazz 7y ago
    Chuck Moore’s software is somewhat famous for reducing the complexity of both the software itself as well as the requirements. In developing a web browser, he would probably eliminate all of JavaScript, the user interface, and most of CSS, and leave it to run only on a chip he designed for the purpose. His ideology is super cool, but isn’t what is expected of software like this. For instance, OKAD (chip design and simulation CAD package) is 500 lines of colorForth. Although it includes all sorts of fancy tools, he also applied his ruthless minimalism to the requirements.

nine_k 7y ago

To sum up Chuck Moore's quotations: you write code that takes all of the machine, and you got to write all of the code. If you have this, you can squash out all abstraction and build the ideal solution directly. This may hold true for small-scale hardware like controllers. They have a well-defined set of tasks, small enough to fit in your head. This means that you have a certain trouble sharing the code with your colleagues, making the bus factor of your project closer to 1, and lowering the usefulness of code reviews. This means that you have trouble sharing code with yourself in your next project. You become tightly coupled do the machine. This is, on one hand, liberating, you can do anything easily. But this is also limiting, because you spend your mental resources on optimizing for this particular machine. I personally think that deep optimization is something that the machine should do, they are better than humans at this most of the time. And humans should do want machines currently can't.

Twisol 7y ago
My takeaway was that you're always writing against a machine. The difference is whether you're writing against a physical hardware machine or an abstract virtual machine. OSes and VMs abstract over existing machines and present a virtual interface for the sake of portability, but they're still themselves machines. You're still coding against a machine, and you still have to spend time learning the vicissitudes of that machine. But you also have the impedance mismatch between the virtual machine you're developing against and the physical machines you intend the software to run on. All software abstractions are, to some extent, leaky.
astrobe_ 7y ago
> This may hold true for small-scale hardware like controllers. They have a well-defined set of tasks, small enough to fit in your head. People usually insist that software should be modular, so that you don't have to have millions of lines of code in your head when making a local change. That's what drove the procedural evolution and later the OOP evolution. So if you're a good boy/girl/etc. you write your million-LOCs PC application as modules that are manageable for (ideally) a single person. Then you need an extra programmer to glue the modules together. > This means that you have a certain trouble sharing the code with your colleagues, making the bus factor of your project closer to 1, and lowering the usefulness of code reviews. Where does Forth prohibit peer reviews and pair programming? If you have a bus factor of 1, it is because you don't want to pay the price of increasing it. It has nothing to do with Forth; plenty of projects in super-high hyper-readable projects have a bus factor of 1. > This means that you have trouble sharing code with yourself in your next project. Not really. It's easier to copy/paste/hack Forth code. The code is more compact for various reasons: point-free style makes it less verbose, you tend to factor more intensively and you code exactly what you need. > You become tightly coupled do the machine. This is, on one hand, liberating, you can do anything easily. But this is also limiting, because you spend your mental resources on optimizing for this particular machine. No, that's the other way. When you code e.g. for a little-endian, two's complement CPU then you don't have to worry about big-endian and sign magnitude. You are actually also optimizing programmer's cycles too. Being tightly coupled to the machine is what embedded programming really is about. Embedded programming is often about writing esoteric values at occult addresses in order to bang out bits on an SPI bus. Running a Python program on Debian on a rPI is not really embedded programming.

jwilliams 7y ago

Eons ago as an embedded programmer I came to respect Forth. I encountered numerous situations where using Forth led to a much smaller footprint (size in particular) -- Why? For exactly the reasons that Chuck Moore espouses here; you are writing a purpose-built VM from the hardware up. Even then I don't agree that portability/abstraction isn't important - it's got the potential to be an extremely reductionist position. Instead I'd argue it's incredibly expensive and should be treated as such.

nickpsecurity 7y ago
"Instead I'd argue it's incredibly expensive and should be treated as such." Using a cross-platform framework isn't incredibly expensive in time or performance cost. It's done by one-person projects and large businesses alike. There's issues but that's way overstating it. Then, there were 4GL's like Lansa and Windev that made it easier to do than creating non-portable, native applications. Those weren't used for performance-sensitive code, though. Mostly business apps.
- jwilliams 7y ago
  I wasn't being specific enough - I meant expensive in the most general sense. e.g. An abstraction is a cost not only in terms of (potential) performance, but developer headspace, etc, etc. The right number of abstractions is very powerful. Too many any you'll sink under the weight of them.

wwweston 7y ago

>I was also researching AI in Forth, implementing ideas from LISP examples and doing expert systems and neural nets and mixing them and building robots. In the software I added a layer for an inference engine for English language descriptions of rule sets and a layer for the rules. I wrote a learning email report and conversation engine AI program and had it running for a few months. My boss could not distinguish it from me. That was my idea of AI, smart enough to do my job for me and get paid at my salary while I took a vacation. Is the author exaggerating here, or did they actually succeed at writing something that could pass whatever Turing test level his boss could offer? If it's the latter, what then-current knowledge would they likely have sourced?

brokenkebab 7y ago
I can't know what the author means, but the thing which is known as chatbots now is very old tech, in fact: https://en.m.wikipedia.org/wiki/ELIZA https://en.m.wikipedia.org/wiki/ELIZA (1966)
ianamartin 7y ago
He’s throwing shade on his former boss

MrEldritch 7y ago

Chuck Moore has always struck me as some kind of alien, not unlike the way stories about Von Neumann do - that this is a person who is, in his specialized field, capable of thinking in ways that I just can't, and achieving things that seem practically magical with it.

gaze 7y ago
You might be right... but I have the impression that if you talked to him, he'd tell you that you'd get similar milage by following his philosophy about program design. It's just that most people just can't stomach it.

pilmihilmipilmi 7y ago

Does anybody know what Chuck Moore does right now? I was following a while his posts on patent lawsuite but then he went quite.