4 ms·

I'm with you on this; I can't reply to the sibling comment, but I'll elaborate on what this means in my own professional practice. I did a dual-major in CS and

I'm with you on this; I can't reply to the sibling comment, but I'll elaborate on what this means in my own professional practice. I did a dual-major in CS and EE, and then an MSc in CS. While I'm a little fuzzy on the specific details of the current transistor geometries (14nm?! that's wild!), I do pretty much understand the entire stack upwards from there. I could design a fully-functional computer from the logic gate level, although it likely would be slow as hell and be exceptionally boring. It's not my strong point, but I understand enough about what's going on. Honestly, most of my electronic design work these days is analog circuits slung onto the side of a microcontroller, with code written in C. I'll do schematic design and capture, and board layout without too much difficulty. Going up from there, I've written my own (toy) operating system from scratch. I've written Linux kernel drivers for both off-the-shelf devices and for custom devices implemented in FPGAs. High-bandwidth/low-latency TCP servers written in C. My own (toy) programming language. I've written C extensions for PHP and Python, and have done pretty intense profiling work on them; this requires a pretty deep understanding of how the internals of the interpreter work (part of my MSc coursework). And I've done web apps in PHP, Python, Ruby, and Elixir. The whole point of this is that I'm totally comfortable going as deep into the stack of abstractions as necessary to solve whatever problem I'm facing. When I started learning Rails, I was mystified by all of the "magic". I'd never even really used Ruby, let alone all the extra stuff Rails does. But I set up the emacs-bundler library (https://github.com/tobiassvn/bundler.el https://github.com/tobiassvn/bundler.el) and started diving in. I'd work through a tutorial, and every time I encountered something I didn't understand, I'd dive into the guts of Rails (bundle-open activerecord) and read the code until I understood it. As an example of going a layer deeper, I once encountered a bug in a Python script that used PySerial. There were multiple threads, and the script would hang sometimes. I read through my code and couldn't find any problems, so I dug deeper into the PySerial code. Nothing obvious in the .py file for PySerial, so I dug deeper into the C extension. In the C code, I discovered that there was one case where the GIL wasn't being properly released before doing a (sometimes) blocking call! Tada! The script worked great if the call didn't block, but hung if it did.

sanderjd 11y ago
I think there's a subtle difference between what your parent said and what you're saying: they suggested that they know what's going on at every level, and you merely claim that you can figure out what's going on, if need be. (A charitable reading would be that they meant the same thing though.) I think we should all aspire to this level of having enough of a mental model for all the layers underneath us that we can go dig into them when needed. But it takes a lot of effort to get to the point you're at, so it's a pretty big ask. (Also, most of us probably can't go back to a university to learn the EE side, and it's not easy to self-learn it.) Having said all that, for Rails specifically, it's pretty easy to do exactly what you did and just open up Rails and other library code. It's almost entirely simple method definitions, and the parts that aren't can be understood if you go read about how `define_method`, `method_missing`, and `const_get` work. The "Rails is magic" meme seems to either scare people off from reading the code, or give people permission to be lazy about it.
- evilduck 11y ago
  Especially with pry existing now, the "Rails is magic" meme is tired and incorrect. Install pry, pry-rails. Something weird occurs? binding.pry, `show-method` or `show-source` and it dumps you to the exact line and filepath of the method, be it the original or a monkeypatched method (use -a to show them). Keep digging like that and you'll eventually hit the C implementation code. [18] pry(String):1> show-method length From: string.c (C Method): Owner: String Visibility: public Number of lines: 5 VALUE rb_str_length(VALUE str) { return LONG2NUM(str_strlen(str, NULL)); }
  - rudolf0 11y ago
    I wish other REPLs were like this. IPython does it too, but not sure others can.
- jwdunne 11y ago
  Your last point really stood out to me. Reading through the commentary, it's difficult to see what is so magical about Rails after spending a lot of time using and especially abusing vanilla Ruby. Sure, I can concede that code that tries to do too much for you to the point where you didn't actually want it is annoying. It's just that, in the context of what Ruby CAN look like, Rails isn't that arcane. For example, entirely for fun (it was a lot like a game - I couldn't stop seeing how far I could push it), I gradually built up a small library (less than 100 lines of code) that eventually yet radically transformed Ruby into what looked like a badly designed yet different (functional) language. Functions could be conveniently composed, partially applied, juxtaposed, etc by monkey-patching the symbol class with overloaded operators. I also had fun getting all this working for instance method calls so they could be treated the same way (few caveats with that though). Not to say that this is a production-worthy effort, it's simply not. It's just the experience that has ultimately taught me the extent of Ruby's (perhaps dangerous) power and that Rails doesn't actually call upon that much of it in the grand scheme of things. Truly knowing Ruby for Ruby and what it's features can really do, you only need to look at the so-called magic that Rails demos to understand intuitively how it does what it does.

sanderjd 11y ago

I think there's a subtle difference between what your parent said and what you're saying: they suggested that they know what's going on at every level, and you merely claim that you can figure out what's going on, if need be. (A charitable reading would be that they meant the same thing though.) I think we should all aspire to this level of having enough of a mental model for all the layers underneath us that we can go dig into them when needed. But it takes a lot of effort to get to the point you're at, so it's a pretty big ask. (Also, most of us probably can't go back to a university to learn the EE side, and it's not easy to self-learn it.) Having said all that, for Rails specifically, it's pretty easy to do exactly what you did and just open up Rails and other library code. It's almost entirely simple method definitions, and the parts that aren't can be understood if you go read about how `define_method`, `method_missing`, and `const_get` work. The "Rails is magic" meme seems to either scare people off from reading the code, or give people permission to be lazy about it.

evilduck 11y ago
Especially with pry existing now, the "Rails is magic" meme is tired and incorrect. Install pry, pry-rails. Something weird occurs? binding.pry, `show-method` or `show-source` and it dumps you to the exact line and filepath of the method, be it the original or a monkeypatched method (use -a to show them). Keep digging like that and you'll eventually hit the C implementation code. [18] pry(String):1> show-method length From: string.c (C Method): Owner: String Visibility: public Number of lines: 5 VALUE rb_str_length(VALUE str) { return LONG2NUM(str_strlen(str, NULL)); }
- rudolf0 11y ago
  I wish other REPLs were like this. IPython does it too, but not sure others can.
jwdunne 11y ago
Your last point really stood out to me. Reading through the commentary, it's difficult to see what is so magical about Rails after spending a lot of time using and especially abusing vanilla Ruby. Sure, I can concede that code that tries to do too much for you to the point where you didn't actually want it is annoying. It's just that, in the context of what Ruby CAN look like, Rails isn't that arcane. For example, entirely for fun (it was a lot like a game - I couldn't stop seeing how far I could push it), I gradually built up a small library (less than 100 lines of code) that eventually yet radically transformed Ruby into what looked like a badly designed yet different (functional) language. Functions could be conveniently composed, partially applied, juxtaposed, etc by monkey-patching the symbol class with overloaded operators. I also had fun getting all this working for instance method calls so they could be treated the same way (few caveats with that though). Not to say that this is a production-worthy effort, it's simply not. It's just the experience that has ultimately taught me the extent of Ruby's (perhaps dangerous) power and that Rails doesn't actually call upon that much of it in the grand scheme of things. Truly knowing Ruby for Ruby and what it's features can really do, you only need to look at the so-called magic that Rails demos to understand intuitively how it does what it does.