3 ms·

What if it had a really powerful debugger?

eropple 10y ago
Having a "powerful debugger" is orthogonal to "can I dynamically define classes at runtime, when that makes sense to solve my problems?" and "can I load a library that's annotated to make for a simple extension system?". Like, take a look at this[1]. I wrote it for a game engine in C#. It allows for dynamic loading of modules or static packaging on platforms that require it. This is what I would consider a low-end thing for a Ruby application that needed extensibility--just something you do out of hand. Crystal can't do that. Maybe it will in the future, but it's not even a 1.0 feature. So Crystal might be a challenge to a Golang-ish thing, but it's not a challenge to a Ruby or a JVM/CLR thing on that front. [1] - https://github.com/eropple/Exor https://github.com/eropple/Exor
- AstralStorm 10y ago
  Do you really need to define code at runtime? Why not at compile time? Need to pull in templates and macros made by someone, but not the code that uses them? Plugins have a long tradition already, starting with the old dlopen and loadLibrary. Even in C++ (mostly) you can have it done, just look at Qt.
  - chrisseaton 10y ago
    > Do you really need to define code at runtime? The people who wrote Rails thought they did - it defines tons of code at runtime. We can't say that they needed to or not. Nobody needs a programming language abstraction. But it worked for them.
  - eropple 10y ago
    Well, for one, Crystal doesn't support PIC, so you can't write dynamic code in the first place. For two: yeah, I very regularly do need to define code at runtime. Consider ActiveRecord (or, like, all of Rails, but ActiveRecord specifically), which hits up your database for its schema at runtime to build its API. Consider that it's totally normal in Ruby to use an `if` statement in your class definition; for example, I will replace entire implementations of functionality if I know I'm running in JRuby rather than MRI, without having to add some weird thunking layer. Consider that it's normal to not only `extend` other people's classes, but to write `self.extended` hooks in your own classes to respond to it. A class in Ruby is just an object. It is not a Class, it inherits from Class. Mutating them to achieve your goals is commonplace and valuable. It's the closest thing to brain candy as a meaningful, good Lisp I've used since college. (Clojure is not my thing. And obviously I know that Ruby has a lot of Smalltalk-ish stuff in it rather than Lisp, but I never used Smalltalk...) You can fake a lot in a compiled language. I have done this. But you had better be getting significant wins for doing it, and something like Crystal does not offer them over something like Ruby unless you're doing something that doing it in Ruby was a bad idea in the first place. (If you wrote something in Ruby where you actually cared about perf, for example, you picked wrong.) Right now, writing Rust plugins and using them from Ruby is a more Ruby experience than Crystal is. Which isn't a shot at the language, I have to stress--just that it's not Ruby, it's something very different.

Having a "powerful debugger" is orthogonal to "can I dynamically define classes at runtime, when that makes sense to solve my problems?" and "can I load a library that's annotated to make for a simple extension system?". Like, take a look at this[1]. I wrote it for a game engine in C#. It allows for dynamic loading of modules or static packaging on platforms that require it. This is what I would consider a low-end thing for a Ruby application that needed extensibility--just something you do out of hand. Crystal can't do that. Maybe it will in the future, but it's not even a 1.0 feature. So Crystal might be a challenge to a Golang-ish thing, but it's not a challenge to a Ruby or a JVM/CLR thing on that front. [1] - https://github.com/eropple/Exor https://github.com/eropple/Exor

AstralStorm 10y ago
Do you really need to define code at runtime? Why not at compile time? Need to pull in templates and macros made by someone, but not the code that uses them? Plugins have a long tradition already, starting with the old dlopen and loadLibrary. Even in C++ (mostly) you can have it done, just look at Qt.
- chrisseaton 10y ago
  > Do you really need to define code at runtime? The people who wrote Rails thought they did - it defines tons of code at runtime. We can't say that they needed to or not. Nobody needs a programming language abstraction. But it worked for them.
- eropple 10y ago
  Well, for one, Crystal doesn't support PIC, so you can't write dynamic code in the first place. For two: yeah, I very regularly do need to define code at runtime. Consider ActiveRecord (or, like, all of Rails, but ActiveRecord specifically), which hits up your database for its schema at runtime to build its API. Consider that it's totally normal in Ruby to use an `if` statement in your class definition; for example, I will replace entire implementations of functionality if I know I'm running in JRuby rather than MRI, without having to add some weird thunking layer. Consider that it's normal to not only `extend` other people's classes, but to write `self.extended` hooks in your own classes to respond to it. A class in Ruby is just an object. It is not a Class, it inherits from Class. Mutating them to achieve your goals is commonplace and valuable. It's the closest thing to brain candy as a meaningful, good Lisp I've used since college. (Clojure is not my thing. And obviously I know that Ruby has a lot of Smalltalk-ish stuff in it rather than Lisp, but I never used Smalltalk...) You can fake a lot in a compiled language. I have done this. But you had better be getting significant wins for doing it, and something like Crystal does not offer them over something like Ruby unless you're doing something that doing it in Ruby was a bad idea in the first place. (If you wrote something in Ruby where you actually cared about perf, for example, you picked wrong.) Right now, writing Rust plugins and using them from Ruby is a more Ruby experience than Crystal is. Which isn't a shot at the language, I have to stress--just that it's not Ruby, it's something very different.