Reflective Surface
Still powered by a contradiction in terms
Archive for Software Development
May 2, 2008 at 12:04 pm · Filed under Seaside, Software Development
During FISL, I had the opportunity to watch Randal L. Schwartz talk about Seaside. Schwartz is very well known in many open source communities–especially in the Perl one–and now is evangelizing Smalltalk and Seaside. I asked him if we could talk a bit about the subject, given my previous interest in the field, and he graciously agreed to an interview.
Without further ado, here’s what we talked about:
- Tell us a bit about you: what’s your background, how did you started programming, what are you doing today?
-
I taught myself programming when I was 9. By the time I was 15, I was
teaching programming from the front of the room to my classmates, and writing
contract code on the weekends for real money.
I worked for three different companies for a total of eight years, before
starting Stonehenge in 1985. Stonehenge has grown over the years: we’ve
can count 17 of the Fortune 100 Companies as our clients.
I spend a lot of my time lecturing and writing these days, but I also still
design, create, and review code as well. I answer questions for free for
about an hour or two each day on the dozens of mailing lists and blogs and web
communities I frequent.
- You are extremely famous in the Perl community, but now you are
strongly advocating Smalltalk/Seaside. What did change? When did you
start using Smalltalk?
I started using Smalltalk before Perl was even invented, back in 1982. I’ve
already written that story up at my blog.
- What are Smalltalk advantages over other traditional languages like Perl,
Ruby or Python, for example?
-
Smalltalk has a very simple syntax: I can teach the entire syntax in about 20
minutes, and include it as part of my talk introducing people to Seaside.
The major Smalltalk implementations (except GNU Smalltalk) also
have a mature IDE, allowing easy exploration of code relationships, and to
learn the libraries as needed by looking at both the implementation and the
uses.
And that’s a bonus as well: we have two commercial smalltalks (Cincom and
GemStone/S) as well as two open smalltalks (Squeak and GNU Smalltalk) all
supporting Seaside. This allows a nervous manager who might be hesitant at
selecting a strictly “volunteer-based” language to also have two commercial
vendors to pick up support. Options are good!
- Do you believe Smalltalk will finally reach mainstream status?
-
Well, it *had* mainstream status in the mid 90s, just before Java entered, at
least with large Wall Street firms and other institutions who wanted rapid GUI
development to stay ahead.
But yes, I believe Smalltalk is positioned today to reenter as a major
player. For details, see my “Year of Smalltalk” post.
- Also, your talk was entitled, “Seaside: Your Next Web Framework”.
What is really interesting about Seaside?
-
I like how Seaside can abstract both control flow (along one axis) and
representation (along the other axis) with relative ease. Seaside seems to
put the right related things near each other. I also like the “debug the
broken webhit within the webhit”: when something blows up, I can explore in
the standard debugger, fix what’s broken, patch up any mess, and then continue
within the same web hit, as if nothing broke.
Also, the traditional Rails persistence is provided with Active Record, which
requires objects to go through an object-relational mapper to drive SQL
queries. Seaside can do the same thing (via GLORP), but a better solution is
to avoid the mapping entirely, using things like the open source Magma
solution, or the commercial GemStone/S Virtual Machine. When you can get rid
of the ORM layer, you get a lot of speed back, and a much easier programming
environment.
- What do you see in Seaside’s future, and how does it compare to the
future of the other frameworks?
The Seaside team is currently refactoring and repackaging Seaside so that
portability will be easier to manage and so that you can pull in just
the parts that you need. I also see a lot of bolt-ons being created, like
the Pier CMS and adaptors for various APIs such as Google Graphs.
- Do you think the market is ready for Seaside?
Yes. Ruby on Rails reopened the discussions about what to do in a post-Java
world, by going back to the late-binding languages like Perl and Python and
Smalltalk. And Seaside is a mature framework, being even older than Rails,
but just not as well known. I’m hoping to change that.
- Have you deployed anything using Seaside? If so, what were the
challenges?
I’m working on a few projects now, but nothing is public yet. The initial
challenge was the relative lack of documentation, so I spent the better part
of two days going through every posting to the Seaside mailing list. I feel
much better informed now, but my eyes were pretty bleary. I hope to repackage
the knowledge I gained into postings to my blog as well as helping to answer
questions on the IRC channel and mailing list.
- You are now part of the Squeak Foundation Board. What are your
plans for the Foundation?
My primary concerns are licensing issues, release management, and proper
publicity. All of these issues are being addressed, but of course, we’re all
volunteers and always looking for more qualified volunteers to help.
- Are there any Squeak Foundation plans for Seaside?
Nothing formal that I’m aware of. However, Squeak is the primary development
platform for Seaside, so we’re sure that Squeak will remain an essential
component.
- What are the most promising developments in the Smalltalk/Seaside
world currently?
-
Well, what got me involved is GLASS, the GemStone/Linux/Apache/Seaside/Squeak
solution to get people up and running with Seaside quickly. This also
entailed the GemStone management creating a zero-cost commercial license for a
fully functional (but limited) version of GemStone/S. With this free version
of GemStone/S, you can build a business, and when your business exceeds the
capabilities, there are strategies about migrating to larger licenses that are
reasonable. It’s a great solution for getting a rock-solid
commercially-supported Smalltalk VM with persistence and clustering into your
plans.
- What about next year’s FISL. How did you manage to get three entire
days for Smalltalk?
As I said, “it all started over a couple of Caipirinhas…”
- What are your plans for those three days? Do you plan to bring
other Smalltalkers?
I will be working with the FISL organizers and the various vendors and groups
of the Smalltalk community to produce a full mini-conference. I hope to have
both beginning and advanced Smalltalk training, as well as various Seaside
tutorials. I expect this conference will attract a significant number of
Smalltalk developers to FISL for the first time, as well as expose Smalltalk
to the remainder of FISL, so it’s a win for everybody.
Many thanks, Mr. Schwartz, for the interview.
March 3, 2008 at 8:28 am · Filed under Funny / Weird, Software Development
Arc’s Out:
Arc is still a work in progress. We’ve done little more than take a snapshot of the code and put it online.
I’ve working on this for a long, long time and realized I’ll never get it done properly so I’ll release it anyway.
Why release it now? Because, as I suddenly realized a couple months ago, it’s good enough.
It’s shit but I’m famous enough that people will be talking about it for a long time. People will think it’s good even if it’s really just a bunch of macros on top of Scheme.
I worry about releasing it, because I don’t want there to be forces pushing the language to stop changing.
I’m not going to change it, but if you idiot enought to want to use it, remember that there’s not documention. In other words, don’t call me if you can understand a single line of the code.
Which is why, incidentally, Arc only supports Ascii. MzScheme, which the current version of Arc compiles to, has some more advanced plan for dealing with characters. (…) But the kind of people who would be offended by that wouldn’t like Arc anyway.
I don’t understand and don’t care for any other character set other than my precious ASCII. I learned it forty years ago and I’m not giving it up now. No way. Ah, that why Yahoo! completely rewrote the application I sold them. Bunch of losers.
Why? Because Arc is tuned for exploratory programming, and the W3C-approved way of doing things represents the opposite spirit.
Also, I don’t understand anything about new and modern standards and technologies like XHTML and CSS. And I’m not waste my precious VC time learning them. And I don’t care about you people who dare to make the Web less complicated. Did I mention why Yahoo! had to rewrite the program they bought from me?
Tables are the lists of html. The W3C doesn’t like you to use tables to do more than display tabular data because then it’s unclear what a table cell means.
I told you. I don’t understand anything about HTML.
So experience suggests we should embrace dirtiness. Or at least some forms of it; in other ways, the best quick-and-dirty programs are usually quite clean.
Look! A dumpster! Let’s have some fun!
Arc tries to be a language that’s dirty in the right ways. It tries not to forbid things, for example. (…) For now, best to say it’s a quick and dirty language for writing quick and dirty programs.
I lost so much time with this shit that the world should share my pain. Basic, watch yourself. It’s Arc time! Agora é a vez do Arc.
February 14, 2008 at 3:28 pm · Filed under Seaside, Software Development
To those curious about the way Seaside applications are structured or just looking for a simple example to see how they differ from the other more usual Web frameworks, I’m making available the code of a simple experiment of mine: a small system to keep information about the books I’m reading, have read or intend to read.
For the remote possibility somebody asks about this, the system is inspired and modeled after Caffo’s bookshelf. Of course, his system is prettier–and faster too, at the moment.
Some caveats about the code:
- It’s running on a very old and underpowered server.
- This is an alpha version so don’t expect subtleties in the code. I’m still learning Seaside, and migrating from 2.6 to 2.8 proved an interesting exercise.
- The application depends on an instance of [GOODS]. The connection data for the instance can be configured in the application settings.
- The login is a beautiful example of how things should not be done. I started with a normal login system, got lazy in the process, and adapted it to allow just one user to log. The user can be configured in the application settings as well.
- I’m not using any deployment optimizations. Everything is in memory, and thumbnails are generated on the fly.
- The code is Squeak-specific.
That said, the system shows how a Seaside application runs, and how Magritte can be used to model data. It’s enough to show how Seaside is different from any other of the usual Web frameworks in use today.
The code can be found below:
While the code will run in any Squeak 3.9 image, I recommend Damien Cassou’s Squeak-Web image. With his latest image, it’s just a matter of loading GOODS and the code to begin development. GOODS configuration, of course, is left as an exercise to the reader.
February 7, 2008 at 1:11 pm · Filed under Software Development
Recently, somebody recommended me to take a look at Software Craftsmanship, by Pete McBreen, as a good treatment of software engineering versus software craftsmanship as approaches for software development.
The theme is indeed interesting, but I was surprised to see how badly the book is written. McBreen, granted, does a decent job of presenting the main arguments for both sides–which is more than you would expect from a proponent of a specific approach–but he also repeats those same arguments endlessly. I don’t know how an editor managed to let something like that happen, but if the incessant repetition were to be eliminated the book would lose at least three quarters of its almost three hundred pages.
McBreen’s argument is simple: Software engineering is appropriate only for huge projects (those is the 100 developer-years and above). For simple projects, needing faster development and no critical hardware infrastructure, the old concept of craftsmanship is much more interesting: a master craftsman running a team of journeyman and apprentices.
I agree with the arguments and many of the other conclusions presented my McBreen. In fact, to the extent I’m concerned, that’s exactly the way I’ve been running my own small company. The results, so far, have been excellent.
Mane people reading the book, however, will quickly give up after reading two or three entire chapters essentially saying the same thing. They won’t look kindly also, to statements like the one below:
Software craftsmanship is the new imperative because many members of the software development community are stating to chase technology for its own sake, forgetting what is important.
The fact that the second part of that sentence is painfully obvious and that the relationship between the first and second part is clearly a non-sequitur doesn’t seem to bother McBreen, tough.
Nevertheless, much of what McBreen is talking about is valid and necessary, as when he describes how good enough software is not really good to users or the industry. Some of this analysis of the prevalent (and wrong) metaphors–like car building versus car design–were interesting enough to motivate me to finish the book.
Ultimately, the book is necessary and part of one of the most important debates taking place today in the industry. I’m afraid, however, that many readers will abandon the book after a couple chapters after being put off by McBreen’s redundant style. More’s the pity because a good editor would made the book the new Peopleware.
January 18, 2008 at 1:51 am · Filed under Software Development, Web
In the past few days I have been thinking about the future of development–especially about the growing interest in tests and domain specific languages, and about the new trends in Web development. I was surprise to realize that, despite the fact the much talking has been done about how they may revolutionize the field, no significant application or framework is combining those concepts in something truly new.
The historic of the field is abysmal. We are now forty years into a period of very few changes in the conceptual basis of software development. For twenty years we have been using basically the same tools, practicing the same moves, and not moving are all. The industry remains bound to the minefield of object oriented programming, relational databases, and bottom-up design.
With regards to Web development, for example, although innovative in many ways, Rails and Django share two flaws that will make them obsolete as quickly as the other many frameworks that have graced the field in the last decade.
The first flaw is conceptual fragmentation. In an attempt to make Web development “painless”, those two frameworks and their descendants have diluted the way the application domain is considered in the application. It’s a more manageable–dumbed-down, if you will, way to develop application but the disconnection between code and domain is fairly evident.
The second flaw is the fixation of opinionated solutions. The use of REST by Rails is a good example of this kind of fixation. REST is a very useful concept, even necessary for some applications, but Rails half-baked external solution, full of accessory tricks, is sub-optimal. But Rails developers are sticking to it without questioning what it represents for their applications because Rails is opinionated software.
In fact, many of those so-called modern frameworks are just pretending complexity does not exist or that they can be easily managed by the use of small methods and a couple of tests.
Test-driven development is now being considered a silver bullet. New developers are using it as a panacea–as a way to guide design as if it would be possible to analyze the problem domain of the application by peering at the small window offered by TDD. The enormous amount of examples showing how to test what has been already tested is quite insane.
Seaside, which I tend to defend as a next step in Web development because of its innovative application of old concepts and its refusal to submit to the common solutions, is not the full solution though. Is great, it’s necessary, but it is still a step below what we really need.
Hopefully, the interest in concepts like language oriented programming will invite attempts to solve the Web development problem is new ways that will transform the field until the next revolution is needed.
Maybe we need a way to generate executable specifications that will really a way to build applications, and not a inferior way to model the expected behavior of an application. Maybe that can be a New-Year resolution: to think of a way to connect the dots, to join the loose treads created in the past twenty years. Is anybody up to it?
January 15, 2008 at 10:31 am · Filed under Software Development
I’m reading Blink, by Malcolm Gladwell, which is about the ability to arrive at correct decisions from minimal information–in other words, in a instinctive or intuitive way. I’ll write more about the book later, by I’ve been thinking about Gladwell’s argument and how it would apply in the field of software development.
What occurred to me is that experienced programmers are able to the make the same kind of instantaneous judgments, especially when they are debugging a program. I can remember countless occasions in my programming career when the simple act of looking at the code, without even trying to read in detail what was written, would generate a clear picture of what was wrong with that specific part of the application.
I think any other programmer would be able to say the same. That ability seems to be a mix of general programming knowledge and specific application knowledge. And the longer you program, the better you will be at spotting problems in the presumed function and structure of the code. It doesn’t matter if the problem is simple–duplicate rows because of a missing join statement, for example–or complex–subtle behavior problems in the application because of slightly changed configuration parameters.
It’s interesting to compare the behavior of two differently experienced programmers. Curiously, I have been doing something like that for a while, even before I started to read the book, and I think Gladwell is quite right here. I don’t agree with many of his arguments in the book, but the basic relationship between expertise and intuition is something we often miss.
The converse is also interesting, the times when instinct fails. That may cause a programmer to spend hours looking for a ridiculously small problem–a wrong letter in a protocol definition that will prevent the entire program from working and a misleading error message. The fact the this kind of problem can be solved by falling back (taking some time away from the problem or using a second opinion) indicates that the mechanism is, to a certain extent, resettable.
Anyway, it’s quite interesting to think about the way our mind works and the ability it has to make those instantaneous comparisons and classifications.
January 11, 2008 at 11:28 pm · Filed under Software Development
The equivalence between elegance, beauty and correction is almost an axiom in the field of mathematics. Bertrand Russell expresses this correlation thus:
Mathematics, rightly viewed, possesses not only truth, but supreme beauty–a beauty cold and austere, like that of sculpture, without appeal to any part of our weaker nature, without the gorgeous trappings of painting or music, yet sublimely pure, and capable of a stern perfection such as only the greatest art can show. The true spirit of delight, the exaltation, the sense of being more than Man, which is the touchstone of the highest excellence, is to be found in mathematics as surely as poetry.
— Bertrand Russel, The Study of Mathematics
Code, once we consider its mathematical roots, presents the same intrinsic correlation. Although it is too much mutable to evoke the cold and austere beauty to which Russell alludes, the fact that code and its other products exhibits the same aesthetic imperatives is obvious even to the most inexperienced programmers. Even users can occasionally apprehend those aspects of code when they talk about the way a given application works and how functional and usable it is.
Most of that elegance derives from the incremental economy one can achieve by successively refining a body of code. The author of The Little Prince describes those steps with the following words:
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
— Antoine de Saint Exupéry, Terre des Hommes
Exupéry criterion is an excellent validation tool for what code should be–and by extension, any of its products–in its final form. There is beauty and perfection to be found in code, to borrow Russell words, as surely as there is beauty and perfection in the most cherished poems.
To the intelect of programmers, this beauty is visually clear in what they product, easily expressed in the successive reductions they can perform to achieve a core of functionality that will stand the test of time. Obviously, that perfection depends both on the programmer and the tools he chooses to employ, but it’s available to any practitioner of the craft willing to make the effort to become a master craftsman. As another great programmer said:
Ugly programs are like ugly suspension bridges: they’re much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code.
— Eric S. Raymond
Being a function of a developed sense of programming, I believe it’s possible to purposefully chose to code beautifully. It’s a matter of time and options, something about every programmer should think regularly in the course of his career. Training oneself to recognize beauty may seem far fetched, considering that reading code is much harder than writing it, but that may be the key to the task: beautiful code will be much more readable than ugly code, and that will help programmers to identify and recognize good code.
Ultimately, the challenge of every programmers is to learn to code elegance, teaching himself or herself to recognize code that meets standards of concision, simplicity and beauty–which brings us to another quotation:
Simplicity carried to the extreme becomes elegance.
— Jon Franklin
My advice to those who are beginning their programming careers and also to those who are feeling that their code is becoming bloated and unwieldy is this: train yourself to code in a way that will show the problem solving intent of each line, and that your code is the best way to solve the problem at hand.
In less time than you will realize, elegance will be second nature to you, with all benefits it brings. It’s hard work, but worth it.
January 6, 2008 at 10:52 am · Filed under Software Development, Web
Tim Bray began his predictions for 2008 saying that this is the decisive year for RIA applications: either they become mainstream or they will be relegated to the dust bin of history. Given the news about Microsoft planning to overhaul its entire site to show their RIA platform, Tim Bray is probably right in saying this will be a important year for RIA technologies.
Bray makes an interesting point when he says that he tends to associated “richness” not with interface–which, he also says, is something only developers care about–but with the interactive capabilities of applications, regardless of the technology they use. I agree, but I also think that Silverlight and Flex (and similar technologies) may have a useful role in a different place, providing different levels of interface in a very specific class of applications: internal sites.
Obviously, Microsoft and Adobe are setting their sights much higher than that. The former with its pathological need to control the industry; the latter, with its duplicity about open sourcing its products. I’m not worried. Public facing applications have different interaction and accessibility needs, and no developer is going to use technologies that will actively harm their applications on those two areas. One of the main problems plaguing alternative interfaces is that they are always trying to catch up with what users have grown used to and they can never succeed. Between dealing with the cognitive dissonance they force users to experience and dealing with multiple hosting system, they don’t have the leverage to compete with the advances being made in JavaScript integration.
Another interesting point Tim Bray makes is that most applications are Web-enabled to some extent–even if users don’t realize it. Add that to the growing research in offline/online integration and we are dealing with an entirely different playing field.
Contrary to Bray, I will risk a definitive prediction: RIA, with regards to Flex and Silverlight, will indeed be recognized as a secondary option this year, and no big applications–Microsoft site notwithstanding–will be launched using either technology. Conversely, we will see people using Silverlight or Flex in internal applications.
The rest of the year, however, will belong to Ajax.
January 5, 2008 at 10:52 am · Filed under Software Development
I guess I can safely say that most programmers consider testing is an essential part of the software development process–even those who are not using any format framework right now beyond following a prepared script about what should be tested and how it should be tested.
Ironically, the parallel ascension of Web applications as the preferred form of modern user interfaces and agile methodologies as a more efficient alternative to the usual coding creation systematics offered a unique opportunity to experimentation in the testing arena. Web applications are usually easier to test because you can automate most of the testing. Since they are not event-driven but based on linear protocols, testing Web applications can be done with less cost and more productivity. Likewise, agile methodologies bring to the playing field a need of experimentation to create more competitive practices that generated hundreds of new tools with a very pronounced effect on testing.
The end result is an increased awareness by developers of the testing process. Automated tests are becoming a premise of modern development techniques instead of a optional step in the development process. The benefits are clear: better management of changes in requirements, more robust products, improved integrations, and even better documentation depending on the tools a developer is using.
Even though those benefits are always touted as the main gains from testing, there is an additional benefit that is always overlooked people talk about the subject: the motivational gains testing can bring to the development process in the day to day coding.
Most new projects have complicated beginnings, with choices being made in the spur of the moment that will heavily influence their life-cycle. The motivational benefits of tests in the beginning of such projects can contribute to their development in two different ways: first, by making visible the project quality level from the first second; second, by the pure pleasure a passing test suite can bring to a developer.
People can be strongly influenced by what they see and a passing test suit can show that the work being done is not random but follows a precise structure that developers will then strive to keep.
Even legacy projects can use that to their advantage. By incrementally creating a testing process, developers will feel they are gaining control of a otherwise unyielding mass of code and that will be converted in other benefits as well, with better understanding of the code and progressive knowledge diffusion being two of the most important ones.
To underestimate the effect this kind of motivation can have on developers is the same as underestimating the human factor. Testing provides exactly the characteristics needed to increase motivation while also providing tangible technical benefits. And although the human factor is rarely factored in the choice of a methodology, the past few years have shown an increased awareness in this subject that is quite heartening.
So, the next time somebody complains that testing is a waste of time, maybe you don’t need to point only the technical benefits–the human benefits can be a strong selling point as well.
December 23, 2007 at 4:32 pm · Filed under Software Development
In the past couple of .NET projects my company developed, since we met with no objections from our clients, we decided to use Castle (by way of its two sub-projects MonoRail and ActiveRecord) to see how well it would perform. Unsurprisingly, considering the care that went into the Castle code, they made .NET development altogether more bearable.
Castle is a collection of projects that includes database access layers (using NHibernate to power a ActiveRecord implementation), templating engines (of which NVelocity and Brail are but two examples), and a series of other services geared to rapid application development.
Although my experience with Castle is still small, I’m liking it. I always considered C# a good programming languages and many of its characteristics fit very nicely with the way I like to develop when using a ORM implementation. For example, the way Castle implements ActiveRecord is, at least in my opinion, a much better way to see what’s going one–a nice blend, indeed, of the Rails and Django approaches.
Obviously, since C# is not a dynamic languages, some things are much hard–or at least, much less flexible–than their Rails or Django counterparts. Castle is also lacking some accessories we’ve grown to love in Rails; to wit, the console and the database shell. Nonetheless, it also shines when debugging is necessary since Rails lacks a decent debugger (although Netbeans, if you are incline to use it, solves the problem nicely) and Django is also missing debugging tools.
Looking at the changes already present in C# 3.0, I can see Castle becoming even more pleasant. At the moment, it is already saving us a lot of work and I’m sure it will be a lot better in the near future.
Next entries »
