Stop the systematic abuse of object-oriented programming

Object-oriented programming (OOP) has become the dominant type of programming over the last 10 years or so; a major driver of this has been Java, VB.NET, and C#. But what I keep seeing more and more is that too many programmers using object-oriented languages really do not understand OOP.

A huge misunderstanding is the concept of encapsulation. Encapsulation is meant to hide the underlying implementation of a concept from the code that makes use of the object — not to expose it. The idea is that the consuming code does not need to know or care about the particular implementation “under the hood,” so it can be changed without affecting anything else. Encapsulation works hand-in-hand with polymorphism.

Between encapsulation and polymorphism, code can (and should) be extremely loosely coupled. But really it isn’t in many pieces of code that I have seen. Far too many objects end up simply being equivalent to a Pascal “type” structure, a strongly typed collection of other types, gathered in one spot for easy reference. Another fairly common misuse of OOP is to write “classes” that play out like hashtables of hashtables of hashtables. While that type of programming made sense in Perl for a variety of reasons (not the least of which is the lack of a comprehensible object system in Perl), it is not in the spirit of OOP.

Why are these techniques a problem? For one thing, they require too much knowledge by the consumer of the underlying functionality. The first example leads to these statements that look like this:

FooObject.Property.Item(Index).Method(Parameter 1, Parameter2).Property = BarObject.Method(Parameter 1).Property.ToKludgeObjectType()

If the consumer has no idea what any of those sub-properties, methods, and so on do, they cannot get too far using either of these classes. On top of that, by exposing so many of the internals to the consumer in what will need to be a full-access manner, the encapsulating object hands over full control. This can cause some real damage, particularly if those contained classes have properties or methods with negative consequences.

The second type that I describe typically looks something like this:

FooObject("Property").Item(Index).Method(Parameter 1, Parameter 2)("Property") = CType(BarObject.Method(Parameter 1).Item("Property"), KludgeObjectType)

Wow… what an utter disaster. Can you imagine working with this? The worst part is that, with all of those collection lookups, you can throw compile time checking out of the window. The person who writes this manages to combine a very dangerous aspect of dynamic languages (lack of compile time checking) with the worst of compiled languages (design time knowledge of types) into something that derives none of the benefits of either type of language. One “fat finger mistake” in all of those lookup values will compile just fine, but come run time, they will become errors of one sort or another. It would not be so bad if a simple mistake just lead to an outright exception like “Index out of range,” but if the mistake just happens to be purely logical (e.g., the item named does exist, but the wrong item was named), there is a solid chance that the code will keep running but with silent and hard-to-detect corruption of data and/or logic.

I know part of the problem here is simple laziness. I am guilty of it plenty of times. For me, what usually happens is that I am using an OO language for something that I really just need a procedural or mostly procedural language for. Let’s face it, not every application requires too much OO design — they really just need a way of quickly passing a bunch of loosely related data around. But these “shuttle classes” always seem to take on a life of their own, and the next thing you know, you are writing static/shared classes with static/shared members to process the data within the “shuttle classes.” Why? Because you really meant to be using Perl, Pascal, or maybe even Smalltalk or a simple shell script, not C++, Java, C#, or VB.NET (at least for this one part of the project, that is).

Folks, this is where the rubber stops meeting the road. Those earliest experiences with programming will always color our current thought process regarding programming. And nearly universally, we were introduced to programming with a procedural language or a very procedural use of a non-procedural language. Add to that the fact that contrary to popular belief, Java, VB.NET, and C# are not purely noun-oriented OO. After all, they have some primitive verbs in there. What we really just want to do sometimes is to extend the language itself (add new primitive verbs) –that is where those anti-OO static classes of static methods come from, and it is the only way we can really add a new verb to the language. Those pseudo-procedural-functions end up needing a ton of parameters passed to them (just like procedural code), since the data that they are working on is no longer included in the class that they are members of.

At the end of the day, this type of programming is indicative of one or more of the following things:

• The programmer was “born and bred” in a non-OO environment and is untrained in proper OO.
• The programmer does not feel like using the proper OO techniques for whatever reasons.
• The language being used is the wrong language for the job.

I think the last item is a lot more common than most of us care to admit. After all, we turned to OO to save us a lot of headaches, increase code reuse, etc. But none of the OO promises can be fulfilled when we treat an OO language like it is something that it is not. And if we are going to program away the benefits of OO, why bother using the languages?

I guess this is yet another reason why I am fairly pro on the .NET CLR (and would be on the JVM if Sun was more supportive of other languages). It is possible (in theory) to write the right code in the right languages. Sadly, the only two languages with massive support in .NET right now are the nearly identical twins, VB.NET and C#. It looks like the first language to get formal “kid brother” status is the functional language F#. IronRuby and IronPython are still “CodePlex cousins,” in which Microsoft might donate some time, server space, and documentation but little real support. Ruby is also attractive to me because it seems to blend procedural and OO code pretty well. I really, really need to try Ruby out.

The takeaway here is that you really need to get off the couch, learn proper OO, and use it correctly. Otherwise, you are hurting your own efficiency, writing slow code (all of those collection lookups and OO tree traversals are rather expensive!), and making your code difficult to maintain. If you still cannot figure out how to write what you need in an OO-friendly manner, you may need to think about switching languages.

courtesy @TechRepublic

fetched from blog4aurobindo(blogspot)

Developer efficiency myths and truths

If you read the ads in development-related magazines or on Web sites, you would think that solving development inefficiency is a great path to making big bucks — and I believe that it is. There are tons of products on the market that claim to improve developer efficiency, from different languages to IDEs, automated build tools to automated build environments. I will try to bust some myths, bring to light a few truths, and show some partial truths regarding developer efficiency.

Myths about what leads to developer efficiency

#1: Drag ‘n Drop IDEs are the be-all and end-all.

Drag ‘n Drop IDEs are great… for building UIs. Outside of using a Drag ‘n Drop IDE as a graphical code generator for UI-specific tasks, they universally stink. Unless you are writing an application so basic that the IDE’s assumptions about how code should be written won’t hurt things, chances are you will rip out at least half of the code that the Drag ‘n Drop IDE put there for you. Go ahead, use Visual Studio or Eclipse — they are great IDEs. But be wary of trying to drag ‘n drop your way to a complete application.

#2: Slumber parties at the office equal more quality work completed.

I call a workaholic programmer who regularly pulls all-nighters The Martyr. It is tempting to think that putting in more hours equals more work, but most developers are spun out by 5:00 PM. Development is brain-taxing work, and you cannot do it when you’re tired or improperly nourished. A late night here and there may pay off, but chances are, the quality of the work done past 6:00 PM or 7:00 PM is low, and the next day your efficiency will be in the toilet. Avoid the late night work whenever possible — you are not nearly as efficient as you’d like to think.

#3: Caffeine, nicotine, and sugar are your friends.

Caffeine, cigarettes, and sugary beverages contain chemicals that might provide a temporary boost in awareness, alertness, and concentration. But the 30-minute jolt that a can of Mountain Dew might give you is followed by a much longer crash that dulls your senses and fatigues your body. This is why you see people with trash cans full of soda bottles, cigarette packs, and coffee cups; they need to continually ingest the chemical(s) of their choice to find a balance. Trust me, I have been there myself (regrettably, I started drinking coffee again a month ago, but I am still cigarette and sugar free). Try to replace the coffee with water, the sugar with fruit, and find a way to quit smoking. Not only will you stop feeling the nasty side effects of coming down, but you will also have much fewer interruptions when you do not need to leave your desk constantly.

Truths about what leads to developer efficiency

#1: Environment matters

No, I am not talking about Al Gore or Greenpeace. If you are in an office, I bet good money that there is a standard fluorescent light bulb over your head. It probably cost the builder $45 or less to install; meanwhile, full-spectrum task lights can easily cost over $100.

Ever notice how many IT pros turn the lights out in the office? It is because fluorescent lights are horrible on your eyes when you’re using a PC; turning the lights off reduces the immediate stress on your eyes that causes the 2:00 PM headache. The problem is that your eyes dilate even more when you turn the lights off, letting even more of the eyeball killing monitor light damage them. In other words, the short term “fix” does long term damage. Go ahead, buy the $100 task lamp; it is cheaper than a new pair of glasses or contacts, and it will improve your efficiency significantly since you won’t be in pain by mid-afternoon.

#2: Practice makes perfect

A lot of developers think that warming a chair for 10 years makes them a better programmer. The fact is that someone who spends time reading about new ideas and trying them out on their own time is going to learn valuable lessons that they can apply in their day-to-day work. If you want to become more efficient, I suggest spending time working on a project (at home or set aside an hour or two a week at the office) that is related to work but that uses techniques that are new to you. You will discover that learning new techniques always pays a huge dividend.

#3: Limit interruptions

Your manager is making you less efficient. Every time he or she stops at your desk for a quick status update or e-mails you a memo reminding the team of the dress code policy, your concentration is broken. Even a slight distraction of a minute or two can take many more minutes to recover from and get back in “the zone.” Add that up over the course of a day, and you could be losing up to an hour’s worth of time where you are fully “in the problem” due to your manager or a coworker interrupting your thought process.

Close the door (if you have one), put blinders on so people near you don’t bother you, and close your e-mail and IM clients. Limit opening your communications software to a few times a day (after a meal, a restroom break, or other similar time is perfect, since you have already lost your train of thought anyway). If it is really important, they can pick up the phone and call you.

Partial truths about what leads to developer efficiency

#1: Code generators may lead to more work on your end.

If you are doing a ton of rote tasks, like creating the accessors for a class that represents a 200 element XML schema, code generators are great. Drag ‘n Drop IDEs make short work of generating UI code, but unless your task is extremely generic, you will probably spend more time tweaking the generated code than it would have taken you to just write it yourself. For specialized tasks, sometimes a text editor that supports regex find/replace or a spreadsheet program like Excel can do a task in a few moments where pricey code generators fall flat.

#2: Language matters some of the time.

Sometimes language matters, and sometimes it doesn’t — it is completely situational. For example, many of the languages that can be written extremely quickly thanks to type inference or syntactic tricks are often difficult to follow when they are maintained. The two minutes worth of typing saved can cause an hour of wasted time down the road. The current mainstream languages (Java, VB.NET, and C#) are all so similar (VB.NET is slightly more verbose) that none of them are particularly more efficient to work with. Some languages do have unique properties and advantages that can significantly impact development time. For instance, try writing something that is as pure logic (or math) as a weather forecasting system in C#, and you’ll be sorry. On the flip side, a typical Windows desktop application written in Fortran will probably take forever. Library support matters too; some languages, despite being weaker, in and of themselves, have library support that makes up for it.

#3: Personal life

Developers who get phone calls from friends and family for a total of two hours a day are probably not going to get much done. However, locking people down is not going to fix the issue of personal calls either. For many people (particularly those with children), a five minute phone call might save a trip home. In an ideal world, developers would not let their personal life and issues affect their work. In the real world, an argument with a spouse, money worries, the kids’ grades, and so on can and will spillover into someone’s work time.

So, for all you managers out there, while personal telephone calls represent an obvious inefficiency, it’s fairly useless to have a programmer in the office who has something heavy on his or her mind. They won’t be able to concentrate anyway, so go ahead and let them do what they need to do within reason.

Are you a developer??? cheers Aurobindo

fetched from blog4aurobindo(blogspot)

Meeting the software development challenge with static source code analysis

This white paper highlights key business and technology issues facing large software development teams and discusses how Coverity’s groundbreaking static source code analysis technology enables them to detect and fix critical defects and security vulnerabilities early in the development process.

here is the pdf.

source @TechRepublic

fetched from blog4aurobindo(blogspot)

Why developers should check out ColdFusion 8

Adobe ColdFusion 8 (CF is a force to be reckoned with in the application server space. I’ve been using ColdFusion for 10 years, and I haven’t seen the community this excited about a new release in a long time. The recent release is by far the most compelling version since they moved to the Java platform — and possibly even the most compelling version ever.

There is a long list of new features and enhancements in CF 8, but in this article, I’m just going to focus on five of my favorites.

Server Monitor

The Developer and Enterprise Editions of CF 8 offer the highly anticipated Server Monitor feature. This might be the single biggest addition to ColdFusion, since it blows away anything I’ve seen on any other server platform.

Using the beautiful Flex-based Server Monitor interface, you can now watch requests move through a live server. You can see exactly how much memory a session or an application is using, what the template cache is doing, and which threads are taking too long to run.

You can also drill down into live requests and see which individual tags or method calls are slowing things down. It’s immensely powerful to watch the monitor and immediately tune your code in response. Is a query getting executed a lot? Cache it! Is a tag or function causing a bottleneck? Now you know exactly what line of code to optimize. Want to write your own code that runs in response to a hung thread, low JVM memory, or anything else? The monitor API will let you.

Exchange integration

It’s incredibly easy to integrate CF 8 with Microsoft Exchange. With a few lines of code, you can add events to Exchange calendars; add and remove attendees; manipulate tasks, contacts, lists, and more.

Love it or hate it, Exchange is such a staple for many IT departments that the ability to interact with it — or even build your own full-blown interface to your Exchange data — is a big boon to a lot of businesses that use ColdFusion.

AJAX capabilities

Another hugely popular addition in CF 8 is a large set of built-in AJAX functionality. By using simple tags or JavaScript functions, ColdFusion will handle all the chores for creating great AJAX-based applications. CF 8 makes these things a snap: autosuggest, related select boxes, dynamic content updates, and EXT-based datagrids.

One of the coolest features is the ability to create JavaScript proxies for server-side ColdFusion Components (CFCs). You can call a method on the proxy, and under the hood it will make a call to the corresponding method on the CFC. All the work of translating data to and from JavaScript Object Notation, converting ColdFusion datatypes into JavaScript types, and protecting against hack attempts is all handled for you by the ColdFusion server.

There’s even an excellent AJAX debugging window that shows everything that is going on. This probably has the biggest “wow” factor for the new release, since developers of any skill level can whip up a jaw-dropping AJAX application in minutes.

Image manipulation

CF 8 takes image manipulation to a new level. Adobe added more than 50 new tags and functions for dealing with images. The capabilities include simple things like resizing, getting image sizes, and converting images, as well as virtually any image-based task you can imagine. This includes drawing, adding text, and adding effects such as blurring, antialiasing, and rotating.

Performance

The best improvement in CF 8 is that it’s really fast. The development team really outdid themselves in this area. Depending on the application, it can be up to 10 times faster than CF 6 or CF 7. Some processes, like CFC instantiation, are an eye-popping 23 times faster than CF 7. So even if you upgrade to CF 8 and don’t use any new features, your application could easily triple or quadruple its performance on the same hardware. This is quite a compelling reason to upgrade.

Great extras

I’m only scratching the surface of all the amazing new capabilities in CF 8. The list goes on and on to include: generating ATOM and RSS feeds with one line of code; zip file manipulation; built-in Flex Data Services; ColdFusion administrator enhancements; and PDF and PDF form generation. There are three additional benefits to using CF 8 that I will briefly cover.

CF 8 lets you integrate with .NET objects as easily as you can currently integrate with Java objects. The .NET assets can be remote, which means you can use them even if your ColdFusion server is running a UNIX-based OS.

Adobe supplies a series of nice plug-ins for the Eclipse IDE that work with CF 8. This includes simple things like built-in ColdFusion docs, automatic generation of CFCs (including ActiveRecord, Data Access Objects, Beans, etc.), and wizards that will generate a full-blown AJAX application. It also includes a full debugging perspective. In conjunction with the free CFEclipse plug-in, this makes Eclipse the standard IDE for most advanced ColdFusion developers.

CF 8 gives you the ability to do your own thread-based programming. If you have a long running task, you can fire off another processing thread and forget about it; or you can trigger multiple threads to speed up a process and then join them back together and continue.

Download a free edition of CF 8

CF 8 Developer Edition is free, so I urge you to give it an honest look. I believe existing ColdFusion users will find a lot to like in version 8, and new users should try out this application server.

What do you think of CF 8?

Now that I’ve shared my thoughts about my favorite features and enhancements in CF 8, I want to hear what you think of this release. What features do you like the most in CF 8? If you aren’t using CF 8, what features pique your interest enough to give it a look?

fetched from blog4aurobindo(blogspot)

10 signs that you aren’t cut out to be a developer

Programmers make big bucks. Software developers dress casual every day of the week. Anyone can teach themselves to be a programmer. These are just a few of the reasons why people say they want to become a developer. Unfortunately, the job market is littered with people who may have had the raw intelligence or maybe even the knowledge, but not the right attitude or personality to become a good programmer. Here are a few things to consider when deciding whether you should become a software developer.

#1: You’d rather be trained than self-teach

In most development shops, there is rarely any training, even if the company has a training program in place for other employees. At best, the company might reimburse you for a book you buy. Programmers are expected to arrive on their first day with all (or at least most ) of the skills they need. Even worse, the assumption is that programmers are really smart people who are good at problem solving. That assumption leads upper management to believe that good programmers do not need training. Finally, training for developers is extremely expensive. The result? When you change positions, you will need to figure out what is going on yourself, and you will probably need to teach yourself.

#2: You like regular working hours

Software development projects are notorious for being late. Even the projects that are delivered on time always seem to run behind schedule at some point. If you don’t like (or can’t handle) irregular or fluctuating demands on your time by your employer, development is not for you. When crunch time comes, your employer is more concerned with getting the product in the hands of a million-dollar client than with your child’s soccer game or the new TV program you wanted to watch.

#3: You prefer regular raises to job-hopping

The world of development is one of continual erosion of skill value. Unless you are working at a shop that deals with slow-to-change technologies, chances are, your skill set is less valuable every day. The state of the art is changing rapidly, and the skills that are hot today will be ho-hum tomorrow. As a result, it is difficult to sit at the same desk doing the same work every day and expect a raise that exceeds a cost of living increase. You need to keep your skills up to date just to maintain your current value. In addition, if you want to boost your paycheck, you need to expand your skill set significantly and either earn an internal promotion or go to another company.

#4: You do not get along well with others

It’s one thing to be an introverted person or to prefer to work by yourself. It’s another thing to be unable to get along with others, and it can sink you as a developer. Not only that, your manager may well be a nontechnical person (or a technical person who has not worked hands-on in some time), so you need to be able to express yourself to nontechnical people.

#5: You are easily frustrated

Software development is often quite frustrating. Documentation is outdated or wrong, the previous programmer wrote unreadable code, the boss has rules to follow that make no sense… the list is endless. At the end of the day, no one wants to be working next to someone who is always cursing under his or her breath or screaming at the monitor. If you are the kind of person who goes insane spending eight hours to do what appears to be 10 minutes’ worth of work, this is not a career for you.

#6: You are close-minded to others’ ideas

In programming, there are often problems that have only more than one “right” answer. [Update: Corrected by author] If you do not handle criticism well, or do not care to hear the suggestions of others, you might miss something important. For example, a few weeks ago, one of our junior-level people made a suggestion to me. After considering it for a bit, I decided to try it. It turned out that he was right and I was wrong, and his suggestion brought the time to execute a piece of code from multiple days to a few hours. Ignoring this person due to the difference in our experience levels would have been foolish.

#7: You are not a “details person”

Programming is all about the details. If you get lost in a movie more complex than Conan the Barbarian or have a hard time filling out a rebate voucher, you probably won’t do very well in the development world. Sometimes, something as simple as a missing period can mean the difference between random failure and perfect success. If you are the type of person who might not figure out where the missing period is, your career will be limited in range, at best.

#8: You do not take personal pride in your work

Sure, it’s possible to program by the book and do a passable job. The problem is, the book keeps getting rewritten. Software development is not a factory job where you tighten the same bolt all day long, where a touch too much or too little torque makes no difference. It requires independent thought, which in turn requires the people doing the work to take pride in it. Furthermore, it’s easy to do something the wrong way and have it work just well enough to end up in production. That “little error” you turn a blind eye to since it doesn’t seem to cause any problems will cause problems. Programmers who do not treat each project as something to be proud of turn out poor quality work, which in turn makes their careers short-lived.

#9: You prefer to shoot first and ask questions later

Software developers, at least the good ones, spend a lot more time planning what they’re going to type than actually typing. Usually, when coders just open up their code editor and start banging away at the keyboard, most of what they write gets ripped out later. Programmers who ponder, think, consider, and plan write better code in less time with fewer problems. There’s a reason so many programmers barely know how to type properly: The hard part of the job is knowing what to type. People who do not invest the time up front in their zeal to get started with the “real work” are actually skimping on the “real work.” If you are a doer and not a thinker, software development is probably not a good career choice for you.

#10: You do not like the geek type of person

For a bunch of reasons (some legitimate), a lot of people just do not enjoy being around the engineer or techie personality. If you have a hard time with the Dilbert or Weird Al personality type, do not even consider going into programming. Are all developers like that? Of course not. But they comprise a large enough portion of the workforce that you would be miserable in the industry.

courtesy @ TechRepublic

fetched from blog4aurobindo(blogspot)

The programming paradigm needs an update

The way I view programming is different than it was a week ago due to various factors. First, I have spent a lot of time lately with my head buried in the .NET documentation, and something in the back of my mind said, “If C# is so much more efficient than VB.NET, why do all of the code samples appear to be the same length and look virtually identical?” Then, I reread an e-mail from someone telling me that XYZ language was awesome because it needed dramatically less source lines of code (SLOC) to do the same thing as more mainstream languages. And, I have still been multithreading the same dumb little piece of code. Finally, I read a post by Mark Miller about Emacs and Lisp.

It is all coming together for me now, the conscious understanding of what I really dislike about programming. I got into programming because I like solving problems, but solving problems is really only a small fraction of the work. The rest of it is giving exact, precise details as to how to perform the tasks that solve the problems. It is like painting the Sistine Chapel by putting a seven-year-old boy on a scaffold and dictating to him every stroke you want him to make. It is ridiculous.

This highlights the real problem in the programming industry: Everything we slap on top of the development process is more garbage on top of a rotting foundation. Let’s take a closer look at what we do here, folks, and examine how much the programming paradigm has (or has not) changed.

Then (i.e., 10 -20 years ago)
A programmer sits down and analyzes the process of the work. Using a stencil and a pencil, he lays out a workflow on graph paper. The programmer sits down, fires up his trusty text editor (if he is lucky, it supports autoindent), and creates one or more text files containing source code. He then compiles the source code (or tries to run it through an interpreter) to check for syntactical correctness. Once it compiles or interprets correctly, he runs it with test cases to verify logical correctness and to check for run-time bugs. Any bugs are logged to a text file; or maybe he has a debugger or crash dump analyzer to find out what went wrong. This continues until the program is considered complete.

Now
A programmer sits down and analyzes the process of the work. Using a flowcharting tool or maybe a UML editor, he lays out a workflow. The programmer sits down, fires up his trusty IDE (if he is lucky, it supports version control), and creates one or more text files containing the source code. Some of this code may be auto-generated, such as data objects based on the database schema or some basic code from the UML. Half of this generated code will need to be discarded unless the project is very basic, but at least it is a start. The IDE will handle the basics of getting a form to display regardless of whether it is a desktop app or a Web app. The programmer then compiles the source code (or tries to run it through an interpreter) to check for syntactical correctness. Once it compiles or interprets correctly, he runs it with test cases to verify logical correctness and to check for run-time bugs. Any bugs are logged to a text file; or maybe he has a debugger or crash dump analyzer to find out what went wrong. This continues until the program is considered complete.

Wow… we’ve traded in vi for Visual Studio and a bunch of print statements for [F11]. At the end of the day, nothing has really changed except for the tools, which are barely keeping pace with the increasing complexity of developing software. We are stuck, and we are stuck badly.

The Lisp advocates like to say, “Lisp would have taken over if only we had better/different hardware!” Now we have the hardware, and Lisp is still not taking over. I assert that we need to go far beyond something like Lisp at this point; we need to get into an entirely new type of language. A great example of this is multithreading.

IT pros usually say two things about bringing multithreading work mainstream: Compilers need to get a lot smarter before this can happen, and we cannot make the compilers smart enough for this to happen well. If this seems like an irresolvable contradiction, it isn’t. The problem is not the compilers — it’s our paradigms.

If you’ve spent a fair amount of time with multithreading, you know that it will never become a commonplace technique until the compiler can handle most of it automatically. The fact is that it’s tricky for most programmers to keep the details of a system where concurrency is an issue — and debugging these systems is a pure terror.

Smarter compilers are the answer, but there is a truth amongst the compiler folks that compilers will never get that smart. Why? Because properly translating a serial operation into a parallel one requires understanding the code’s intentions and not just the step-by-step how to guide that the source code models. I can read your code and (provided it is clear enough) understand probably 80% of your intentions up front and possibly figure out an additional 10% or 15% of your code with time. The other 5% or 10% will be a mystery until I ask you.

Read the comments on this post from Chad Perrin about Python and Ruby; these people are trying to optimize a trivial chunk of code. What is even more interesting is the point Chad makes over and over again in his responses (he posts as apotheon): Maybe the intention of the code was to produce that onscreen counter that is eliminated in most of the optimizations. Or maybe, despite it being slower due to the concatenation of immutable strings, there was a knock off effect of that as well. Who knows? The intentions cannot be made through code without having ridiculously verbose comments in the code or having an exacting product spec available.

Perl appears to understand intentions, but it is a trick. Perl was simply designed to make certain assumptions based on the way most programmers usually think in the absence of logical code. If your intentions do not square with Perl’s assumptions, it either will not run, or it will not run properly. If you do not believe me, try abusing Perl a little with a record format that specifies the tilde as a record separator instead of newline. Perl’s assumptions fly out the window unless you set the record separation string in your code; and, at that point, you are no longer actually using the assumptions — you are giving it precise directions.

I am all for self-documenting code. I like to think that no one reading my code had to struggle to figure out what it does. But aside from design specs and/or pages of inline comments, there is no way for someone reading it to know why I wrote the code that I did. It is like being in the Army. They usually don’t tell you why you need to march down a road, they just tell you to do it.

Programmers are in a bind. Without a way for the compiler to know the design specifications, the compiler cannot truly optimize something as complex as a parallel operation beyond really obvious optimizations. There are no hard and fast rules to making a serial operation parallel; it is a black art that involves a lot of trial and error even for frequent practitioners. In order for the compiler be able to understand those design specifications, it would require an entirely different type of language and compiler. Assertations and other “design by contract” items are not even the tip of the iceberg — they are the seagull sitting on the iceberg in terms of resolving the issue. If the compiler is smart enough to understand the design document, why even bother writing the code? UML-to-code tools generally try to do this, but they do not go far enough. At best, these tools can translate a process into code that literally expresses that process; there is no understanding of intention.

There are a few major schools of programming languages — object oriented, procedural, functional, and imperative — all of which have their strengths and weaknesses. Functional and imperative languages come the closest to what I am talking about. SQL is a great example. You tell it what you want not how to get what you want. The details of the “how” are up to the database engine. As a result, databases are optimized in such a way that they run a lot faster than what 99.9% of programmers could get the same stuff to run (not to mention redundancy, transactions, etc.) despite their rather general purpose nature. Even SQL shows a lot of weakness; while it is an imperative language, it is extremely domain specific. As soon as you want to manipulate that data, you land yourself in the world of procedural code either within a stored procedure or your application.

Most applications (and every library) become a miniature domain specific language (DSL) unto itself — not syntactically (although some, such as regex libraries, reach that status), but in terminology, subject matter, and so on. The problem you are most likely trying to address has absolutely nothing to do with the language you are using and everything to do with a specific, nonprogramming problem.

A great example of the disconnect between code and the problem it addresses is the subject of loops. I bet over 50% of the loops out there go over an entire data collection and do not exit without hitting every single element in the collection. The logic we are implementing is something like “find all of the items in the collection that meet condition XYZ” or “do operation F to all items in the collection.” So why are we working with languages that do not deal with set theory?

Programmers end up implementing the same thing over and over again (i.e., a function or object or whatever in a library that takes that big set as the input) and implementing a filter command that returns a smaller, filtered set, or an “ExecuteOnAll” method that takes a pointer to a function as the argument.

When the language folks try to make it easier on us, the result is stuff like LINQ, the welding of a DSL to a framework or language to compensate for that language or framework’s shortcomings in a particular problem domain.

The only way LINQ could get implemented is if the languages that support it have closures, which are “the thing” in a functional language like Lisp; closures are even important in Perl. But programmers have been working in Java and Java-like languages for the last five – 10 years (depending on how much of an early adopter you were), and a lot of folks missed Perl entirely, either sticking with VB and then the .NET languages or starting with C/C++ (or Pascal) and going to Java and/or .NET. The only exposure most programmers ever had to a truly dynamic language is JavaScript (aka ECMAScript). (By dynamic language, I mean a language that can edit itself or implement or re-implement functionality at run-time. JavaScript, with its support for eval(), has it and so does Perl. In functional languages like Lisp, this is all the language really can do.) In reality, JavaScript is not that bad; in fact, I like it quite a bit. I am just not a huge fan of the environment and object model programmers are used to seeing it in (the browser DOM).

Most of the programmers I have dealt with have little (if any) experience with a dynamic language. The result is that they don’t have the ability to think the way you need to about a dynamic language. These programmers stumble around blind; they intuitively know that they aren’t working to their potential, but they have no idea where to start. (Why else would there be the huge market for code generators and other gadgets to improve productivity by reducing typing?)

I do not believe that Lisp and its ilk are the answer; they are too difficult for most programmers to read through and understand, and the entire code is a back reference to itself. Procedural languages have also proven hard to maintain. Object-oriented languages are the easiest to maintain — at the expense of being insanely verbose, which is another reason for the code generators. Imperative languages are almost always going to be little more than DSLs.
Where do we go from here?

I want to see programmers headed towards intentional languages. I have no idea what they would look like, but the source code would have to be a lot more than the usual text file and would need to be able to express relationships within the data format, like XML or a database do. The programming paradigm needs to be able to quickly reduce any business problem to an algorithm so that the real work can go into writing the algorithm and then, at the last minute, translating the results to the domain’s data structures again. The programming paradigm would look like a mix of a lot of different ideas, but syntax and punctuation would have to be fairly irrelevant.

What are your thoughts about the programming paradigm? What direction do you think it needs to take?

fetched from blog4aurobindo(blogspot)

Sun says farewell to mobile Java

According to James Gosling, often called the father of Java, the Java Micro Edition (ME) will gradually supplanted by the Java Standard Edition (SE). He said, “We’re trying to converge everything to the Java SE specification. Cell phones and TV set-top boxes are growing up.”

The idea is that mobile devices are packing ever increasing amount of processing power – enough to handle all the demands of full-featured Java.

Excerpt from News.com:

Sun’s Java expectation dovetails with recent trends, most notably Apple’s iPhone, which architecturally is much more an Apple computer writ small than a mobile phone writ large. In particular, Apple uses a version of its regular Safari Web browser so users will have as much of the desktop Internet experience as possible.

To be clear, the move to Java SE won’t be happening overnight. Smart phones using various pared-down versions of Java is expected to stay in the market for at least a decade. But the shift is already under way.

courtesy @TechRepublic

fetched from blog4aurobindo(blogspot)