3 ms·

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.

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.