3 ms·

This reminds me a lot of GOAL, the in-house videogame development language that we used to use at Naughty Dog. It had a LISP syntax and feel - complete with awe

by strags 13y ago

This reminds me a lot of GOAL, the in-house videogame development language that we used to use at Naughty Dog. It had a LISP syntax and feel - complete with awesome metaprogramming and on-the-fly relinking - but the runtime was much closer to a low-level C/C++. In fact, you could even drop into MIPS asm in the middle of a function. Coming from a mostly C/C++ background, it was an eye-opening experience, and I'm definitely a fan of languages other than C for performant code.

pjmlp 13y ago
C and later on C++ just got widespread due to UNIX's adoption at the enterprise, before that, there were quite a few systems programming languages around. Of course, youngsters nowadays tend to think only C and C++ play on that league.
- zhemao 13y ago
  Interesting. Which ones in particular were popular? And what do you consider a "systems programming language"? As I understand it, a systems programming language is a language that can be used to implement an operating system. C was the first high-level language to be used in this way.
  - pjmlp 13y ago
    Algol 68, PL/I, PL/M, Ada, Modula-2, Modula-3, Oberon, Extensions to Pascal like Apple Pascal and Turbo Pascal, Lisp
zhemao 13y ago
I've heard about that and it sounds awesome. Can you say anything more about its design and syntax? For instance, I've heard that you could do manual memory management in GOAL. How was that accomplished?
- strags 13y ago
  It's been a while, so my memory's a little fuzzy. If I remember correctly, all the code was s-expressions, piped through a scheme (?) preprocessor, and then into the compiler. Many of the basic language constructs were actually macros. The lower-level language itself was statically typed, and supported pointers and arrays as native types - identical to their C equivalents. Classes either derived from "structure" (unboxed) or "boxed". The boxed types had a class pointer, much like a C++ vtable ptr, but with some more useful introspective data attached. Runtime linkage was mostly accomplished by patching types' method slots and/or patching a global symbol table. The compiler talked to a MySQL database which was shared by the whole company, so that symbols wound up having unique and consistent ids across all machines. The "listener" ran on a PS2 devkit, and essentially just accepted object code to link and execute. The REPL worked by having the compiler compile each expression, squirt the MIPS object code over to the PS2, have the PS2 link and execute it, and return a result, which the compiler would then print (possibly peeking into the PS2's memory in order to display more useful information). Similarly, you could place your cursor inside a block of code, hit CTRL+T and have just that function/method updated on the target. (This was back when edit-and-continue was still something of a novelty!) The ABI was close enough to C that GOAL and C could call each other almost directly (the MIPS GP register had different meanings in GOAL vs C code, and so had to be patched up). You could also pretty much mix GOAL and assembly, and we frequently did. GOAL's backend was never going to be as efficient as gcc's, but the massive increase in productivity it provided meant that we could devote much more time to optimizing the stuff that really mattered. I think Andy Gavin's on here somewhere - he should really write an article about it if he hasn't already :)

by strags 13y ago

pjmlp 13y ago

C and later on C++ just got widespread due to UNIX's adoption at the enterprise, before that, there were quite a few systems programming languages around. Of course, youngsters nowadays tend to think only C and C++ play on that league.

zhemao 13y ago
Interesting. Which ones in particular were popular? And what do you consider a "systems programming language"? As I understand it, a systems programming language is a language that can be used to implement an operating system. C was the first high-level language to be used in this way.
- pjmlp 13y ago
  Algol 68, PL/I, PL/M, Ada, Modula-2, Modula-3, Oberon, Extensions to Pascal like Apple Pascal and Turbo Pascal, Lisp

zhemao 13y ago

I've heard about that and it sounds awesome. Can you say anything more about its design and syntax? For instance, I've heard that you could do manual memory management in GOAL. How was that accomplished?

strags 13y ago
It's been a while, so my memory's a little fuzzy. If I remember correctly, all the code was s-expressions, piped through a scheme (?) preprocessor, and then into the compiler. Many of the basic language constructs were actually macros. The lower-level language itself was statically typed, and supported pointers and arrays as native types - identical to their C equivalents. Classes either derived from "structure" (unboxed) or "boxed". The boxed types had a class pointer, much like a C++ vtable ptr, but with some more useful introspective data attached. Runtime linkage was mostly accomplished by patching types' method slots and/or patching a global symbol table. The compiler talked to a MySQL database which was shared by the whole company, so that symbols wound up having unique and consistent ids across all machines. The "listener" ran on a PS2 devkit, and essentially just accepted object code to link and execute. The REPL worked by having the compiler compile each expression, squirt the MIPS object code over to the PS2, have the PS2 link and execute it, and return a result, which the compiler would then print (possibly peeking into the PS2's memory in order to display more useful information). Similarly, you could place your cursor inside a block of code, hit CTRL+T and have just that function/method updated on the target. (This was back when edit-and-continue was still something of a novelty!) The ABI was close enough to C that GOAL and C could call each other almost directly (the MIPS GP register had different meanings in GOAL vs C code, and so had to be patched up). You could also pretty much mix GOAL and assembly, and we frequently did. GOAL's backend was never going to be as efficient as gcc's, but the massive increase in productivity it provided meant that we could devote much more time to optimizing the stuff that really mattered. I think Andy Gavin's on here somewhere - he should really write an article about it if he hasn't already :)