What? You could write several commands on one line in CP/M assembler:

  LHLD 0 ! XCHG ; zero DE

I dont remember MSDOS Masm having such feature?

Xubuntu. It is Ubuntu with XFCE. Windowing systems are often surprisingly crappy in multi-screen situation. XFCE may not be most refined, but what it does is robust and without surprises.

You can insert scanned object into OpenSCAD, but it is just a surface map and very easily the model becomes too large. Is this problem now solved?

wdym?

For example: I scan a ball into STL-file. I can include it into my OpenSCAD design, but it is not a OpenSCAD-sphere, just a sphere-shaped surface with billions of facets.

Problem with Forth and Lisp is that you can freely start to improve language, so it sort of destroys the usefulness in a company of full of Salarymen and Office Droids.

Here is Grok's scheme to make Forth more readable:

  Below is a Forth implementation of a simple parser that transforms
  (. (+ 1 2)) into 1 2 + . and executes it. This assumes the input is
  provided as a string or entered interactively, and the parser outputs
  the transformed Forth code to the input stream for execution.
  
  
  \ Buffer to store transformed output
  20 CONSTANT BUF-SIZE
  CREATE BUF BUF-SIZE ALLOT
  VARIABLE BUF-PTR
  
  : INIT-BUF ( -- )
    BUF BUF-SIZE ERASE
    0 BUF-PTR ! ;
  
  : ADD-TO-BUF ( c -- )
    BUF-PTR @ BUF-SIZE < IF
      BUF BUF-PTR @ + C!
      1 BUF-PTR +!
    ELSE
      ." Buffer overflow" ABORT
    THEN ;
  
  : PARSE-EXPR ( addr u -- )
    INIT-BUF
    BEGIN
      DUP 0> WHILE
      OVER C@ CASE
        '(' OF DROP 1 /STRING ENDCASE  \ Skip (
        ')' OF DROP 1 /STRING ENDCASE  \ Skip )
        '.' OF BL ADD-TO-BUF '.' ADD-TO-BUF BL ADD-TO-BUF
               DROP 1 /STRING ENDCASE
        '+' OF BL ADD-TO-BUF '+' ADD-TO-BUF BL ADD-TO-BUF
               DROP 1 /STRING ENDCASE
        BL OF BL ADD-TO-BUF DROP 1 /STRING ENDCASE  \ Handle spaces
        ELSE
          DUP ADD-TO-BUF  \ Copy number characters
          DROP 1 /STRING
        ENDCASE
      REPEAT
    2DROP ;
  
  : EVAL-EXPR ( addr u -- )
    PARSE-EXPR
    BUF BUF-PTR @ EVALUATE ;  \ Execute the transformed string
  
  \ Example usage
  : TEST ( -- )
    S" (. (+ 1 2))" EVAL-EXPR ;
  
  TEST

Did you actually test that code? Never mind the tiny buffer size or possible hallucinations, but just from looking at the "parser", it does seem to do nothing more than copy the expected tokens in the same order it reads them on input, ignoring any parentheses.

This CAN'T possibly work, not even for the example input. Maybe if it reversed the string, but unless I've forgotten completely how to read Forth it doesn't do even that.

And for some reason this kind of garbage is apparently the future of programming, and people seem compelled to post it everywhere...

This was kinda joke. I have done it in real life, but that was in 1976. And the mechanism was totally different, more Lisp-like, but could not make Grok to do it, so I suggested simple pre-parser.

What I really wanted was a "pascal-type" tokenizer and second stack for commands. "(" means push next and ")" means pop and execute. In this kind of system (if (< a 1) (setq a (+ a 2))) is totally valid without much overhead and about 187% more readable than Forth.

  And yes I know it is not Lisp, perse.

Also Lisp isn't just about a prefix syntax, it's the whole eval/apply and lists.

Bloody Grok does not seem tobe able to make generic parser, so that Forth whitespace requirements can be ignored. When said I want "Pascal-type" tokenizer, it started to print Pascal-language compiler, which was amazingly complex and long. I cannot imagine many humans can produce that much Forth and survive.

Hey Grok: Write commonlisp macro "test", which is usually an addition, but when two parameters are already numbers, it is the sum of those numbers.

  (defmacro test (a b)
    (if (and (numberp a) (numberp b))
        (+ a b)
        `(+ ,a ,b)))

These are very strange statements, coming from you. Please teach the kids properly! :)

Bad memories. Some malformed macro may evaluate differently than compile and the problem is impossible to find.

This is a feature. It is something you want sometimes and don't want at other times.

Macros can stage calculations to compile time. Compile time can happen in a completely different environment from run-time, such as on a different machine. It only happens once, whereas run-time can repeat many times.

A macro can be designed to that it opens a specific file, reads the content and generates some code based on that (or simply includes the file as a literal constant). That file exists only on the build machine, perhaps part of the source tree of the program. Thus, compiled code containing the macro call can run anyhere, but source code containing the macro cannot be evaled anywhere.

Hey Grok: Does commonlisp have some mechanism to prevent malformed macro to do things globally, so that eval works differently than compile?

  Grok: Yes.
  < 5 pages of semi-incomprehensible explanations omitted >

Excellent.

I remember we learned to read and write in one month in Finnish school. If this did not happen, one was officially classified as retarded (in 1950s). How long it takes average american to achieve errorfree skills?

Grok:... In USA on average, achieving consistent error-free literacy might take 4-6 years of schooling (kindergarten through fourth grade), but this varies widely.

Look for [flagged] and [dead], that is where the discussion is. Rest is just NPCs repeating same pointless platitudes.

  You need to change the settings for this.

Remember seeing such plant in 1980 in Nevada. Train conductor pointed it out and joked about cooked birds too. Very strange they built a new one, just when 10 watt panel was reduced from $100 to $10.

There was no internet, so unless you were connected to educational organization and their curriculum, there was no way to get information of various topics in somewhat palatable way. BYTE changed all that, and suddenly everybody could learn all about Prolog and Smalltalk and other Scheiße.

Ah okay, yeah fair enough. I thought the guy was talking about the specific magazine issue of Smalltalk.

He was: he pointed out that the world of computing he (we) knew back then is illustrated in all the ads. Note that August 1981 is also the month the original IBM PC came out. In contrast the articles showed a world of computing with mice, overlapping windows, menus, cut/copy/paste.

A comment in the video pointed out that the mouse had been invented back in 1964 and claiming it was not common is a cop out. The author of the video didn't know about it before this issue and I didn't know about it. But now we knew, and for how many others was this true?

"Scheiße"

Bad memories of Smalltalk. Current implementation did not scale up.

Good memories of Smalltalk. (Was it Smalltalk or was it me?)

> Current implementation did not scale up.

Did the prototype suggest it would?

I was not in that project, but I heard it just suddenly choked up, just when the model was becoming useful.

There was no mention in the box that there was a limit. It was the fancy version with EMS-support, so it was not a hardware problem.

Not your memories of Smalltalk.