jump to navigation

Java Makes Me Sad June 5, 2015

Posted by PythonGuy in Java, SQLAlchemy.
Tags: , ,
add a comment

Today, we were faced with an engineering challenge. The solution was obvious: Let’s add a table to relate these two concepts. It will solve all of our problems elegantly.

The backend developer balked. “It will take hours to write, hours more to test and debug!”

See, we decided that Java was cool and we’d write our backend services in Java. Now we are paying for it. Well, we paid for it before we even got out prototype working.

This made me really sad.

In SQLAlchemy, adding a table is extraordinarily simple. Just declare a new class, add in the members, and you’re done. Adding a relationship is super-easy as well. Just add an attribute name for the other class and set it equal to the results of the relationship() function. Using the relationships are super-duper-easy. Really, 10 lines of new code would be all that was required to get our feature working with a relationship table. In the API method, we’d need to change 1, maybe 2 lines of code to get it plugged in. Total work to production quality: Less than 10 minutes.

Morale of the Story: Development time is always the most expensive time. Minimize it.

Also: The JVM sucks. Just sayin’.

Maybe you don’t need objects after all January 16, 2011

Posted by PythonGuy in Advanced Python, Java.

My style of Python programming is so very different than the Java code I was forced to write to keep my job that I since quit to work at Deal-Digger.

I have a general rule of thumb: Avoid objects if you can, but don’t be too shy if it makes sense.

Case in point: Modules. Modules make very, very fine objects in and of themselves. A lot of the worlds problems can be solved with modules that simply don’t have objects. Python is so laid back when it comes to typing that you don’t need to be upfront about the type of the parameters you pass around at all. (See Duck Typing.)

If you don’t need to be specific about the types of objects, you probably don’t need to define any classes at all. Hence, Java, which is anal retentive about types, and requires you to write about 10 classes to get the 1 class you actually need.

Another issue you get to avoid altogether is inheritance. Trust me, inheritance is nice when you need it. It is painful if you don’t. It’s a cost, meaning you spend time upfront, so make sure you actually need what you’re spending your time on.

The style of programming I use rarely benefits from deep thought and magnificent design up front. I’ve found myself to be most productive in Python if I work like this:

  1. Choose a feature to implement.
  2. Find the shortest path to implement the feature, without thinking very much about other features.
  3. Do it. Then test, a lot.
  4. Rinse and repeat.

It surprises myself what I am capable of following this model. Try it, you might be surprised as well.

Python is Not a Stepping Stone to Lisp June 13, 2010

Posted by PythonGuy in Java, Lisp, perl, Python, Ruby.
add a comment

I’ve dabbled a bit in Lisp-land. I left frustrated and annoyed. Not with the language, per se, but moreso with the community and its support, or rather, the lack thereof. I’ve also taken up full-time residence for a number of years in C and C++ land. I’ve tinkered in quite a few language and today, I’m forced to write in Java. (Thanks, Java. My project is now a full two months late because your memory management sucks and I cannot do proper caching.)

Brian Carper is an ex-pat of the nation of Ruby now strangely finding residence in the nation of Clojure. He talks about why Ruby is a natural step towards Clojure, and unwittingly exposes Ruby’s fatal flaws, flaws which I find simply abhorrent. One day we’ll be reading about Brian Carper’s adventures in some other language, wherein he discovers, after all, that previous language X had it all wrong to begin with.

For reasons I cannot imagine, he hasn’t tried Python out, at least enough to find it satisfying all the weaknesses of all the languages he has tried before. Yes, super() is not, and bad Python sucks as bad as bad anything. Python isn’t a trivial language to master, although with no foreknowledge you can get pretty deep into Python without realizing it.

Anyway, perhaps this bit of arguing will help him see the error of his ways. I like to classify languages into two categories: great languages and terrible languages. There really is no middle ground.

Great languages are languages designed to solve a problem and that subsequently solve that problem. C went about trying to provide some kind of structure to assembler without getting too far away from assembler, and succeeded brilliantly. Lisp set out to prove that a language built on pure mathematics can solve the world’s problems and do it quickly and it succeeded wildly. Perl set out to show that “scripting” in a higher level language can actually make some problems really easy to solve.

Terrible languages set out to solve a problem and fall short. These are languages like Ruby and Java and pretty much everything out there except a few languages.

When you finally realize what makes a great language a terrible language, you have reached a certain level of understanding. It’s like waking up one morning and seeing, for the first time, that Lincoln probably had body odor!

So all languages are terrible. Even Python. Python sucks, a lot! I mean, I had to fight with the dang thing for hours because I happened to name a script “mymodule.py” in my bin path and it wasn’t picking up the right package path! We have a name for these things in the Python community (warts), and we show them off like trophies, waving them proudly and emphatically in front of programmers new and old.

It’s really odd seeing a language community proudly and boldly declare what their language is terrible at. It’s even more odd to see them do it with a smile.

What makes one language better than others is that it sucks less. When you compare the long list of Python’s failures with the long list of every other language out there’s failures, you’ll quickly see that Python isn’t too bad. In fact, it’s kind of nice.

We don’t have to weigh our benefits against out costs. We know that every language has some huge benefits.

What we do assert, however, is that our costs are much less than other language’s costs, and so you’ll end up with Python because we suck less.

In the end, all languages only provide one benefit: Helping you get your program correct.

Python Typing: Just the Right Amount March 22, 2008

Posted by PythonGuy in Java, Lisp, perl, Python.
1 comment so far

So, I’m reading some blog posts from who-knows-when. I closed the pages and it is lost to my memory, so sorry I can’t uncover it.

A few points seemed to bleed through, though:

1. Dynamic typing (that is, not specifying the type of the objects at the time of coding) is a good thing, since getting static typing (the opposite) correct is very hard. In fact, Haskell and other languages make a really, really good effort at it, almost get it right, but still don’t solve the problem of making the code easier to read, write, and maintain than dynamically typed languages. So, in the boxing match of static typing vs. dynamic typing, dynamic typing wins by forfeit.

2. Strict typing (that is, specifying the type of the object upon inspection) is a good thing, since loose typing (not knowing what type a thing is, even after looking at it very hard) is terrible. In this boxing match, the opponent is so ugly and so hard to deal with, that the audience boos him out of the ring before the match can start. Strict typing wins.

So, the ideal language will be dynamic and strict (python, lisp), not static or loose. (Although, if someone figures out the static typing thing without making life harder, there could be an upset. This is unlikely, since writing strict typing code that works is as hard as writing code.)

Some people nowadays are trying to bring in some form of static typing to python. Python 3k will have it, to some degree. However, it is not really going to be implemented at compile time. it will be an additional parameter check at runtime that will throw an exception should the static type check fail.

I have a bold prediction: In the end, no one is going to use the static typing features of Python. How do I know this? Because perl tried something similar, and it fell by the wayside, hard.

Granted, perl’s typing system was extremely naive and difficult to use. But it is a testament to me that I don’t see any new code with it being used. In fact, I bet you could just ignore the whole thing—just pass those constructs up and not even recognize them—and the old code that uses them won’t even notice. This is partly because the code that is calling the statically typed subroutines are already debugged, but also because if there is an issue, it will come up. If there isn’t, it won’t.

Duck typing these days is taking a lot of hits. That’s unfortunate, because duck typing is the exact amount of typing we need. Duck typing, in the end, says, “Who cares what type it is? I’m just going to use it and if it wasn’t duck enough, we’ll be eating patte of whatever you passed me.”

See, sometimes I do know better than the person who implemented the function what should be passed in. Sometimes I want to sneak something in that is not expected. Here’s an example: The sys.ps1 global variable in the sys module. At first glance, 99% of the programs would say, “That should always, 100% of the time be a string.” But then that 1% who actually seriously use BASH everyday and know that $PS1 is most definitely not a string but actually a piece of code written in a special language will pipe up and say, “That is most definitely *not* a string. It is something that could be turned into a string, but that’s all it is.”

Sometimes, the people who put the guts inside of the black box are too strict. Sometimes they overestimate what the requirements for input are. And sometimes people who use those black boxes know better.

So let’s leave our contracts where they belong—in the documentation. Let’s allow coders to put together their systems and see if they work, to learn how the black boxes work better than the people who made the black boxes. In other words, let’s keep our noses out of each other’s business.

Language Realms March 23, 2007

Posted by PythonGuy in Java.
add a comment

There are a few things that really wrinkle my hide because I know that they are cop-outs.

Programming languages have different specialties; use Python for X and Java for Y.

I don’t like this because it is not true. A language is a very,very general purpose tool. The same English we use to worship at church is the same English we use to talk about physics. The same English we use to talk with children is the same English we use at board room meetings. Sure, the vocabulary is a little different (because the scope of the conversation is different), but the sentence structure, the basic vocabulary, etc, are all the same.

Wouldn’t life suck if you had to speak one language as a child, another as an adult, another in church and another in science? Why, this would completely separate the communities from one another. It would become impossible for children to speak with adults, and clergy with scientists. It would be an utter disaster.

Which is why, “different realms, different languages” is a terrible idea. That only segregates realms of problem from one another.

Now, I know that this is semi-true today. I can’t write certain kinds of programs in Python or Java because the infrastructure is simply not there. But doing so is not impossible–it only requires that  I lay the groundwork. This would be comparable to translating the Bible from Latin to English, or making German Physics papers available in English. It would be comparable to explaining what all the specialized terms that churches and physicists use in their respective languages, and then standardizing terms in the common language.

I am a firm believer in “one language to rule them all” because I believe we will all be better off if we do. Now, which language should that one language be? I don’t know, but let’s not fool ourselves into thinking that having many languages is making our lives any easier. It isn’t.