4 ms·

> he needed four different programming languages. No single language was suited to the task at hand Are we so behind in the world of software development that

> he needed four different programming languages. No single language was suited to the task at hand Are we so behind in the world of software development that people don't understand the concept of metaprogramming? If you have to write code for two or more languages, just use a meta-language (it could be Python or Lisp, for example) to write code for each language as needed. People discovered this concept as far back as the 70s (see how Smalltalk is implemented for example).

fluidcruft 12y ago
Problem: You have to deal with 4 languages. Solution: Use "metaprogramming"! Problem: You have to deal with 5 languages and 4 bespoke translators.
- vinceguidry 12y ago
  I'd just use Ruby or Lisp, depending on whichever you know better. Wrap the domain concepts you're working with in classes, and use templating to deal with the other languages. Don't bother with translators, just wrap IO. The most exciting development I can think of is gradual typing. I don't want Ruby to be fast. I mean, definitely make performance improvements, but in order to be truly fast, you need an honest-to-goodness static compiler that understands machine code better than you ever will. Can't use one on Ruby 'cause it's not static. But if you can build up your type system gradually, so it emerges as your domain model does, then you can get all the benefits of rapid iteration while still preserving your ability to eventually make it fast without rewriting it in another language. Imagine being able to compile to C in production, while keeping it in Ruby in development and testing. Best of both worlds. If the static step gives you problems, just switch it off and report a bug.
  - ska 12y ago
    Your second paragraph illustrates the issue with lumping ruby and lisp together. Lisp is already fast, in some common lisps (e.g. sbcl) you have a compiler that gets within about 2x of a good optimizing c compiler, which is pretty good. So in some sense, it already has the best of both worlds (more powerful than a ruby or python, faster than most languages when compiled). I think the reasons it did't take over the world have nothing to do with the technical core, and everything to do with ecosystem and network effects.
    - vinceguidry 12y ago
      I've a hunch that the speed of those flavors of Lisp is coming from a bunch of really smart people basically spending their entire careers optimizing it. Which gives me hope that Ruby can get there too. > ecosystem and network effects. Which is a really important consideration. Technologies are a dime a dozen, community is rare and ephemeral. If you can build a solid, robust community around your tech, it doesn't matter what the limitations are.
      - ska 12y ago
        Actually most of these compilers have pretty small teams, and in some cases part time volunteer effort has done a lot of the optimizer But language design really matters, for example one guy put together a JIT for lua that is roughly as fast as the JVM. He's good at it, but he wouldn't have been able to do the same thing with Java (or, I expect ruby) on his own....
- agentultra 12y ago
  ... and that hasn't been a problem for programmable programming languages like Common Lisp. In fact, it's a strength. A great example is GLSL. It's a great system but the context switching required by the programmer and the plumbing necessary to send the compiled program to the graphics card... tedious. cbaggers is working on a CL package that provides a DSL that compiles from Lisp to GLSL code and helpers which compile and upload the code for you. You can essentially live-edit GLSL code without switching gears. This is useful.
Hortinstein 12y ago
maybe I am not understanding what you mean, but I thought that metaprogramming still involved knowing both/multiple languages. I get the sense from the article that he was trying to eliminate the overhead of glue-code and meta-languages while also preventing context switching between languages.

fluidcruft 12y ago

Problem: You have to deal with 4 languages. Solution: Use "metaprogramming"! Problem: You have to deal with 5 languages and 4 bespoke translators.

vinceguidry 12y ago
I'd just use Ruby or Lisp, depending on whichever you know better. Wrap the domain concepts you're working with in classes, and use templating to deal with the other languages. Don't bother with translators, just wrap IO. The most exciting development I can think of is gradual typing. I don't want Ruby to be fast. I mean, definitely make performance improvements, but in order to be truly fast, you need an honest-to-goodness static compiler that understands machine code better than you ever will. Can't use one on Ruby 'cause it's not static. But if you can build up your type system gradually, so it emerges as your domain model does, then you can get all the benefits of rapid iteration while still preserving your ability to eventually make it fast without rewriting it in another language. Imagine being able to compile to C in production, while keeping it in Ruby in development and testing. Best of both worlds. If the static step gives you problems, just switch it off and report a bug.
- ska 12y ago
  Your second paragraph illustrates the issue with lumping ruby and lisp together. Lisp is already fast, in some common lisps (e.g. sbcl) you have a compiler that gets within about 2x of a good optimizing c compiler, which is pretty good. So in some sense, it already has the best of both worlds (more powerful than a ruby or python, faster than most languages when compiled). I think the reasons it did't take over the world have nothing to do with the technical core, and everything to do with ecosystem and network effects.
  - vinceguidry 12y ago
    I've a hunch that the speed of those flavors of Lisp is coming from a bunch of really smart people basically spending their entire careers optimizing it. Which gives me hope that Ruby can get there too. > ecosystem and network effects. Which is a really important consideration. Technologies are a dime a dozen, community is rare and ephemeral. If you can build a solid, robust community around your tech, it doesn't matter what the limitations are.
    - ska 12y ago
      Actually most of these compilers have pretty small teams, and in some cases part time volunteer effort has done a lot of the optimizer But language design really matters, for example one guy put together a JIT for lua that is roughly as fast as the JVM. He's good at it, but he wouldn't have been able to do the same thing with Java (or, I expect ruby) on his own....
agentultra 12y ago
... and that hasn't been a problem for programmable programming languages like Common Lisp. In fact, it's a strength. A great example is GLSL. It's a great system but the context switching required by the programmer and the plumbing necessary to send the compiled program to the graphics card... tedious. cbaggers is working on a CL package that provides a DSL that compiles from Lisp to GLSL code and helpers which compile and upload the code for you. You can essentially live-edit GLSL code without switching gears. This is useful.

Hortinstein 12y ago

maybe I am not understanding what you mean, but I thought that metaprogramming still involved knowing both/multiple languages. I get the sense from the article that he was trying to eliminate the overhead of glue-code and meta-languages while also preventing context switching between languages.