Hacker News Reader

Comment by nilsb | Hacker News Reader

Is it just me or is understanding those examples virtually impossible if you're not intimately familiar with that particular framework? Then again... I guess that's the author's point.

View on HN

Why is that magic always hated when it comes to Java, but praised when Django or Ruby on Rails do it?

I think most senior or experienced Python developers tend to steer clear of Django.

It's just that you don't hear about it because it's mostly junior / less experienced developers writing about Django online.

edit: having said that, I wish we would be more skeptical of magic frameworks like Django in the Python community at least. Things like 'get_object_or_404'[1] should be burned to the ground.

[1] https://docs.djangoproject.com/en/4.1/topics/http/shortcuts/...

Sweeping generalisation or what?

> Things like 'get_object_or_404'[1] should be burned to the ground.

Why? A shortcut like that is useful all the time when writing URL handlers (views in Django).

What does the object have to do with http status codes? It completely entangles the HTTP layer with the database model.

So we should also get rid of `.orElseThrow()` (by default a `NoSuchElementException`)?

If it was .orElseReturn404 then yeah. My point is HTTP codes have no place outside of HTTP endpoints

Maybe it’s different flavors of magic. One is intuitive, one is inpenetrable without being an expert or early on in the project lifecycle. Also java projects tend to grow way larger.

Java projects growing way larger are likely just survivorship bias — python apps of similar sizes would just crumble, while java’s static typing gives enough stability against that.

I wasn’t disputing that java can grow larger codebases for various reasons: static typing and so on. What I am saying is that these systems do become impenetrable after a while and that magic that once is very welcome becomes the death arrow of obfuscation because while well meaning and useful at first, combined with a bunch of design patters and framworks it becomes a hot mess nobody wants to maintain.

I dunno, this sort of thing seems intuitive to me:

    @POST
    @Path("/widgets/{widgetId}")
    public Widget getWidgetById(@PathParam("widgetId") Long widgetId) {
        // ...
    }

...where the sort of `method_missing` magic that Rails uses is _far_ less intuitive. Since when can I just call a method that doesn't exist, and expect the language to contrive what it thinks is a sensible definition on the fly?

> Since when can I just call a method that doesn't exist, and expect the language to contrive what it thinks is a sensible definition on the fly?

Since Smalltalk-76 introduced[1] doesNotUnderstand: ?

I understand you didn’t really ask a question, but then I didn’t really give an answer (though the article’s discussion is fairly interesting). I guess my point is that there’s a distinction between a facility one finds unintuitive and a facility that’s newfangled and (therefore) outrageous. Even when the first category probably includes a good number of outright stupid ones.

[1] http://worrydream.com/refs/Ingalls%20-%20The%20Evolution%20o..., §5.11

> Also java projects tend to grow way larger reply

It's the latter. Java is more likely to be used by a large companies. Django is more likely to be used by startups and SMB's (as well as by students and side projects).

Forums like HN and Reddit are disproportionately populated by students, and younger developers who are typically more interested in discussing tech for their personal projects than their day jobs.

If your mindset is oriented around tech that is optimized for one-man projects or tiny teams, then you are likely to reject tech that is optimized for large teams in large companies.

> Forums like HN and Reddit are disproportionately populated by students, and younger developers

Are you sure? Are there any demographics stats on that?

Yeah. It's the issue with the framework not the language.

The examples use CDI (dependency injection through annotations) and yes, these annotations become hardwired to the business objects... Java has some kind of traits now through interfaces so it's not much of a problem today.

> Java has some kind of traits now through interfaces so it's not much of a problem today.

Well that's the article's premise, right? Opening sentence:

    Java is good by modern standards, from a technical perspective

Later on:

    Java’s culture eschews common sense approaches

> so it's not much of a problem today.

Every Java codebase I've worked on in my career has had plenty of this crap in it. The culture has settled on doing it this way.

What non-java codebases you worked on (of similar magnitude) that didn't have plenty of crap in it?

Java encourages doing things like they were done 15 years ago because rewriting reams of low-value boilerplate with delicate architectural impacts is neither fun nor (at first sight) valuable.

Typical immature enterprise organizations tend to extend the system with low-risk new features instead of refactoring and remaking old stuff.

Reply on news.ycombinator.com