6 ms·

DHH says that explicit code favors novices and those with 'fresh eyes' on a problem while burdening experienced veteran programmers with bloat of boilerplate to

DHH says that explicit code favors novices and those with 'fresh eyes' on a problem while burdening experienced veteran programmers with bloat of boilerplate to read and to write. I may as well come with fresh eyes for any code I wrote over a year ago. I'm reading _my own code_ with an eye to figure out how it was put together. I should be courteous to my future self and to anyone else who wants to read my code. I pick up a new framework every year or two. I've been a full time software professional for over 16 years and I'm picking up new tools all the time. I prefer tools that tell me things explicitly so that I don't have the steep learning cliff of grokking the entire system in order to be able to work with one little part. And isn't this hypocritical? So many people (probably DHH too?) gush about how easy Rails is to get started with, but here DHH argues that it's so much butter for the veteran who knows what all the implied magic is. Doesn't all that implied magic also leave the beginner kinda helpless? There's so much Rails tutorial with the attitude "here, do this, trust me, it'll work". And I've found that trust to be misplaced. The underlying implied design isn't actually what I wanted, and it's really hard to get it to do what I want because the convention is so baked in. On the other hand, Go is a bit tediously boilerplate heavy. I'm still looking for the right balance.

camus2 9y ago
> On the other hand, Go is a bit tediously boilerplate heavy Go is a half baked DSL gone too far. Just like PHP, in 15 years, people will regret that the language wasn't carefully crafted despite its good "ideas", when developers will have to maintain million of lines go projects in production.
jbeja 9y ago
> I'm still looking for the right balance. You see this is only a problem you face. Instead looking for the perfect language (which doesn't exists) why don't you build it yourself?
tps5 9y ago
This seems right to me. the analogy I'd use is driving a car versus sitting in a passenger seat of a car. When I'm a passenger, I never remember the route we took. I retain almost no information about lefts and rights and landmarks. But if I'm driving, I really only have to drive to a place once to remember the way.
- adangert 9y ago
  It seems like automation and magic keeps on eating away at the driving experience, most cars are sold with automatic shifting, power steering, and a host of other features that most users are blissfully unaware of, the final outcome being self driving vehicles.
  - majewsky 9y ago
    Not sure if insightful or just taking the metaphor too far.
mercer 9y ago
> And isn't this hypocritical? So many people (probably DHH too?) gush about how easy Rails is to get started with, but here DHH argues that it's so much butter for the veteran who knows what all the implied magic is. Doesn't all that implied magic also leave the beginner kinda helpless? There's so much Rails tutorial with the attitude "here, do this, trust me, it'll work". And I've found that trust to be misplaced. The underlying implied design isn't actually what I wanted, and it's really hard to get it to do what I want because the convention is so baked in. As someone who got 'started' (to an extent) with Rails, I both agree and disagree with this paragraph. The main benefit of Rails, for me, was that once I dove in and try to understand how things worked, I learned a tremendous amount. Contrast that with my situation now, years later, where I'm piecing together 'best practices' for React/Electron/Cordova apps from various articles and tutorials, and I can conclude Rails really helped me along. On the other hand I do agree that the tutorials that you mention weren't much help, if not downright harmful in my journey. All that said, I currently lean towards the side of explicitness for actual work, and Rails goes a bit too far for my tastes. But then I'm bit of a control freak.
galacticpony 9y ago
I was interested to hear the argument up until "Ruby on Rails" showed up. If "Ruby on Rails" does what you need, that's great, but then I'd say you're barely programming anymore, just like writing HTML/CSS barely is programming. If we just go down another level (where you would implement something like Ruby on Rails), the same question appears. Do we favor explicit logic over implicit relations? At that level, I'd say the rule of thumb that "explicit is better than implicit" pays off, because it's often not that much more code, and a lot of code builds on top.
- savageco 9y ago
  Personally, I think it's the keyboards fault. No one is being explicit enough unless they are using one of these https://imgur.com/a/icKnR#pCbeucK https://imgur.com/a/icKnR#pCbeucK
jmileham 9y ago
I definitely don't see it as hypocritical. Humanely designed systems are thoughtful in where they deploy implicitness. Implicitness can cut down on boilerplate for experts while simultaneously cutting down on confusing minutiae for newcomers. On baked-in conventions, the implied design of a thoughtfully designed framework likely has wisdom that you shouldn't too quickly dismiss, and should at least fully wrap your brain around (along with the complementary design decisions in the rest of the framework) before diverging. The most baked-in assumptions in a well-designed system are the ones that exist for the strongest reasons.
cormacrelf 9y ago
I find myself wanting languages and frameworks that let me write the magic myself. Magic is about solving big sets of similar problems in really compact/effortless ways. Rails tries to solve a really huge class of similar problems, i.e. web development, and starts pushing back on what you can achieve without ditching the framework entirely. I don't mean that in the sense that you stop being able to write regular Ruby (which can do anything), I mean that it's smooth sailing until you want to add your own magic in 'userspace'. Take ASP.NET, for example using method attributes for authorisation: [Authorize(Policy = "AdminOnly")] public IActionResult Method(int projectId) { return Ok(); } It's great and magical if you want to lock down a controller or a method to admins only, or people whose standard user object has an Age field > 18 or something like that. But if you want per-project permissions, with a user->permissions<-project relation? Sorry, you can't easily pass invocation parameters to your AuthorizationPolicy classes because C# Attributes don't support that. You could try having a naming scheme for your url fragments and get the project ID from there, but this means you need to have project parameters in every route, which is often redundant and would need to be checked on any object in a POST request. Any way you go, you have to write code inside your method to get the job done. You have to break out of the magic, and let go of the automatic 403 responses to do anything beyond the simplest case. To actually build this without a clumsy if/else and manually returning 403 with JSON (to describe the error) in every controller method, it was necessary to create an exception and a custom exception handler middleware, and in the handler, produce a non-standard HTTP code and catch it again in a second middleware after the framework would otherwise gobble up 403s and return HTML instead of JSON. Exceptions inside controller methods are a perfectly adequate model for authorisation failures, but because the framework expects you to hook into their middleware for it, they made it very difficult to do it any other way. Ok, that was a lengthy example. But it illustrates what I mean by wanting to write my own magic. Frameworks shouldn't cripple userspace magic by design.
- taeric 9y ago
  If you want to write your own magic in code, you likely want a lisp.
  - cormacrelf 9y ago
nolemurs 9y ago
I totally agree with everything you've said. I came here to post more or less this. > On the other hand, Go is a bit tediously boilerplate heavy. I'm still looking for the right balance. I've been working with Django (in Python) for a while now, and find it strikes a really nice balance. Almost nothing happens by magic, but there's also surprisingly little boilerplate. It used to be a little rough, but it's gotten a lot better in recent years especially (I think likely due in no small part to influence/competition from rails), so if you haven't checked it out recently, you should!
brightball 9y ago
Elixir brings that balance to the force. :)
_asummers 9y ago
Elixir might be up your alley. The language prefers explicit, and gives you macros to make the explicit implicit when it makes sense (e.g. the ORM). Functions are preferred, and you'll get flak for macro laden code, but the best macros are the ones you don't even know are there (like the "if" statement and "def" in Elixir.Kernel).
FatalBaboon 9y ago
Try Common Lisp, you get the basic blocks like a routing library, some templating and a db connector. Then you add up macros as you need them. Power without magic.
Existenceblinks 9y ago
In the middle to late Rails period, there are some patterns that are implicit, for example, DCI, Presenter and Form object. In my view, Rails is not Rails anymore; it's going beyond buffet (as mention in his talk: https://www.youtube.com/watch?v=Cx6aGMC6MjU https://www.youtube.com/watch?v=Cx6aGMC6MjU). It's like it provides LEGO building blocks and people use them with their own plasticine shapes. Data flow through in weird manner. IIRC, there is a place where Rails copies all in-controller's instance variables to in-view's instance variables, and tell people to pretend that they are the same objects. Ruby itself is strange (in implicit way) enough on how things are defined and called. Maybe it's just me, I don't even understand its OOP although I came from C++ background.
ZombieOutlaw 9y ago
Give Elixir a go.
coldtea 9y ago
>DHH says that explicit code favors novices and those with 'fresh eyes' on a problem while burdening experienced veteran programmers with bloat of boilerplate to read and to write. I may as well come with fresh eyes for any code I wrote over a year ago. That's irrelevant to his argument though, as he doesn't speak of coming with fresh eyes to the code, but coming with fresh eyes to the framework/language. Even if you have forgotten why you wrote some particular code, you'd still remember the ways of the framework/language from other code you've since written with them, or generally because they're more general and fundamental than your particular code (the same way you'd remember the language's syntax, etc, but might have forgotten why you wrote some algorithm a particular way).
wtetzner 9y ago
> On the other hand, Go is a bit tediously boilerplate heavy. I'm still looking for the right balance. I think the trick is to come up with the right abstractions. I think we need to strive for abstractions that are relatively easy to grok (at least as a user of the abstractions), such that it doesn't feel like magic as much as it feels like a well designed language for the problem domain. Of course, that's easier said than done. But most things worth doing are hard :)
Someone 9y ago
So, maybe, one should pick a language plus tooling that allows one to round-trip between various variants on the explicit-implicit dimension. Various strongly-typed languages have something like that, with tooling that can add and remove explicit types from variable declarations and generic method calls, make calls of extension methods explicit, add explicit arguments for functions taking default values, etc. That can give you longer code when you don't know the language and/or the program at hand well, and terse code when you do.

camus2 9y ago

> On the other hand, Go is a bit tediously boilerplate heavy Go is a half baked DSL gone too far. Just like PHP, in 15 years, people will regret that the language wasn't carefully crafted despite its good "ideas", when developers will have to maintain million of lines go projects in production.

jbeja 9y ago

> I'm still looking for the right balance. You see this is only a problem you face. Instead looking for the perfect language (which doesn't exists) why don't you build it yourself?

tps5 9y ago

This seems right to me. the analogy I'd use is driving a car versus sitting in a passenger seat of a car. When I'm a passenger, I never remember the route we took. I retain almost no information about lefts and rights and landmarks. But if I'm driving, I really only have to drive to a place once to remember the way.

adangert 9y ago
It seems like automation and magic keeps on eating away at the driving experience, most cars are sold with automatic shifting, power steering, and a host of other features that most users are blissfully unaware of, the final outcome being self driving vehicles.
- majewsky 9y ago
  Not sure if insightful or just taking the metaphor too far.

mercer 9y ago

> And isn't this hypocritical? So many people (probably DHH too?) gush about how easy Rails is to get started with, but here DHH argues that it's so much butter for the veteran who knows what all the implied magic is. Doesn't all that implied magic also leave the beginner kinda helpless? There's so much Rails tutorial with the attitude "here, do this, trust me, it'll work". And I've found that trust to be misplaced. The underlying implied design isn't actually what I wanted, and it's really hard to get it to do what I want because the convention is so baked in. As someone who got 'started' (to an extent) with Rails, I both agree and disagree with this paragraph. The main benefit of Rails, for me, was that once I dove in and try to understand how things worked, I learned a tremendous amount. Contrast that with my situation now, years later, where I'm piecing together 'best practices' for React/Electron/Cordova apps from various articles and tutorials, and I can conclude Rails really helped me along. On the other hand I do agree that the tutorials that you mention weren't much help, if not downright harmful in my journey. All that said, I currently lean towards the side of explicitness for actual work, and Rails goes a bit too far for my tastes. But then I'm bit of a control freak.

galacticpony 9y ago

I was interested to hear the argument up until "Ruby on Rails" showed up. If "Ruby on Rails" does what you need, that's great, but then I'd say you're barely programming anymore, just like writing HTML/CSS barely is programming. If we just go down another level (where you would implement something like Ruby on Rails), the same question appears. Do we favor explicit logic over implicit relations? At that level, I'd say the rule of thumb that "explicit is better than implicit" pays off, because it's often not that much more code, and a lot of code builds on top.

savageco 9y ago
Personally, I think it's the keyboards fault. No one is being explicit enough unless they are using one of these https://imgur.com/a/icKnR#pCbeucK https://imgur.com/a/icKnR#pCbeucK

jmileham 9y ago

I definitely don't see it as hypocritical. Humanely designed systems are thoughtful in where they deploy implicitness. Implicitness can cut down on boilerplate for experts while simultaneously cutting down on confusing minutiae for newcomers. On baked-in conventions, the implied design of a thoughtfully designed framework likely has wisdom that you shouldn't too quickly dismiss, and should at least fully wrap your brain around (along with the complementary design decisions in the rest of the framework) before diverging. The most baked-in assumptions in a well-designed system are the ones that exist for the strongest reasons.

cormacrelf 9y ago

I find myself wanting languages and frameworks that let me write the magic myself. Magic is about solving big sets of similar problems in really compact/effortless ways. Rails tries to solve a really huge class of similar problems, i.e. web development, and starts pushing back on what you can achieve without ditching the framework entirely. I don't mean that in the sense that you stop being able to write regular Ruby (which can do anything), I mean that it's smooth sailing until you want to add your own magic in 'userspace'. Take ASP.NET, for example using method attributes for authorisation: [Authorize(Policy = "AdminOnly")] public IActionResult Method(int projectId) { return Ok(); } It's great and magical if you want to lock down a controller or a method to admins only, or people whose standard user object has an Age field > 18 or something like that. But if you want per-project permissions, with a user->permissions<-project relation? Sorry, you can't easily pass invocation parameters to your AuthorizationPolicy classes because C# Attributes don't support that. You could try having a naming scheme for your url fragments and get the project ID from there, but this means you need to have project parameters in every route, which is often redundant and would need to be checked on any object in a POST request. Any way you go, you have to write code inside your method to get the job done. You have to break out of the magic, and let go of the automatic 403 responses to do anything beyond the simplest case. To actually build this without a clumsy if/else and manually returning 403 with JSON (to describe the error) in every controller method, it was necessary to create an exception and a custom exception handler middleware, and in the handler, produce a non-standard HTTP code and catch it again in a second middleware after the framework would otherwise gobble up 403s and return HTML instead of JSON. Exceptions inside controller methods are a perfectly adequate model for authorisation failures, but because the framework expects you to hook into their middleware for it, they made it very difficult to do it any other way. Ok, that was a lengthy example. But it illustrates what I mean by wanting to write my own magic. Frameworks shouldn't cripple userspace magic by design.

taeric 9y ago
If you want to write your own magic in code, you likely want a lisp.
- cormacrelf 9y ago

nolemurs 9y ago

I totally agree with everything you've said. I came here to post more or less this. > On the other hand, Go is a bit tediously boilerplate heavy. I'm still looking for the right balance. I've been working with Django (in Python) for a while now, and find it strikes a really nice balance. Almost nothing happens by magic, but there's also surprisingly little boilerplate. It used to be a little rough, but it's gotten a lot better in recent years especially (I think likely due in no small part to influence/competition from rails), so if you haven't checked it out recently, you should!

brightball 9y ago

Elixir brings that balance to the force. :)

_asummers 9y ago

Elixir might be up your alley. The language prefers explicit, and gives you macros to make the explicit implicit when it makes sense (e.g. the ORM). Functions are preferred, and you'll get flak for macro laden code, but the best macros are the ones you don't even know are there (like the "if" statement and "def" in Elixir.Kernel).

FatalBaboon 9y ago

Try Common Lisp, you get the basic blocks like a routing library, some templating and a db connector. Then you add up macros as you need them. Power without magic.

Existenceblinks 9y ago

In the middle to late Rails period, there are some patterns that are implicit, for example, DCI, Presenter and Form object. In my view, Rails is not Rails anymore; it's going beyond buffet (as mention in his talk: https://www.youtube.com/watch?v=Cx6aGMC6MjU https://www.youtube.com/watch?v=Cx6aGMC6MjU). It's like it provides LEGO building blocks and people use them with their own plasticine shapes. Data flow through in weird manner. IIRC, there is a place where Rails copies all in-controller's instance variables to in-view's instance variables, and tell people to pretend that they are the same objects. Ruby itself is strange (in implicit way) enough on how things are defined and called. Maybe it's just me, I don't even understand its OOP although I came from C++ background.

ZombieOutlaw 9y ago

Give Elixir a go.

coldtea 9y ago

>DHH says that explicit code favors novices and those with 'fresh eyes' on a problem while burdening experienced veteran programmers with bloat of boilerplate to read and to write. I may as well come with fresh eyes for any code I wrote over a year ago. That's irrelevant to his argument though, as he doesn't speak of coming with fresh eyes to the code, but coming with fresh eyes to the framework/language. Even if you have forgotten why you wrote some particular code, you'd still remember the ways of the framework/language from other code you've since written with them, or generally because they're more general and fundamental than your particular code (the same way you'd remember the language's syntax, etc, but might have forgotten why you wrote some algorithm a particular way).

wtetzner 9y ago

> On the other hand, Go is a bit tediously boilerplate heavy. I'm still looking for the right balance. I think the trick is to come up with the right abstractions. I think we need to strive for abstractions that are relatively easy to grok (at least as a user of the abstractions), such that it doesn't feel like magic as much as it feels like a well designed language for the problem domain. Of course, that's easier said than done. But most things worth doing are hard :)

Someone 9y ago

So, maybe, one should pick a language plus tooling that allows one to round-trip between various variants on the explicit-implicit dimension. Various strongly-typed languages have something like that, with tooling that can add and remove explicit types from variable declarations and generic method calls, make calls of extension methods explicit, add explicit arguments for functions taking default values, etc. That can give you longer code when you don't know the language and/or the program at hand well, and terse code when you do.