You've probably read Why Ruby is an acceptable LISP. Unless you're not in that kind of things and thus can safely skip this post.
(Note that if you are in this kind of things, you may enjoy the following page steam: Amb => Continuation Explanation => Actors Model => Power Loops.)
So yes, programming in Ruby is pretty satisfactory. It's clear and concise. You can have blocks, lambdas, metaclasses and such. After Ruby, C++'s clumsy syntax looks like an S&M exercise, Python looks silly with his need to declare self everywhere and PHP... Well my "$" key stopped working a while ago.
Of course once the over-enthusiasm has fallen down like a poorly baked soufflé, I'm left wondering if things are as green on the other side as it has been mentioned.
Obviously nobody's going to advertise a language by pointing out its defaults. Unfortunately I wish they would. This would stop short many language flame wars. After all, how many times do people have to complain that Ruby is not that much of an improvement over Python? There are some closed spheres where this is true and the benefice of Ruby does not outweigh nor justify the effort of a fourth implementation of everything over and over again. As far as I am concerned, the benefice over Python is good enough to make it worth. There are those who complain about Ruby when they are ecstatic about Perl, and quite frankly here I totally fail to see the point -- Perl is ugly and this ugliness is counterproductive enough for me that I want nothing to do with Perl, period. And same than for PHP, Python and Perl, the argument that the next incompatible major version is going to address all their weaknesses is a non-argument -- if it was really compatible, it wouldn't solve anything and it will take time to get as widely deployed. So in the meantime people will be forced using the new version but programming towards the old one for backward compatibility.
If you want something new, just use something new. And Ruby is here and good enough (and even a bit better here and a bit lesser there.) It's not the fastest VM in the world but then you're not going to implement data crunching algorithms with this. It's not the panacea but hey, these are programming languages and they are never the panacea. There's always one more thing.
Now one of the biggest problem with Ruby is Rails. More than often a Ruby detractor will slightly shift his focus on why you don't need Rails when the argument started against Ruby. I find that infinitely amusing. As much as the Rails clones such as that big joke called Grails and the new Perl thingy.
The point is Rails does work. It has its share of annoyances, the major one being the pain that it is to deploy it under Debian and its fragile dependance with the current Ruby version. It has its share of conventions that you better follow, yet you can still work around them if you're really stubborn (but in this case, choosing Rails is definitely a bad choice.) It integrates nicely with the Ruby language (as long as you have the right version) and is not too complicated to deploy once you understand the choices and their associated issues. And it bring real RAD to the web. After all I didn't even like Ruby and Rails until I re-implemented a full featured PHP web site in a couple of days after failing to add a new feature to the crummy PHP code base for a week.
The bottom line? I offer none. I'll give a try at Ruby and Rails for home projects like I did with PHP, Java, C# and Python in the past, which I all rejected to various degrees for various reasons.
Eventually some day I'll find an ubiquitous language that offers a mix of Smalltalk and Scheme without a crazy syntax, with the expressiveness and down-to-the-metal aspects of C++ and a good sensible adequate framework that doesn't require a 20 MB download first.
It's a well known problem in software engineering: developers have a tendency to reinvent the wheel. Why use someone's else framework when you can as easily roll your own? There's even an acronym for this: NIH (Not Invented Here.)
The causes for this syndrom are pretty much obvious: partly for ego (I can do better than this guy), or fame (I get all the credit), or control (it's my framework.) Most likely for all of the above in some or other degree.
Sometimes it makes sense -- that's called evolution. Maybe I can really do better than this guy. The plenitude of programming languages is a good example. That's why we have C++ vs. Java vs C#, Perl vs Ruby, etc. Would you rather still be programming in Pascal or even worse Cobol and Fortran? (On the other hand, what happened to APL?)
Most of the time it's useless and for one language that succeded to fame there are dozen who failed silently.
One non obvious problem with reinventing a language is the failure to realize
the size of the task. It's easy to come up with some grammar rules, fire flex
and bison and get something pronto. Yet depending on the target you want to
reach you'll realize you need libraries, a runtime and most important a community
and a commitment. Implementing the actual language is almost the most trivial part.
Same goes with frameworks. For example, imagine you stumble accross something like Rails. It's a pretty cool new framework, people love it and it shows an obvious successful track record. But then there's a major problem for Rails: it's not coded on my-favorite-language. Instead it's coded in someone's else favorite language and that's not good.
That's how you end up with Grails: the desire to reinvent the wheel despite the fact that the targetted language is not perfectly round and adequate, so it needs to be patched to look like... something else tham it was supposed to look like just for the sake of implementing the framework. Namely, Grails uses Java but it's not Java anymore... it's Groovy and Grails is just one many subprojects. The bottom-line is that it's something else and even if you know Java you can't code in Grails right away.
Grails is a very good example of reinventing the wheel for all the wrong reasons.
Even though, both Groovy and Grails have another big issue: the project is based on technical merit. The home page describes lots of technical reasons why it's cool. It fails to mention successful examples. Grails provides a couple tutorials which totally fail to introduce the concepts to newbies. Instead if you want to understand why Grails, you need to go to the Rails home page and read the introduction.
Documentation and support is the key, even in open source.
And finally Groovy fails for the same reason that Java: the project is already embryonic and crippled with tons of side-projects with stupid names. On the Ruby camp, you have Ruby and Rails and that's all. On the Groovy side you have Groovy, Groovy Markup, GPath, Groovlets, Groovy Sql, Groovy Beans, Grails, Gram, Groovy SOAP, etc.
I'm going to try a different document structure for project files:
- A plan organized by milestones, or iterations.
- One iteration = one milestone.
- Each milestone has the following section:
- An introduction
- A plan section
- A design & spec section
- An implementation notes section
- The last milestone is described first
- Milestones are in reverse chronological order
- Implementation notes and plan are in chronological order
- The design spec is in structured order.
- New additions can be tagged with a date but this is not important.
- When the scope of the project changes, a new milestone is to be created with its introduction and so forth.
These projects are generally just ideas that I explore. As such a project may not be completely defined when I start it. Eventually the project will go dormant for a while (days, weeks or even years) and then suddenly I want to explore it again. Typically in this case I find something was wrong with the original goal and want to refocus the project differently. In this case I tend to create a new project, say FooBar II instead of FooBar I. But this is odd as the former project had never been completed and sometimes not even started (as in not implemented.)
In this case instead of thinking of the new project as a different project I should rather think of it as a new iteration. It's enough to use the same project file and label all the notes and intro and plan files as belonging to iteration n and then move on with iteration n+1
Sometimes I really want to have a totally different project. An example is RIG 2 versus RIG 1. RIG 1 is an existing PHP web app that is close to be final and matches or even already surpassed the initial goals. RIG 2 is a new experimental project with a totally different scope. In this case RIG 2 is not a derivation from RIG 1 and deserves to have its own project file. On the other hand the scope of RIG 2 has already been refined three times. These correspond to three different iterations of RIG 2 and as such should be part of the same document.
Consequently a number of project pages need to be refactored:
- Xeres 2 must be folded back into Xeres as Milestone 2.
- Sne 2 should be folded back into Sne as Milestone 2.
- Rivet 2 is really something different than Rivet.
- Rig 2 Plan must be folded back in to RIG 2.
On potential derivation of this structure is to have one project page per milestone of a major project, for example I could have a main RIG 2 page that links to RigII-M0, RigII-M1, etc. This could be necessary if the project files becomes to big to the point that it's hard to read. In this case it would make sense for the main project file to contain the last milestone (for example RigII-M36) and then move the older milestones in their own file (RigII-M35, etc.) The main project file would link to the older milestones.
The last important point of the new document structure is the design & spec section. Originally these project pages were either plan files or design/specification pages. Lately they mostly centered around the implementation notes, which is a misnommer as many times these contain design comments.
Instead I need a clearly defined design & spec section for a given milestone. This must focus on structure and not be a time-ordered log. The section should at least contain part of this:
- An overview of the various parts or modules in action.
- For each module:
- Implementation overview.
- How modules interact.
- Interface API.
- Test plan for this module.
- Overall test plan for the whole application
- Deployment
- Expected issues & tasks not addressed
Each section should start with an overview & a rough sketch before any implementation happens and then get more detailed as the real implementation occurs. As the implementation goes, original thoughts may become obsolete and will need to be revised. The old paragraphs should be either removed or moved to an "obsoleted" section.
When I stopped coding on Xeres and Rivet last time, I had a similar issue: I wanted to completely dissociate the logic from the UI. Also I wanted to use some kind of callback or messaging mechanism to avoid tight coupling.
I remember now that I said something exactly like that for Hint: consider a program has a database of object. Viewing the program is just like querying a database.
So that's an idea. right there. It's not innovative in the sense that it probably has been done and there are surely things implemented this way out there. I don't care as long as it makes it easier for me to do what I want.
In the case of Xeres, there should be only a few live objects: media sources for audio and video, media consumers and UI consumers. I see two approaches here:
- Media sources are unique objects, they generate data items that contain portions of video or audio which is then consumed.
- Media sources are the items being queried and their value varies over time.
- Media sources are unique objects and generate one "output" unique object, which value changes when queried.
In the case of Hint, we could say that each directory and file is a unique object in the database and the UI performs queries and display.
In any case, the mechanism can be abstracted as follows:
- The database contains unique objects, independant of each another.
- Well no objects may be linked together but it must be done via weak links.
- Some objects will have a long lifetime and some others a short lifetime.
- Some objects can be automatically persisted accross sessions of the application.
- We may want some objects to auto-expire.
- Some objects are generators: they monitor something and generate new objects and may also obsolete some other ones (files being deleted, etc.)
- Some objects are consumer: they query for objects and consume them (i.e. remove them from the database.)
Consumer objects should be based on a monitoring/event model: they request a given live query on the database and are notified when objects are added or removed to this query. A granularity may be necessary.
Note for Xeres I started with a producer/consumer model with callback notifications. The model here is mostly similar except there's an intermediary in the middle. So technically that's one more layer and it's thus less efficient. Yet here I am interesting in having a generic model and remove as much direct coupling as I can.
Most notably I'd like to completly disable all links to and from the UI.
Blog Archives:
Most recent posts
2005/10/30 - 2005/06/07
2005/06/01 - 2005/04/03
2005/03/31 - 2004/12/18
2004/12/09 - 2004/07/05
2004/06/18 - 2004/03/28
2004/03/27 - 2004/01/18
2003/12/22 - 2003/11/02
2003/11/02 - 2003/09/01
[RSS]
|
|
This work is licensed by Raphaël Moll under a Creative Commons License.
|
|
| Color Theme: | Gray | Blue | Black | Sand | Khaki | Egg | None |
|
|
Visited 110 times by Google, last 2010/08/17 20:35
Visited 239 times by Yahoo!, last 2010/08/26 20:38
Visited 1 times by Alexa, last 2008/11/16 06:56
Visited 29 times by Teoma, last 2010/08/10 15:01
Visited 237 times by MSN, last 2010/09/01 19:47
|
|