INCOHERENT Raving

Manifesto for Integrated Development Environments

Wed, 5 May 2010 00:54:03 +0100

Have you recently take a peek at Coda, or Espresso, or Textmate? Or even Google Chrome's Developer Tools? They are well designed, intuitive, interface rich, and extensible. But Coda, Espresso or Textmate, among several, are text editors, not IDEs. On the other side, VIM and Emacs live in the last century, and Eclipse is an over-bloated platform.

This post is more like an outcry for a decent, common infrastructure for REAL IDEs. Still, there are some questions attached: (i) what features are needed for such a product and (ii) what products are out there that could fulfill this need, and what are they missing? So here's my draft for a manifesto:

Manifesto for Integrated Development Environments

‣ We favor interactivity and productivity over syntax and tools.
‣ We favor inline, contextual documentation over man and html files.
‣ We favor high-definition, graphic-capable color screens over character terminals.
‣ We favor the use of advanced input schemas over unintuitive keyboard shortcuts.
‣ We favor a common, extensible and customizable infrastructure over unmaintained chain-tools.
‣ We know the difference between search&replace and refactoring.
‣ We know the difference between integrated debugging support over a terminal window.
‣ We know the difference between semantic-aware completion over dumb textual templates.
‣ We know the difference between keyword-highlight and syntax-highlight.
‣ We favor the usage of standards like (E)BNF.

That is, while there is value in the items on the right, we value the items on the left more.

P.S.: This last phrase is bluntly taken from the Agile Manifesto.

On Buzzword Degradation

Sat, 1 May 2010 15:55:42 +0100

You know that feeling you have when you repeat a word so many times that it starts to loose its meaning? Try it:

Rumination, Rumination, Rumination, Rumination, Ru-mi-nation, Ruu-mii...

Well, do you? Because this is the precise feeling I now have when hearing words such as innovation, cooperation, communication, openness, leadership, teamwork, emergence, entrepreneurship, among (too) many others...

... and I wonder: well, I know what I understand about teamwork. But what exactly do you mean about it? Actually, what exactly do they mean nowadays, now that everyone uses them? If everyone is “innovating”, where is your difference?

Personally, I tend to regard them as shallow strings of plain letters, boldly highlighted in video projectors. They were once good sellers, but now... Now they are just worn out buzzwords, used so many times, that no one knows what they are supposed to represent. And, as such, everyone seems deprived of the responsibility on using them. Who's to blame?

The problem with these words is that they represent abstract ideas. Strong principles, perhaps, but abstract nonetheless. Next time you attend some company presentation, ask yourself: why are they just shouting these concepts, but not specifying their meaning? For instance, take “cooperation”. What exactly is a “cooperative” company? Why don't they say they prescribe specific practices instead, like "on-site customer" or “pair-programming”?

However mostly unintended, there's a reason for that. By adhering to abstract principles, it is up to the audience to fill in the gaps. Each one will understand cooperation in its very own, specific way; individual interpretations that could, in fact, be inconsistent with others. It seems the audience ought (or not) to recognize cooperation in practices such as “on-site customers”, but mostly everyone will "nod" approvingly in the face of an abstract principle.

So, who's to blame? People, of course. Make a dollar bet with your colleagues next time you attend a start-up launch — that no one in the audience will ever ask: "What exactly do you mean by cooperation?" Oh, and send me 10% ;-)

Moral of the story: don’t sell ideals; sell solutions!

I can’t draw...

Sun, 18 Oct 2009 21:47:45 +0100

.. and I barely can make humor too, it seems. Nonetheless, I’ve found these lost attempts scattered over my backups, so I’ve felt like sharing... It seamed a good idea at the time... Somehow...

The Tyranny of Small Choices vs No Up-front Design: Is Refactoring Enough?

Thu, 3 Sep 2009 23:48:45 +0100

Preview: In this post I’ll explore how the cumulative effect of designing a software system through small iterative steps may lead to suboptimal solutions. I’ll compare this phenomena to the stabilization of local maximums in continuous functions and natural selection to show how the bare process of refactoring isn’t enough. The conclusion, as the reader may have already foreseen, is the same of several agile methodologies: “no up-front design” isn’t “no design at all”...

Singleton Pool

Sat, 15 Aug 2009 13:25:53 +0100

I hate singletons. They are just like junk food: you know you shouldn’t eat it, but it’s kind of convenient... and easy. It’s a quick fix that tends to become an addiction.

Several people have already written about the evilness of singletons: they are used by the wrong reasons, most implementations aren’t thread-safe, promote tightly-coupling, mess up with unit-testing, hinders extensibility, and are a refactorer’s nightmare. Really, just google for them...

Anyway, in the past few days, I had to clean-up the code of a framework we’ve been developing for two years now. Same usual reasons: improve consistency, design, testability, extensability, and probably several other -ilities I can’t remember. As I was digging the code and writing tests to increase coverage, I started to find singletons everywhere, especially in the user-interface layer.

Now, this wasn’t just a smell. It was actually hindering decoupling. Because the instance of a singleton is usually stored as a static field in its class, everywhere we were expecting something from it we needed to explicitly access its type. But what if, in a particular instantiation of the framework, I wanted to use inheritance to change some of their behavior? Or, as it was the case, I wanted to create a Mock for testing?

Consider the following code (yeah, yeah, not thread-safe, I know):

Science vs Engineering

Sun, 26 Jul 2009 15:23:37 +0100

At the University of Porto (Portugal), we have two schools that teach computer-related courses: the school of engineering - FEUP - and the school of science - FCUP. The two courses are, respectively, “Informatics and Computer Engineering” and “Computer Science”.

Among their students, there’s always been an healthy competition. Both sides, of course, claim they are better - for any given arbitrary definition of better. They come up with several metrics and theories - guess who comes up with what - to assert their claims, but mostly they are just teasing each other and live in peaceful harmony... I guess...

This would all be good and great if it wasn’t just for one thing: I am an engineer pursuing a PhD in computer science... Let the fight begin...

FRESHMAN, AGAIN...

It has come to my attention that it was particularly funny to watch me during my first days of the PhD - at least my colleagues say so. Oddly, I don’t recall it that way: to struggle my way through the calculus of inductive constructors and other “wonders of nature”, felt like standing in a boxing ring and realizing you’ve been practicing baking. I remember one of my first reactions was to ask the professor if I was going to need to switch my keyboard to greek (phi? what’s the symbol for phi?!?).

Of course it didn’t helped that I’ve chosen a course on foundations of computer science: Program Semantics, Verification and Construction. Nonetheless, I thought that acquiring a deeper theoretical knowledge would expose me to the mathematical frontiers of software development. If a Ph.D. is about becoming a “doctor in philosophy”, I guess I couldn’t go wrong.

In the end, it all went great. I believe I’ve (re-)earned some respect among my fellow scientists, which comes handy to balance the respect I may have lost from my fellow engineers ;-)

IDENTITY CRISIS?

A friend of mine, when reading this, asked me: “So, you feel you have multiple personalities?” Heck, certainly - probably - not! I know for sure I am an engineer: I have a diploma that says so :-) It just happens that one of my left ribs thinks its from a scientist.

HOW IS YOUR RESEARCH SCIENCE?

If among colleagues this difference only serves to tease me, or make some jokes, in the academic world this is a completely different kind of beast. The kind of beast that keeps asking you “how exactly is your research science?” Not an easy question to be answered upon, but a remark I’ve heard quite often.

The thing is: I don’t know! Fortunately I am not alone. Consider the following citation from here:

“(...) computer science would be better described as being concerned with the meta-activity that is associated with programming. More generally, and more precisely, it is occupied with the design, development and investigation of the concepts and methodologies that facilitate and aid the specification, development, implementation and analysis of computational systems.“

A very peculiar definition which, amusingly, doesn’t reference mathematics anywhere.

SCIENTISTS vs ENGINEERS

Gopalakrishnan, in his book Computation Engineering, differentiates scientists from engineers as:

“(...) people who seek an in-depth understanding of the phenomenon of computation to be a computer scientist. We define those people who seek to efficiently apply computer systems to solve real-world problems to be computation engineers.”

I do not which to incur in a largely, perhaps irrelevant, rumination (although I may just did) about why my research may be considered science. Instead, I’m ranting about what is the fundamental difference between a scientist and an engineer, not regarding their profession — not even regarding their education — but the “motivational forces” behind both. I eventually dare to claim that some scientists are (should be) engineers and vice-versa.

THEORY AND PRACTICE

You see, something inside me is deeply disturbed every time I hear the phrase ”it’s just a matter of implementation...” Just? Heck! Implementation changes everything! It’s all great and good to come up with the theory of time-travel, but what about building a time-traveling machine? Is it just a matter of implementation?

Creation here is the key! It is the act of crafting something, of making a theory reality, that separates the blurry line between science and engineering. The motivational force behind an engineer is its ultimate aspiration to make something out of nothing... With a twist...

Engineers are attracted to scarce resources. So comes Turing with its infinite tape, and its infinite duration. Ah — says an engineer — that’s clever! Now do it with just a few bytes and in real-time. On the other side, the scientist would rightly reply: “still, fundamentally, it’s all the same”.

But the thing is, it’s almost a blasphemy to ask an engineer not to build his work. She just can’t. Proving it’s possible would never be enough. In her mind, it would just deem everything not worth it. If she comes up with an idea, she’ll rush to see it running, and jumping, and whatever she’ll classify as being built! Take that from her and you’ll take the driving force behind her world.

BEAUTY IS IN THE EYE OF THE BEHOLDER

I respect the church-turing thesis. It’s a beautiful theory that establishes a bridge between symbols and machines. I understand the force behind scientists to understand the “why”, and pursue mathematical truth. I am amazed by the efforts scientists take to reduce everything to its basic building blocks of construction. It is indeed an herculean task that establishes the boundaries and foundations of what can and cannot be done.

But engineers regard their art as something different: it’s not the “why” so much as the “how”. For a scientist, if two programs are proven to be functionally equivalent, then they are one and the same. But an engineering will rush to shout a torrent of “non-sense” such as design, and usability, and maintainability, and performance, and cost, and several other cryptic words that somehow would make the two programs “completely different”!

ANY CONCLUSIONS?

Do I really need to have them?... Come on... ;-)

Well, I believe that the first and most important conclusion I take is that each “guild” rushes too quickly to dismiss the other’s work. They both need each other and what worries me the most is their (un)willingly unawareness. Interdisciplinary should step down as just a buzzword, and step up as a standard practice.

Secondly, we shouldn’t try to transform scientists into engineers or the other way round: each has their own driving force behind creativity which should be preserved. It saddens me that Academia, instead of embracing both strengths and weaknesses, often disregard great ideas either because of the inability to “measure” its claims, or because someone decides that, “fundamentally”, it’s not new.

Finally, I must indulge myself into believing that I’m privileged to be in between them, which allowed me to acquire an uncommon perspective. But in the end, as researchers, all that we (I) can hope is to make real contributions which could enrich our knowledge as human beings. Not a very scientific conclusion, but surely a motivating one.

Pattern Language for Hopeless Argumentation

Wed, 27 May 2009 00:23:44 +0100

In the spirit of the “Do The Right Thing” pattern, I hereby present a Pattern Language for Hopeless Argumentation, which you can download by clicking on the above image. Shall you like, hate, made you had some good laughs, or for peculiar reason had been useful during an argumentation you had, then by all means, leave a comment :-) But, most of all, have fun!

• It’s in the Bible. Claiming truth by asserting expertise from an outside source. Alias: Appeal to Authority.
• Inversion of Responsibility. Changing the burden of proof to the opponent.
• Moving the Goalposts. Keep raising the bar of the opponent arguments, until it fails. Alias: Demand of Impossible Perfection.
• Cliche Thinking. Appealing to common sense or wise sayings.
• I’m gonna Cry. Making the audience empathize or otherwise identify with yourself through shown emotions. Alias: Appeal to Pity or Sympathy.
• Heroic Speech. Use of an eloquent and assertive discourse, targeting the audience emotions. Alias: Poetic Language.
• Void. Asserting that the absence of evidence is the evidence of absence.
• It’s the End of the World. Claiming that either the argument is true, or bad things would happen. Alias: Adverse Consequences.
• Shaken, not stirred. Use of charismatic attributes to convince the audience. Alias: Personal Charm.
• Changing the Subject. Deflecting the question by subtly changing the focus to another problem during the discourse.
• No Gray Area. Implying there are only two alternatives, when in fact there are more. Alias: Excluded Middle.
• Fast Talking. Speeding up the pace of speech such that it becomes hard to think and follow.
• Buzzword Contest. Using an overwhelming amount of technical terms, intended to confuse or look like an expert in the field. Alias: Prestigious Jargon, Argumentum Verbosium.
• Pain in the Ass. Systematically repeating the same thing, until it becomes an accepted truth. Alias: Ad Nauseaum.
• Are we there yet. Keep making questions to disrupt the opponent thought or dodge the burden of proof. Alias: Argument by Question.

Demoscene, IRC and Old-School

Mon, 24 Nov 2008 04:09:36 +0000

Back in 1994, when I started to learn C and Assembly, me and some friends started a DemoScene group. We were inspired by titles like Second Reality by Future Crew, running on an 80486 with little more than 1 or 2MB of RAM memory. Those where the days of MOD and S3M - where several musical artists have begun they carrier - and pixel graphics - endless hours of painting pixel-by-pixel and producing incredible works of art. The things we were able to do with such limited machines were most of the times amazingly displayed at the Assembly Demoparty held in Helnsiky, Finland. I remember of wishing not to be so young back then, so that I could have had the experience of participating in those (almost mythological) gatherings.

But time has evolved. MSN replaced IRC, which is now being replaced by Twitter. Facebook, Hi5 and other social networks are pervasive. I’m now able to keep an almost permanent presence in the Internet using my iPhone. And yet, back then, we were much, MUCH more social. I’ve met dozens of new people, held dozens of parties, engaged in several projects at such an young age, due of BBSs and MOOs and IRCs. Fooled are those who thought we were anti-social creatures hidden behind a computer. Most of us travelled in public transportation for miles and hours, only to gather and met dozens of new people.

But now... now that the ability to communicate is an order of magnitudes larger, why do we feel so distant? What “mystical aura” was present in those forms of communication that is, somehow, lost? Will it ever be revived? Can we afford not to?

On Patterns

Thu, 20 Nov 2008 04:35:37 +0000

I’ve recently stumbled across this post (which, by the way, I highly recommend its reading), which has someway enticed me to add some comments. Now, this doesn’t mean I don’t agree with the author concerning a few arguments; I just want to raise the awareness over some points I find particularly important.

I think it was Linda Rising, in the last PLoP conference, that reminded us of something along these lines:

“Should a pattern incite an Ahah! or Eureka! or an Hmm...?”

The thing is, a pattern is a recurrent solution observed in the wild, which solves a recurrent problem by balancing some forces in a particular way. It is not an intelligently crafted solution in the author’s basement or due to an intensive labor in a research lab. It is one such that a domain expert would easily recognize it as: “I’ve seen this!”.

Now, if the GOF’s Design Patterns should have been more or less abstract than they are is ultimately irrelevant; the authors have observed those patterns in a particular context, and while they may reveal to hold outside it, that can’t be neither guaranteed nor intended by the authors. That’s why patterns typically have a target audience. In the context they wrote the book, putting additional effort into implementation details have probably lead far more people to grasp it, than it would have been otherwise.

As a personal example, Ralph Johnson, in PLoP’08 writer’s workshop, suggested that the patterns I wrote could be generalized far beyond their original context. This, however, would need a completely different context-problem-forces triplet. Now... someone reading my paper could say: you focus too much on AOMs; you should have generalized. Well, it’s true. But the proposed pattern is intertwined in a specific pattern language, which has its own context and forces. For that purpose, I may actually have given too little detail (actually, several comments I received were more in that direction).

Alexander’s own work is the very example of what I’m asserting. The Notes on the Synthesis of Form could, could have been easily abstracted into several realms far beyond Civil Architecture. Would it be right for us to state that Alexander coupled himself into unnecessary detail?

I honestly believe the problem is not in the patterns per-se (nor even in the GoF book, which should be regarded as a germinal work), but in the people using them. Personally, I think too few people know the GoF book, or for that matter, patterns in general. Those who know and apply them blindly, have completely missed the fact that a pattern is NOT a building block of software construction! Maybe that’s a reason why GoF entitled their book as Elements of Reusable Object-Oriented Software, and not Design Rules of Good Object Oriented Software.

Richard Feynman once said:

“Know how to solve every problem that has been solved.”

I believe the study of patterns endure this ideal. They are not engraved laws of the tissue of software. They are a systematization of intrinsic, empirical, observed knowledge that can be easily communicated.

Innovation stiffs old practices

Sun, 12 Oct 2008 04:59:36 +0100

While reading a post about the new language Microsoft is supposed to release in their next development platform, I’ve found an alarming message in the author’s blog:

“But if all newbie programmers learn these new languages, who will manage the billions of lines of C and C++ we currently use in the future, unless it is implied to be completely be rewritten?”

I’ve heard this line of rationale before… Who will manage the billions of lines of assembly now that people use C and C++? Who will program hardware, now that everyone is focused on high-level software? What will be the fate of horses, now that cars are being produced?

Careful: this kind of thought may be presumptuous at best. Don’t get me wrong, this is not a direct critic to the author, but to the concept. Practices and tools need to evolve, so we can achieve higher degrees of abstraction. Attempting otherwise not only stiffs evolution, but may turn us into old dinosaurs, mumbling to the air:

“Back in old days, we used two big drums to program; one was called 1, the other 0.″

In the end, there’ll always be someone willing to beat those drums…

proof of god

Tue, 30 Sep 2008 05:01:21 +0100

I grew tired of arguing about religion, particularly because someone, at some point during the discussion, often invoked the need to prove, or disprove, the existence of God. This was the kind of argument that always made me stop the conversation right away, forever. Actually, with time I’ve started to take a simple approach before incurring in a largely, perhaps irrelevant, rumination about religion:

• I am willing to change my opinion. Are you?
• Do you agree to discuss using some kind of human logic? Or will you invoke the inability of humankind to understand the arguments you’ll point out?
• Do you understand the difference between proof and evidence?

Three out of four people will fail the first right away. My fingers are enough to count those who passed the triage so far, potentially leading to a nice, though inconclusive, conversation.

”Nothing must be held sacred. Question everything. God is not great, Jesus is not your lord, you are not disciples of any charismatic prophet. You are all human beings who must make your way through your life by thinking and learning, and you have the job of advancing humanity's knowledge by winnowing out the errors of past generations and finding deeper understanding of reality. You will not find wisdom in rituals and sacraments and dogma, which build only self-satisfied ignorance, but you can find truth by looking at your world with fresh eyes and a questioning mind.” PZ Meyers.

⊨ P = NP ∨ P ≠ NP

Thu, 14 Aug 2008 13:40:54 +0100

I recently started to read a book from Keith Devlin about the Millenium Problems of Mathematics. One particular problem which almost every Computer Scientist have heard is the P = NP. Most of these people know that this problem is directly related to the complexity of a particular algorithm. Most also know that it states that any known solution of a particular kind of problems perform in superpolynomial time. And that’s all they need to know…

What most don’t learn is the exquisite meaning of NP, which stands for Nondeterministic Polynomial; an NP class problem is one such that a non-deterministic computer can solve it in polynomial time. Got it? Let me express it in other words:

A problem which is NP can be efficiently solved by just getting luck in every choice you have to make. For example, in the traveling salesman problem, one can in fact solve it in linear time by correctly guessing the next city. The problem, thus, lies in guessing the right one!

Some people have also heard about NP-complete (NPC) problems. What is the difference between a NP and an NPC problem? To put it simple, an NPC problem is an NP problem that has been shown to exhibit the characteristic of being able to be “translated” into any other NPC problem. This characteristic may seem only vaguely curious, but has a profound relevance, since:

Should a polynomial solution be found to a particular NPC problem, it could easily be applied to every other one. It’s like a dictionary of problems; find the solution of a puzzle, and you’ve found the generic solution of that class of puzzles!

Unfortunately, this is as far as anyone has gone. No one has been able to prove that there exists NP problems that can or cannot be solved in polynomial time, since no one ever found a P solution to an NP problem. Actually, P = NP could be either proved or disproved without actually founding a particular solution: this would mean that every NP problem would have an efficient solution, though it hasn’t been found yet. But no significant advances there either.

Keith describes this enigma in such an enthusiastic way that lead me to read the formal problem statement. I must say that I don’t find it easy to read... But I couldn’t resist inciting my colleagues and readers to have a glance at it. Enjoy!

P.S. My apologies to my purist friends from any inaccuracy I’ve made for the sake of simplicity (and to the excuse of my ignorance :-).