Posts Tagged ‘Philosophy’

Quote of the Day

Sunday, November 30th, 2008

There are phenomena in the universe that are explainable only by means of specific models, or approaches, and not by any other means. nature has many different aspects and is not a single reality; at least the human mind cannot comprehend everything at once using a single model.

- Christopher Alexander in The Nature of Order, Vol. 4

Demoscene, IRC and Old-School

Monday, November 24th, 2008

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 80386s with little more than 1 or 2MB of RAM memory. Those where the days of MOD and S3M, Music Trackers, where several musical artists have begun they carrier using these tools. 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 wish I weren’t 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 we were much, MUCH more social back then. I’ve met dozens of new people, held dozens of parties, engaged in several projects at such an young age, because of BBSs and MOOs and IRCs. Fooled are those who thought we were anti-social creatures hidden behind a computer. Most of us even had to use public transportation and travel several miles during hours, so young we were, and yet, dozens of new people we’ve met.

But now, now that the ability to communicate is order of magnitudes larger than it were back then, where is the socialization? What “mystical aura” was present in those forms of communication that is, somehow, lost? How can we revive it again? Will it be ever possible?

On Patterns…

Thursday, November 20th, 2008

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. 

Linda Rising, in the last PLoP conference, said something along these lines: “A pattern shouldn’t be an Ahah! or Eureka! but something more like an Hmmmm!”. 

The thing is, a pattern is something recurrently seen in the wild, that try to give an answer to a problem by balancing the forces in some particular way. Not an intelligently crafted solution in the author’s basement. A good pattern is one where a domain expert is able to easily recognize the pattern 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 observed those patterns in a particular context, and while they may hold outside that context, 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.

Furthermore, as an example, Ralph Johnson, during the last PLoP workshop, suggested that the patterns I wrote could be generalized far beyond Adaptive Object-Models and into a broader OO perspective. However, that 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 it’s own context and forces. For that purpose, I may actually have given too little detail, since several comments I received asked for more in that direction!

Alexander’s work is a great example of what I’m trying to say. The Notes on the Synthesis of Form could, and are easily abstracted into several realms far beyond Architecture. Should we state that Alexander coupled himself into unnecessary detail?

I believe the problem may not be 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! Maybe that’s 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, almost empirical, observed knowledge.

Another Quote of the Day

Saturday, November 15th, 2008

The reason that iron filings placed in a magnetic field exhibit a pattern - have form - is that the field they are in is not homogeneous…

- Christopher Alexander, Notes on the Synthesis of Form

Quote of the Day

Saturday, November 15th, 2008

(…) there are two ways of constructing a software design. One way is to make it so simple there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

 – Tony Hoare [Turing Award Lecture, 1980]

A Pattern Language for Hopeless Argumentation

Sunday, November 9th, 2008

In the spirit of the do the right thing, I hereby release my latest project on pattern languages to the public. Enjoy :)

Proof of God

Tuesday, September 30th, 2008

I’m getting sick and tired of people discussing religion and invoking the need to prove, or disprove, the existence of God. This is the kind of argument that makes me stop the conversation, for ever. Actually, I’ve started to take a simple approach before incurring in a largely, perhaps irrelevant, rumination about religion:

a. I am willing to change my opinion. Do you?
b. 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?
c. 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, potentially leading to a nice, though inconclusive, conversation.

N.B. Also please take into consideration that things like “God loves us all, even Atheists” are as racist as “God loves us all, even black people”. I would go nuts when I hear the later, so I definitely go nuts whenever I hear the former. There.. Now flame me…

Internet may become sentient?

Tuesday, September 16th, 2008

Another option is the idea of the net itself becoming sentient, a vast self-modifying array of connections and information storage with limited connections to the outside world (kind of like that glob of grey goo you carry around in your skull).  If that happens then Gibson help us all - remember that the net is made of about 90% spam, 9% porn, and quite a lot of whining blogs.  If that mixture ever becomes self-aware we’re not quite sure what it’ll do, but the odds are against it being anything good.

Simply Hilarious! You can find the full article here.

All this thing about LHC…

Thursday, September 11th, 2008

… made me remind something Carl Sagan said, and which I’ve previously posted:

“We are star stuff which has taken its destiny into its own hands.”

- Carl Sagan in Cosmos

Thought of the Day

Wednesday, March 5th, 2008

“We are star stuff which has taken its destiny into its own hands.”

- Carl Sagan in Cosmos

Quando ainda tinha algo semelhante a uma vida…

Thursday, January 24th, 2008

… ia divagando um pouco. Agora não consigo escrever nada sem me perguntar: “Mas o que é que isto adiciona ao estado da arte???”

“Será sábio aquele que, como Socrates,
sabe que a sua sabedoria é pouca?”

Que enigma esse o da filosofia!
Que peculiar modo de vida,
Que caprichosa religião!
Dedicar a vida ao sofrimento,
Por tanto amar a verdade e o conhecimento.

Serão a esses seres permitidos tais devaneios,
Que subtilmente separam o fantástico da loucura?
Ou estarão eles condenados à eterna caminhada,
Pela ténue linha entre a verdade e a ilusão?

Serão apenas os seus destinos uma vã busca,
Do equilibrio sobre os penhascos da realidade?
Ou o nobre fardo de manter a chama acesa,
Para guiar sociedades e gerações.

Oh conhecimento, a que me obrigas,
Para no fim, não passares de um reflexo,
E assim levares tais seres a procurar
Para sempre o outro lado do espelho.

O Mestre da Retórica

Saturday, November 3rd, 2007

“Quem deseja ter razão de certo a terá pelo simples facto de possuir língua”

Goethe

Why learning Haskell/Python makes you a worse programmer?

Thursday, August 2nd, 2007

Recently, I’ve been having a lot of conversations with a friend of mine about meta-programming, partly due to some development we are working on, and partly due to our coming PhD. Some of the time we incur in largely (perhaps irrelevant) philosophical ruminations about programming languages.

But today, he found a rather peculiar blog-post, where the author teases the readers arguing “Why learning Haskell/Python makes you a worse programmer”.

Why learning Haskell/Python makes you a worse programmer?

The author presents two claims to defend his thesis: a) Demotivation and b) Code Obfuscation. Considering demotivation, he states that he “(…) constantly find (himself) wanting to use idioms from these languages, or noticing how much less code (he would) be able to write if (he) was using one of these languages (…)”. Further, it notes that it finds “(…) C# code very ugly compared to both Python and Haskell (…)”. The conclusion, he remarks, “is to make me very depressed and demoralised. I feel like a human compiler, translating the Haskell or Python in my head into a language which is a whole level lower.”

In what comes to code obfuscation, the author believes that because “C# has begun to get some features that are more friendly to functional style programming”, the programmer “when faced with a very common situation” tends to try a “functional solution”. Adapting this “functional solution” to a language like C#, results in “writing such complex code — using such advanced features as anonymous delegates — when a simple loop would have sufficed”. The overall conclusion is “don’t bother improving yourself, unless you have the freedom to improve your environment accordingly.”

While I tend to sympathize with the author frustrations, I believe this to be a classic example of misunderstanding about programming paradigms and languages. In fact I’ll try to summarize my arguments on “Why learning Haskell/Python makes you a *better* programmer”.

The difference between Paradigm and Syntax

First and foremost one must understand the difference between paradigm and syntax. Each different paradigm usually results in a different algorithm. Though, the same algorithm can be expressed in different syntaxes, which depends on the language one’s using to implement. The fact that a certain syntax is less ugly to a programmer implementing a certain algorithm designed in a certain paradigm qualifies the expressiveness of a language. This expressiveness is dependent on the domain’s problem and the paradigm of the solution, so different algorithms (that solve the same problem) can make the same language seem very beautiful or very ugly.

Expressiveness in Programming Languages

A common metric used to quantify the expressiveness of a language is the number of code lines needed to implement a certain algorithm. It is very common to find advocates of every language, using as arguments single-liners to convince that her/his language is the best: “just compare this one-line quick-sort implementation in X to this 30 line implementation in Y”. This makes the reader believe that X is more expressive than Y, while not noticing that the algorithm paradigm used for X is the same as the native paradigm of X, while the opposite isn’t always true (e.g. see [1] [2] and [3]).

The “other side”

It’s also amusing to see many people learning functional languages, believing they are the other side, and putting C and C# (or Java) in the same bag. Why this happens? Because people tend to learn syntaxes and not paradigms. If a language has a syntax very close to another (like C, C++ and C#), they tend to believe that the paradigm is the same. Even worse, because they find that a certain syntax in a certain language produces expressive code, they incur in the pitfall of trying to apply the same paradigm in a different language (and, surprise! that language wasn’t designed to be expressive in that paradigm). I’ve seen this problem occur over and over, especially in people that already have some programming experience; how many times I’ve seen code written in Java which is plain old C in another syntax?… These authors don’t have a clue what Object-Oriented is all about, and I doubt they also have a clue what Functional Programming or Logic Programming is about too (somehow, Prolog and the Logic Paradigm tends to be forgotten).

Which is the best?

What is the solution? In portuguese we say “Cada macaco no seu galho”, which losely translates to “To each its own”. One must understand that there are several forces to be taken account when choosing a certain language to implement a desired solution. Most of the time this are related to infrastructure features (like available frameworks and tools). But an important force (most of the time marginalized) is related to the problem’s domain; I would argue that functional languages are very expressive in what comes to mathematical defined algorithms and that I would definitely choose C to implement a device-driver (don’t confuse the choice of expressiveness with performance) and SQL to define relational queries.

The author’s mistake, in my point of view, is trying to force-fit a solution in a paradigm that is not natural to the language in question (for the author’s sake, I know that he knows this, but not everyone understand this). Just because a language has the infrastructure to deal with certain paradigms (like C# 2.0 new functional-oriented features), this doesn’t mean the necessary syntax is there to make it expressive in that same paradigm; “while in Rome be Roman”.

What can we do?

One solution for the problem of expressiveness are Domain Specific Languages (DSL). DSLs try to solve this by extending/redefining the original syntax and semantic of a language to better express solutions designed for paradigms more closely related to the problem’s domain (consider LINQ and mathematical sets) while maintaining the concepts horizontal between syntaxes (which differ from scripting or embedded interpreters). DSLs aren’t just syntactic sugar (I will argue about this on a different post).

Why learning Haskell/Python makes you a better programmer?

So why does learning other languages (especially languages that implement other paradigms) makes you a better programmer? a) Because it teaches you different points of view and b) because it gives you the best syntax and semantic for a certain domain. Learning different languages don’t necessarily make you better in other languages. It makes you better in understanding and designing new algorithms, though. But most important, it should make you feel more decoupled from implementation details and more detached from syntax.

There is an analogy that I like to apply when people ask “Is it worth it?”. Scott Ambler, in his book The Object Primer, talks about the difference between the Specialist and the Generalist. He argues that while a specialist is a “Jack-of-all-trades and a master of none”, good developers should try to be generalists, as in a “Jack-of-all-trades and a master of few”.

Smallest possible universal Turing machine

Monday, June 4th, 2007

Stephen Wolfram, creator of Mathematica and author of the idiosyncratic book A New Kind of Science, has offered a prize of $25.000 (18 598€) to whomever proves (or disproves) the universality of a 2,3 (2 states and 3 colors) cellular automata.

This fact (once proven) would show that even with an extremely reduced set of rules/states it is possible to achieve Computational Universality.

Personally, I believe that the probability of such a small set to randomly occur in nature could be surprisingly high, pointing that simple organisms and even physical phenomena capable of Computational Universality, more than just the mere result of chance, can be the product of an universal inevitability.

Thougt of the Day

Saturday, February 3rd, 2007

“I do not consider it an insult, but rather a compliment to be called an agnostic. I do not pretend to know where many ignorant men are sure — that is all that agnosticism means.”

Clarence Darrow

Google Trends: What the world is searching for

Tuesday, October 17th, 2006

Excelent essay by my friend Paulo Cunha on the statistical analysis of searched keywords by several countries. A *must* see!

Thought of the day

Thursday, October 12th, 2006

“Excellence does not require perfection.”

Henry James

How to start an opinion…

Monday, October 9th, 2006

“At the risk of veering into a largely irrelevant philosophical rumination on the ontological significance of (…), I feel inclined to point out that (…)”

The Call of Cthulhu

Tuesday, July 18th, 2006

“The most merciful thing in the world, I think, is the inability of the human mind to correlate all its contents. We live on a placid island of ignorance in the midst of black seas of infinity, and it was not meant that we should voyage far. The sciences, each straining in its own direction, have hitherto harmed us little; but some day the piecing together of dissociated knowledge will open up such terrifying vistas of reality, and of our frightful position therein, that we shall either go mad from the revelation or flee from the deadly light into the peace and safety of a new dark age.”

H.P. Lovecraft

The Art of Programming

Friday, June 2nd, 2006

“Despite its transparency, as Bjarne Stroustrup has observed, “our civilization runs on software.” It is therefore a tremendous privilege as well as a deep responsibility to be a software developer. It is a privilege because what we do collectively as an industry has changed and will continue to change the world. It is a responsibility because the world in turn relies on the products of our labor in so many ways. In the context of that labor, software is perhaps the ultimate building material: it springs from pure thought and is intrinsically malleable, yet it can be made manifest in our hardware systems, limited only by our vision (and certain immutable laws of physics and software). As software professionals, we seek to develop and deploy useful systems of quality in a manner that reduces the distance from vision to execution. That the fruits of our labor are transparent to the world is as it should be: users want results and value, not more technology. For this reason, the primary challenge of every software development team is to engineer the illusion of simplicity in the face of essential complexity.”

Taken from http://www.booch.com/architecture/index.jsp