81–90 of 93 posts
Earlier quoted context omitted.
Spinel would be more interesting if this compiled subset could run side by side with interpreted Ruby, like Pallene does for (slightly modified) Lua.
Right now the cost of c interop in ruby is too high. It's actually more perfomant in the general case to rewrite any c lib wrappers in pure ruby these days and let jit do the work
Earlier quoted context omitted.
> eval, send, method_missing, define_method , as a non-rubyist how common are these in real-world code? Quite a lot, that's what allows you to build something like Rails with magic sprinkled all around. I'm not 100% sure, but probably the untyped JSON ingestion example uses those. Remove that, and you have a very compact and readable language that is less strongly typed than Crystal but less metaprogrammable than off…
> Quite a lot, that's what allows you to build something like Rails with magic sprinkled all around True, but I'd point out that use in frameworks/DSLs etc is the main place you see those things, and most of the code people write in their own projects don't use these. In my experience (YMMV), eval and send are rare outside of things like, slightly cowboy unit tests (send basically lets you call private methods that y…
In my opinion the main draw of Ruby is that it's kind of Lisp-y in the way you can quickly build a metalanguage tailored to your specific problem domain. For problems where I don't need metaprogramming, I'd rather use a language that is statically typed.
While obviously super-impressive, it is clearly not maintanable without AI agent. It has spinel_codegen.rb is 21k lines of code with up to 15 levels of nesting in some methods. Compilers code was never pretty, but even by those standard, I feel like it is a very-very hard to maintain code by humans.
Compiler code can be pretty if you have the time to maintain it. Compilers are some of the most modular applications you can build with hard boundaries between subsystems and clear handoffs at each level. The problem is that people often do not have the time to refactor once they have gotten the thing to work. And the mess keeps growing.
Those are pervasive in any old and large project but in my experience especially so in compilers.
Earlier quoted context omitted.
Compiler code can be pretty if you have the time to maintain it. Compilers are some of the most modular applications you can build with hard boundaries between subsystems and clear handoffs at each level. The problem is that people often do not have the time to refactor once they have gotten the thing to work. And the mess keeps growing.
And the migrations. Or rather all the half-started migrations that never get through meaning you have to deal with api v1,2,3 all the times. Those are pervasive in any old and large project but in my experience especially so in compilers.
Compilers should not have so much churn. You decide on a set of language features, stick to it and implement. After that, it should only be bugfixes for the foreseeable future till someone can make a solid case for that shiny new feature.
Scope creep is bane of most projects.
While obviously super-impressive, it is clearly not maintanable without AI agent. It has spinel_codegen.rb is 21k lines of code with up to 15 levels of nesting in some methods. Compilers code was never pretty, but even by those standard, I feel like it is a very-very hard to maintain code by humans.
spinel_codegen.rb is an eldritch horror. I always get spaghetti code like this when using Claude, and I've been wondering if I'm doing something wrong. Now I see an application that looks genuinely interesting (not trivial slop) written by someone I consider to be a top notch programmer, and the code quality is still pretty garbage in some places. For example infer_comparison_type() [1]. This is far from the worst of…
I find it easier to reason about and as it ages, stays maintainable vs more elsif branches with multiple conditions each.
Earlier quoted context omitted.
The most recent cartoon Spinel in my mind is from Steven Universe, so I hadn't noticed the Spinel/Ruby (Moon) pun, that made my day.
I never expected SU to come up in HN! Unfortunately, it wouldn't be the best reference...
Earlier quoted context omitted.
> Quite a lot, that's what allows you to build something like Rails with magic sprinkled all around True, but I'd point out that use in frameworks/DSLs etc is the main place you see those things, and most of the code people write in their own projects don't use these. In my experience (YMMV), eval and send are rare outside of things like, slightly cowboy unit tests (send basically lets you call private methods that y…
I disagree, I use metaprogramming in application code quite regularly, although I tend to limit myself to a single construct (instance_eval) because I find that makes things more manageable. In my opinion the main draw of Ruby is that it's kind of Lisp-y in the way you can quickly build a metalanguage tailored to your specific problem domain. For problems where I don't need metaprogramming, I'd rather use a language…