When I started coding at age 12, it was on TI calculators. The code was in Zilog Z80 ASM, and TI's flavor of BASIC (TI-BASIC). I suspect many of the hackers on this site of used TI-BASIC, and possibly Z80 ASM.

This was all of the experience in coding I had for the next 4 years. I became extremely good at TI-BASIC and ASM. But in High School I started fooling around with Python and the world of Object Oriented programming bewildered me.

In TI-BASIC you get 27 float variables, 6 lists of floats, all limited to 999 elements, 10 strings, and 6 matrices of floats. That is all the data one gets. Very quickly one becomes a wizard of string manipulations (because strings were the only datatype without a default memory cap; they could be as long as your RAM could hold) and whatnot.

Whenever I moved to Python, I found myself following the same paradigm. I didn't make a single Python class until I was in college. I would use tuples and lists and just organize my data that way.

After my collegiate conversion to OOP (and subsequently writing heavily OO Python), I later found out that it is somewhat encouraged to use the built in datatypes over custom classes for performance reasons.

I was accidentally acting Roman without realizing it!

I find tuples and lists incredibly flexible, and I often get dirty looks from experienced devs in a particular language for not using their preferred methodology. For example, I end up creating hashes instead of new classes in Perl. Tuples in Python. I like to think it's a convenient abstraction, because I can use them in nearly any language - even C, sort of, with structs.

As long as your static methods aren't matched by a similar amount of static globals (er, I mean class statics), go for your life.

There is a wonderful writeup by PJ Eby about a Python codebase (Chandler) written by Java developers: http://dirtsimple.org/2004/12/python-is-not-java.html

Of note is that Java instincts are a bad thing for Python. Similar principles apply to other language combinations, and even services (eg SOAP vs REST) in addition to data as PJ wrote (eg XML vs JSON).

Thanks for that link. This quote is especially resounding:

Ask, "how does Python already solve my problem?" and "What Python language feature most resembles my problem?"

I have just come back to Java (for the sake of android) after a long time spent in Clojure-influenced (functional, immutable, favor maps and functions over objects) Javascript. I've noticed the exact same things in my style: static methods, public fields. Another wrinkle is that I tend to leave my generics untyped---and given that I use the Collections framework so heavily, I'm basically writing dynamically-typed Java.

Time will tell if this is horrible or genius. I suspect it will be neither since I'm just writing a toy app for now and probably won't run across any problems of a huge-incomprehensible-codebase nature.

Thank you for this post, I've felt like the OO police have been closing in on me and will burst through the door at any moment to force getters and setters on me.

I find that programming languages are like real languages in that the more different they are the easier time I have working in each without confusing one for the other.

It is easier for me to write Java/C#/C++ code and then Python code and adhere to the conventions of each than it is for me to write Go code and then switch to Java/C#/C++ code. This is true for the larger architectural differences as well as for more minor syntax-related differences (eg. if I've been writing a lot of Go and then I switch to maintaining some C#, I'll often leave semicolons off statements in the C# code until the compiler complains about it).

What? I don't get the analogy.

From the phrase "When in Rome, do as the Romans do."

The author is saying that when he is "in Rome" he finds himself not doing what the Romans do, but rather doing what the Parisians do or what the Berliners do, since he has spent so much time in his metaphorical Paris and Berlin.

He appears to be referring to the phrase, ""When in Rome, do as the Romans do."

Same here... Except that I've been doing that since years and years and years. Way before "functional Java" came out. I learned about basically every single "trick" TFA describes (and more) on Usenet, in comp.lang.java.programmer, back in the days.

The "abstract" keyword is forbidden (I know a lot of OO "experts" that are going to explain how bad this is). No public constructor (they do break encapsulation and hence it's a gigantic no-no). Every single class is final.

Liberal use, everywhere, of multiple (interface) inheritance.

@NotNull everywhere. Really. I hardly know what a NullPointerException is since 5 years or so.

The final keyword is used nearly everywhere.

Most classes do throw a Runtime exception if you try to call hashcode() or equals() on an object (because in anything but the simplest case, where there's only one level of inheritance, the hashcode() and equals() contract cannot be guaranteed -- This fact was explained in "Effective Java" by Joshua Bloch back in the days and is not open to discussion).

Basically I'm doing "OO over immutable objects" and it's much easier to reason about the state while programming this way.

The most laughable thing of them all is that years and years ago when you'd talk about that on comp.lang.java.programmer people like Jon Skeet (you know, the StackOverflow user with the biggest reputation of all StackOverflow) would call you crazy and explain why the "common" way was the one true way. These were the kind of people explaining how James Gosling was a god for not adding enums to Java and why Java applets were the best thing since sliced bread.

One IBM JVM engineer would regularly hand Jon Skeet's arse to him by the way.

And now... Oh the irony, Jon Skeet on StackOverflow is basically rewriting exactly what these precursors where telling on c.l.j.p. years and years ago.

So, slowly, people are starting to accept that it may not have been that great an idea to allow the addition of mutable, extendable objects in a hashmap.

Thankfully things are changing for the best, at last... : )

If you think it's hard to not be a roman in Java Rome today, you have zero idea what it was like to not be a roman in Java Rome during the Usenet days.

Since you apparently wanted to know why you're being downvoted, here's a reason: I cannot derive a meaningful point from this comment. You seem to be encouraging us to eschew programming languages in favor of "be[ing] really effective." Platitudes will never replace actual tools.

Also, you're saying all this in a rather obnoxious manner, talking about how you're "drunk instead of high" and what-have-you. Nobody wants to hear about how drunk or high anybody else is -- and if you don't feel like you can compose a decent comment in your current state of mind, you can't be too surprised if you go ahead anyway and end up downvoted.

If you need help, ask for it. People tend to respond pretty well to that.

But do it quickly, because I'm pretty sure you're going to get hell-banned for this. And for reasons that will be painfully obvious to you once you are sober.