Hacker News Reader

Comment by brown9-2 | Hacker News Reader

Couldn't this "pluggable architecture" be written in any language?

This is more of a rant against "developers" with "really bad habits" than it is against the language.

When I write a simple function in Scheme and find myself wondering whether I might later want to swap in a different algorithm at runtime, I don't start making a pluggable architecture right then. Because I don't need to. The function I wrote can simply drop into whatever pluggable architecture I write later.

In Java, if I think I might need a pluggable architecture later, I'm tempted to go ahead and make it from the start, since my object model will need to support it.

Yes, this. I think people are missing, or not remembering, that Java makes you code defensively where other languages don't, and the appeal of falling into these patterns just to make sure all bases are covered without having to think too hard.

Anonymous subroutines serve a similar purpose in Perl, and are awesome for it.

It's a rant about Java culture. Culture is an important aspect of any language.

The Sapir-Whorf Hyptothesis applies to software languages as well as human languages...

I'm not so sure about this, it recently came up in discussion with a former teacher of fine, here's what I said then:

To the linguistics question I just had a discussion about this with my boss (who's a linguist by training, currently on leave from his PH.d which has something to do with Greek, he's also been programming a lot longer than I have). One of the points he had was that the Sapir–Whorf hypothesis doesn't just say speaking German affects how you think in German, it affects how one thinks as a whole. To that we're both a bit skeptical, being a programmer probably affects ones cognition (or ones cognition causes one to be predisposed to becoming a programmer, whichever!), but the specific language one uses... probably not. On the other hand, within programming it's clear that different languages (or at least their communities) have different personalities. A good example of this is Python and Ruby. Semantically these languages are remarkably similar (in the context of all programming languages), however their communities have seized upon the small differences and as a result the cultures (accepted best practices and such) are fairly different. Another good example of this is what are known as "design patterns", which were originally supposed to be a language-neutral way of expressing how code could be architected, however in practice some of these really make no sense with certain languages, because e.g. the language has builtin-features which obviate the need for such things.

What about, say, imperative vs. functional languages?

I didn't cover that because the person I was speaking with was not a programmer, however I think what I said still holds up: within the scope of programming haskell vs PHP is pretty huge, but I don't think they're particularly different cognitive modes in the larger scope.

not to mention, declarative

The current common stance of linguists is that the SWH doesn't hold for human languages. I personally disagree, but I haven't done the formal experiments to confirm my informal belief.

That was true 20 years ago, today not so much. The strongest of the original Sapir-Whorf claims don't hold up, but the weaker ones do. See Lera Boroditsky's work in particular. She's been publishing on this topic for at least 10 years. Most of the good stuff requires a library (or paying), but heres an edge article from a year and a half ago:

http://www.edge.org/3rd_culture/boroditsky09/boroditsky09_in...

Boroditsky, L. (2003). Linguistic relativity. In L. Nadel (Ed.), Encyclopedia of cognitive science (pp. 917–922). London, England: Macmillan.

Boroditsky, L. (2001). Does language shape thought? English and Mandarin speakers' conceptions of time. Cognitive Psychology, 43(1), 1–22.

Thanks guys. Funny that I'm still learning about it in college, then...

Yes. Maybe even more so.

I disagree to some extent. Sure, some people would overarchitect because culture says so, but I think the more important thing is that Java doesn't give the developer "other choices". If you, for example, make the factorial function in Python, you wouldn't have to worry about integer overflow, because Python does that for you. Therefore, a Python equivalent would be (in theory) easier to understand. The fact that you have to wrap a class around the function is also an example of "limitations".

I disagree to some extent. Sure, some people would overarchitect because culture says so, but I think the more important thing is that Java doesn't give the developer "other choices"

Java doesn't force you to over-architect solutions. Wrapping everything in classes doesn't make your code over-architected by definition.

For Java, the culture is heavily towards writing "solutions" like the overengineered mess in TFA. For python, it's different. Same for Ruby or PHP or .NET or...

Note that for none of those languages are you "forced" to act like the culture says you probably will. Nothing in Ruby forces you to unit-test, for instance, but the culture leans so heavily that way that it's more shocking when you find a team not doing it.

"class-oriented" languages (such as java) attract such people.

OOP seems to be "difficult", so there are lots of "tutorials" around that "teach" OOP by introducing and combining all those brainless constructs, without teaching common sense. what you get is code monkeys who believe that this is decent source code.

every code base should have at least one person dedicated to simplifying it and questioning every design decision, so all this "just in case" abstraction gets the knife.

I think the problem is that OOP is just taught as a way to organize code.

Pretty much everything in our ostensibly OO system could be static methods and it would work just fine. Objects rarely have instance variables, or if they do they are just used to set up a method call. Object lifetimes are measured in single-digit lines of code, and messaging between them is extremely rare.

But that's what people have been taught.

I think you may be generalizing from a particular language culture to all OOP. This doesn't apply everywhere.

I'm talking about the kind of generic business app built in blub by a team of chair moisteners who don't know anything outside of the one language the project is written in.

It could be Java (of course), C# (just about as likely), or VB (when they get the idea to use objects), or Python (yes, I've seen it).

Neither Python nor Ruby encourages this behaviour. Classes are clean and mean.

OOP is not difficult. I learned OOP with Smalltalk and then went on to program with Actor on Windows 3 and lived happy until I decided to learn C++. I closed the book for 8 years because of what I saw: a parody of the simplicity and elegance of C. C++ could, as well, be a work of satire.

OOP is only "difficult" if you try to learn it using a language that makes it difficult. Sadly, Java is one such language.

Sure, I've seen it in C# code. But I can tell that the people writing it were coming from an enterprisey Java background (because they wrote 400KLoC without using any part of C# that isn't also in Java).

Perhaps your anecdote is a bit telling then.

Maybe this "pattern" is less indicative of someone who comes from a "Java" background than it is someone who comes from an "enterprisey" background.

It just so happens that the overlap between the two is huge.

I hate to always be the defender of Java but it irks me to see articles that claim to lambast Java but really are about this so-called "culture" that has popped up.

Um, not really. Dynamic languages have duck typing (look it up on wikipedia); they get used to writing for the now and letting the what-ifs wait, as in some cases, changes can be accomodated with little tear-down of existing code.

That's fair, but I think many of us are used to seeing this come from the Java world so the specific example he gives (in Java) is apt.

Reply on news.ycombinator.com