Older blog entries for nuncanada (starting at number 17)

Have put a stop on programming for a while. Dropped out of the math course, so i am studying to get in the Computer Science course. Here in Brazil, the best courses are on public universties which are non-paid, and so there is a lot of competition to get in them.

Been doing good on tests, will pass without much problems... But i want to keep studying to see how well i am able to do...

Look how our social systems evolve, a common feature is the increase of 'Separation of Concerns'.

Programming is much more of a 'social problem' than a mathematical one. Programming needs to evolve towards a bigger separation of concerns...

Movies i liked the most till now:

- Gattaca - Dark City - The Cube - Memento - Run, Lola, Run - Muholland Drive - Matrix I - Forrest Gump

10 Mar 2004 (updated 24 Mar 2004 at 23:43 UTC) »

It's the first book that my father said i should read which i've been able to read to the end: 'Zen and the Art of Motorcycle Maintenance' by Robert M. Pirsig.

I won't even bother reading any book my father recommends now on. It's just that he's 'an artist while i am a mechanic'. ;) We've completely different book tastes.

I guess the only non-technical/scientific books i really like are those which make me forget human reality... Authors like Douglas Adams, Neil Gaiman and Tony Vigorito...

29 Feb 2004 (updated 29 Feb 2004 at 19:04 UTC) »
Exceptions: A seemingly good idea that works worst than its predecessors

If you have pretty 'linear' code, exceptions might be a good solution to lessen the quantity of error handling code. Maybe when making a library that is the case... Still for most real programming out there, it is about reusing diverse components, lots of interrelationship between you code.

From experience, when trying to use lots of decoupled parts which call up each other without a previous knowledge of the paths, you will have to catch exception as close as possible to the problem.

This makes it worst than using simple return statements for errors....

I am not the only one...

Congratulations to John Cox (niceguyeddie)
Xaraya's Leader got a very deserved interview on php|architect commenting on the (in?)famous nukes past and future.

About me:
I dropped off from my math undergraduate course missing 5 classes to finish, couldnt stand the lack of purposefulnes, and the boring differential equations classes were the finnishing incentive i needed.
I really like puzzles, but i dont see much point in math as a job, it would be like a being a professional chess player... It's interesting, but what's the point?
Worth, computers are soon going to be the best chess players around and not that latter will also be the best mathematicians...

Code doesnt want only to be open, it wants to be modular.

Open Source Movement is missing better tools to allow code reuse. We have been mostly trying to copy what's out there in closed source. In the closed source environment, core reuse is a secondary problem, while it's crucial when you have open source.

Right now languages seems to be heading towards problem area specialization (perl, php, prolog...). That's one way to quickly advance into the given area, still wouldnt be better if all area specific languages were just local dialects of a mother language?

Some interoperation between languages is going on between php/java, this has also existed with c/with almost anything. This seems a trend to divide work between languages, so you can use the best tool for each particular job.

I think this is the future of programming. The usual saying 'Use the best tool for each job' will meant more than it did before. Where we will have problems segments being solved by different languages.

Now that comes the part about code being modular: if the particular problem local language is 'simple' enough so that its programs can be trivially be evaluated to equivalence classes then this 'i think my way is best' attitude will be overthrown. The problem is constructing such languages/a mother tongue compiler...

I kept reading papers about Open Source, 'The Political Economy of Open Source Software' explained to me what i was thinking (or i think i was) about oss being more than gift economies, besides a lot of other subjects over oss motivations, organization etc. It's an awesome paper, the best i have read so far about general oss economics.

Reading it makes me think that all 'infrastructure' software sooner or later will be oss, the possibility of commercial profit will remain only on suprastructure (especialized or niche) software...

Researching upon Open Source, i found something that seems important to understanding it but is left in the locker room by the linux zealots:


Innovation? New? No, it's just another copy of the same old stuff.

OLD stuff.

Compare program development on Linux with Microsoft Visual Studio or one of the IBM Java/web toolkits. Linux's success may indeed be the single strongest argument for my thesis: The excitement generated by a clone of a decadesold operating system demonstrates the void that the systems software research community has failed to fill.

Besides, Linux's cleverness is not in the software, but in the development model, hardly a triumph of academic CS (especially software engineering) by any measure.

from System Research is Irrelevant by Rob Pike

20 Oct 2003 (updated 20 Oct 2003 at 23:13 UTC) »

Success in Open Source: Technical or Social Merits?

The open source community regards itself as a 'meritocracy', a system where status is based on merits. But what kind of merits? Technical? Between two competing open-source projects, which one is expected to 'survive', the one with most features, or the one better designed?

PHP-Nuke's still deep roots among the user base seems to imply better architecture is not that important. Its competitors, Postnuke and Xoops, are better designed (and soon to appear Xaraya, even more imo) but still doesnt seem to have reach the number of Google indexed pages (how to compare user bases in open source software? Can we trust download statistics?). One of the possible reasons for that could be that the user base consists mainly of non-programmers which can't evaluate the code base.

But another example seems to imply that is not the case: Open Source Java Object/Relational Persistency Libraries: OJB vs Hibernate

In many comments ( 1, 2), the dispute is portrait as OJB being the design guided (which might make it less practical) and Hibernate the functionality driven, popular library.

One of the outstanding features of OJB is its Criteria API, it provides a clean abstraction to SQL-like queries in contrast to Hibernate SQL alike: HQL...

If developers were really interested (and informed) in the technical matter of which is the best way to abstract SQL, they would choose OJB's approach instead of Hibernate's. Still Hibernate is more popular, and recently implemented the Criteria API too.

Although i am tackling about a particular issue among the many ones for Object/Relations Persistency Libraries (the one i know most about), i believe it to be more or less how the rest works, given the very different philosophy behind the projects:

Hibernate's "What matters is delivering useful functionality in a timely manner" and OJB's dedication to design principles.

Regarding the question asked by myself, i do believe Hibernate has the better approach towards a succesful open source project (social merits)!

The problem with this approach is that usually later the addition of certain functionality gets impossible or too human resource intensive to be feasible, obligating architectural changes (*Nukes). Once down that road, there are 2 options:

To keep adding just the functionality you are able to or to make the architectural changes which might reduce the functionality you have until you are able old stuff comply with the new system, makes it counter-productive to add new features as these may have to be redone, steal time away from adding feature towards remaking the architecture (which might take a long time). And in case of libraries/frameworks it might alienate the user base if the supported API is going to change.

A successful project would need to deal with this phase very well once it is needed.

8 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!