Hacker News Reader

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!

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).

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.

Have you taken a look at what can be done in functional languages (perhaps F#) ? I'm just starting to get into them [0] and it's been really fascinating.

Jet.com has an interesting post on why they chose F# for similar reasons [1]

[0] I'm working through the How to Design Programs book from Matthias Felleisen which I highly recommend despite its rough edges http://www.ccs.neu.edu/home/matthias/HtDP2e/

[1] https://tech.jet.com/blog/2015/03-22-on-how-jet-chose/

Yeah, way into FP. I've used Haskell, Clojure, and hopefully some Erlang or Elixir soon, and I pretty much use functional style wherever else I can, including C# and JavaScript.

F# seems to be getting more attention, but I mostly just see people struggling to get EF migrations going, and it seems general ecosystem support is still shoddy (compiler bugs on .NET core 1.1? 3rd party VSCode support? official VS plugins crash all the time?). I have to use C# for work, so it's just not stable enough despite F# itself being around for ages :)

THat's not my experience with F#, I've used it with EF and .net core 1.1, and VS. I've been extremely happy and had little to none of the issues you listed.

I pulled it out of the drawer again a few days ago. It was lovely, I wrote a monad for asynchronous HTTP results (basically the async monad + an Either monad + some methods to produce some HttpErrors) and encoded a bunch of API functionality (including auth filters) with early returns. The only pain was not having anonymous dynamic objects in C# new { syntax = "syntax" } and using Dapper.

I'd definitely like to give it a go for some bigger projects.

If you want to write your own magic in code, you likely want a lisp.

I think you may have diagnosed me correctly. I have been enjoying Clojure. But weirdly enough, the more powerful a type system you have, the more you can do lisp-like magic. Think Rust's traits that can have default implementations, which basically gives you what multiple inheritance is supposed to provide. And Into<T> that essentially sprinkles opt-in dynamic typing through your codebase. There are so many bits of magic you can express with powerful static types, and I don't really mind writing a generic implementation once.

Strong types give me the feeling of expressing some sort of universal truth in a math way. I am actually quite bad at that.

Lisp let's me understand how procedures go together to build things. In particular, it helps get to a dual phase of programs. Macros aren't my program running. Rather, they are a program that makes the program I want to run. It just so happens that being able to cycle between those phases is very useful.

I can make no claims that one is superior.

Edit: s/string/strong/.

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.

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.

Not sure if insightful or just taking the metaphor too far.

> 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.

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). 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.

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.

>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).

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.

> 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 :)

Elixir brings that balance to the force. :)

> 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.

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.

Give Elixir a go.

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.

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