Live data from Hacker News

Uniform Structured Syntax, Metaprogramming and Run-Time Compilation

m00natic.github.io

41–45 of 45 posts

Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation

#41
post #27
post #23

Earlier quoted context omitted.

> Yes, that's what I remembered, they started out using LISP. Only for the optimizer and the inference engine. The authors also had no prior experience developing an application in a hybrid of C and Lisp. > "Terrible mistake" is pretty unambiguous language. 4MB memory footprint was a terrible mistake at that time.

They obviously started writing Postgres in LISP, because "we soon realized that parts of the system were more easily coded in C" wouldn't make sense if writing a hybrid had been the initial plan. They tried going all LISP at first, and failed. Was it them, or was it LISP?

Since they had no experience in Lisp programming, they chose the wrong language just for 'doing something different'.

Writing a database in a performant way isn't something for a Lisp newbie.

"By the time Version 1 was operational, it contained about 17000 lines of LISP and about 63000 lines of C".

Version 1 was written in a mix of C and Lisp.

That's also not surprising, since that would have been a common approach for some technical reasons. But it's a bit difficult to do - again, especially as a newbie.

> Was it them, or was it LISP?

Their lack of experience, their approach, the LISP implementation they were using, the hardware constraints (4 MB footprint was not acceptable to them), ... A conservative approach using a lower-level systems programming language like C was a good choice at that time and they were much more successful with that approach.

There were/are a bunch of databases written in Lisp and even in a mix of C and Lisp: Statice (Symbolics), Zeitgeist (TI), Orion/Itasca, AllegroStore (Franz), ... But they were written by Lisp experts.

Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation

#42
post #26

Earlier quoted context omitted.

True, `my-dsl-1-macro` potentially does anything inside its syntactic parentheses extent, including possibility manipulating syntax within it that someone just glancing at the code might assume is a code snippet that's pasted in verbatim, including what looks like a use of `my-dsl-2-macro`. The verbatim paste seems like the usual case for macros. This kind of potential expectation violation isn't specific to macros.…

Sure, the point I was trying to make is that macros add yet another layer of potential violation of expectation. It's hard (for me) to say whether their dangers outweigh their benefits (my guess is probably not), but it is something worthy of consideration to understand where anti-macro opinions come from.

That concern sounds reasonable. It doesn't help that there's wide variation in the nature and quality of macro/DSL/minilanguage/metaprogramming stuff people see.

Personally, I'm very comfortable working with reasonable programmers using macros in Racket. And most CL programmers are very sharp, and could be trusted to use restraint with their more dynamic tools (especially if you're talking about work, rather than creative personal side projects).

For that matter, some non-macro/template overriding features of C++ pack more astonishment than syntax extension in Racket. And I wonder how much some suspicion of a good macro system is due to prior experience with languages like C++.

Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation

#43
post #39

Earlier quoted context omitted.

That doesn't support the post's argument, that it's not about aesthetics, but about qualitatively simpler solutions. > Often times I hear the claim that (programming language) syntax doesn't matter or if it does, it's only to provide some subjective readability aesthetics. It's somewhat surprising to me how large majority of supposedly rational people like programmers/computer scientists would throw out objectivity w…

Well, dynamic queries by end users is the main goal here. Your static helper functions are completely unusable in that context. Analysing a query and generating code at runtime is easy and idiomatic with uniform syntax (and accompanying language support) and the claim is that solution is not only speedier but implementation in CL is qualitatively simpler than the alternatives.

The point my first comment made is that you don't need to analyse a query at runtime, you just need to provide functions. I will agree again that Lisp makes REPLs easier to write than does C++, but a CL with Lua syntax could still, just as easily, provide functions and expose a REPL. It's the same solution, just without the unjustified AST transformations.

Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation

#44
post #43

Earlier quoted context omitted.

Well, dynamic queries by end users is the main goal here. Your static helper functions are completely unusable in that context. Analysing a query and generating code at runtime is easy and idiomatic with uniform syntax (and accompanying language support) and the claim is that solution is not only speedier but implementation in CL is qualitatively simpler than the alternatives.

The point my first comment made is that you don't need to analyse a query at runtime, you just need to provide functions. I will agree again that Lisp makes REPLs easier to write than does C++, but a CL with Lua syntax could still, just as easily, provide functions and expose a REPL. It's the same solution, just without the unjustified AST transformations.

How can you provide a REPL language without analyzing it at runtime? Write Lua random syntax in the REPL? Not a great improvement over C++. Not to mention that you'll probably use something like `eval` which is not compilation thus inferior.

By the way, even your original example - I can't see how it can work honestly. How can you identify fields through (lambda) parameter names only (no mention of types either)? Probably the least boilerplate-heavy solution would be stringly typed.

Re: Uniform Structured Syntax, Metaprogramming and Run-Time Compilation

#45
post #43

Earlier quoted context omitted.

The point my first comment made is that you don't need to analyse a query at runtime, you just need to provide functions. I will agree again that Lisp makes REPLs easier to write than does C++, but a CL with Lua syntax could still, just as easily, provide functions and expose a REPL. It's the same solution, just without the unjustified AST transformations.

How can you provide a REPL language without analyzing it at runtime? Write Lua random syntax in the REPL? Not a great improvement over C++. Not to mention that you'll probably use something like `eval` which is not compilation thus inferior. By the way, even your original example - I can't see how it can work honestly. How can you identify fields through (lambda) parameter names only (no mention of types either)? Pro…

A Lua REPL is hardly worse than a Lisp one.

> something like `eval` which is not compilation thus inferior

I honestly don't know what that means. Turning text into code is compilation; there is no difference between the two in that regard, except perhaps that in the Lisp DSL case it's more manual.

> How can you identify fields through (lambda) parameter names only (no mention of types either)?

Not familiar enough with Lua, but in Python you just use keyword arguments.

Post reply on HN