Promiscuous programming

-

How many folks out there are promiscuous programmers? You know who you are, every project you work on, you meet a new technology or language and feel compelled to "try it out"... without giving the right amount of consideration to the language that is currently being used. Worse yet, you seem compelled to badmouth a language that has been really good to you ( I love you java;) ) and always compare the imperfections of your programming wife ( java, you're syntax is really bloated) to the sexy cool stuff from one of your programming girlfriends (ruby, I love your monkey patch).

I'm not saying that this is necessarily a bad thing, I think it is very important to have breadth in technology and learning new programming languages is a way to become a better programmer. It's more important though, to have an objective perspective about the REAL comparison and not just get infatuated with every new thing that wanders by because you think (or worse yet someone else thinks) it's better. Listen to me folks, the grass is rarely greener on the other side of the fence... It's different, and frankly it MIGHT be greener... but even if it IS greener, that doesn't necessarily make it better.

So where am I going with this? Am I suggesting that being a promiscuous programmer is a bad thing? Not really... and in that respect perhaps the metaphor is a bit bad. But, you have to suspect advice about women from a guy who's only ever been with one woman about women because ... he has a noted lack of experience. What I'm saying is when you're starting out, playing the field and figuring out what you like is important, but it's also important to commit to something and really "know" it. Make sure that changing languages is a conscious decision and you weight the benefits and drawbacks of such a switch lest you spend your entire career as a programming slut flitting between one fancy new thing and another.

Comments

Franklin Chen said…
This comment has been removed by the author.
October 19, 2011 at 8:32 AM
Franklin Chen said…
Interesting to see this topic pop up today, because just yesterday I touched on this in a blog post on the theme of time management in which I mentioned having decided to stop being too much of a programming language hobbyist (and that thought came up when I was trying to come up with a list of Pittsburgh software developer groups and realized that ironically, it's not such a great thing that I've explored so many of them.
October 19, 2011 at 8:35 AM
Anonymous said…
Really badly written piece.
December 25, 2011 at 7:41 AM
Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules ...
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u...
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa...
Read more