Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Tcl/Tk on Rails

72 views
Skip to first unread message

tclt...@aol.com

unread,
May 13, 2007, 9:30:42 PM5/13/07
to
I have been task by one of clients to study Ruby On Rails and as soon
as I am able, to start writting appliactions using Ruby On Rails. I'm
a newbie to Tcl/Tk and is now in the middle of the development of a
real world Tcl/Tk application.

My question is, can I come up with something similar to Ruby On Rails
by using httpd combined tcl plugin? Please enlighten me on this.

davidn...@gmail.com

unread,
May 14, 2007, 2:13:26 AM5/14/07
to
> My question is, can I come up with something similar to Ruby On Rails
> by using httpd combined tcl plugin? Please enlighten me on this.

Not likely.

tclt...@aol.com

unread,
May 14, 2007, 3:57:40 AM5/14/07
to
How about apache rivet? Is it dead?

Larry W. Virden

unread,
May 14, 2007, 8:38:43 AM5/14/07
to

Are you asking "Can I write the equivalent of Ruby on Rails in Tcl"?
The answer to that is yes.
However, do you know how much work has gone into Ruby on Rails? To
have the equivalent, expect to be coding for quite some time. And,
nothing personal intended, so I don't really know you, but if you are
trying to replicate something that a community of ruby fans (and
experts) have created, expect that you will need similar numbers of
similarly skilled people to achieve that level.

If you are really asking "is there anything in the tcl community which
is equivalent", that's a different question. And my first response to
that question would be "I don't know anything about Ruby on Rails -
describe the detailed specific requirements you have on comp.lang.tcl
and ask if what existing tools come closest to meeting those
requirements"...

MartinLemburg@UGS

unread,
May 14, 2007, 9:11:34 AM5/14/07
to
On May 14, 2:38 pm, "Larry W. Virden" <lvir...@gmail.com> wrote:
> If you are really asking "is there anything in the tcl community which
> is equivalent", that's a different question. And my first response to
> that question would be "I don't know anything about Ruby on Rails -
> describe the detailed specific requirements you have on comp.lang.tcl
> and ask if what existing tools come closest to meeting those
> requirements"...

Perhabs the wikipedia "Ruby on Rails" page helps a bit for the common
understanding:

http://en.wikipedia.org/wiki/Ruby_On_Rails

Best regards,

Martin Lemburg
Siemens Automation and Drives - UGS PLM Software


Mark Roseman

unread,
May 14, 2007, 9:34:07 AM5/14/07
to
"Larry W. Virden" <lvi...@gmail.com> wrote:
> If you are really asking "is there anything in the tcl community which
> is equivalent", that's a different question. And my first response to
> that question would be "I don't know anything about Ruby on Rails -
> describe the detailed specific requirements you have on comp.lang.tcl
> and ask if what existing tools come closest to meeting those
> requirements"...


Let me help... the answer is no, there is nothing that is equivalent or
even close. And, as you noted, the amount of energy and expertise
required to create one would be for all intents and purposes completely
impractical.

Mark

sp...@controlq.com

unread,
May 14, 2007, 10:57:19 AM5/14/07
to

While true, Ruby/Rails is a large undertaking, there is nothing inherent
about tcl/tk which prevents a similar package from being implemented other
than lack of a community effort. Tcl/Tk has a number of things already
going for it which may serve as components:

SQLite and bindings for various databases
HTTP (various libraries)
Apache/Rivet (a wonderful tool)

To enumerate but a few ...

AFAICT, Rails offers a limited (restricted) view of relational tables to
provide a persistent object store (not in the strict sense) which assumes
a key structure specific to rails, and if adhered to, will make coding web
based dbms apps trivial from a programming effort. Great for the 85% of
apps which require same, but a bear for the other 15% that require a
bit more sophistication IMHO.


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Neil Madden

unread,
May 14, 2007, 10:42:34 AM5/14/07
to

I don't think RoR uses anything like the Tcl plugin -- it's all
server-side as far as I know. There are a number of basic frameworks for
developing webapps in Tcl (Rivet, AOLServer, etc). Possibly the nearest
thing is the ActiWeb stuff that comes with XOTcl:

http://media.wu-wien.ac.at/apps.html

I've not used it myself though, so I don't know whether it compares to
Rails. I'd say just use RoR. Ruby's not a bad language.

-- Neil

Uwe Klein

unread,
May 14, 2007, 11:14:46 AM5/14/07
to
Neil Madden wrote:

> I don't think RoR uses anything like the Tcl plugin -- it's all
> server-side as far as I know. There are a number of basic frameworks for
> developing webapps in Tcl (Rivet, AOLServer, etc). Possibly the nearest
> thing is the ActiWeb stuff that comes with XOTcl:
>
> http://media.wu-wien.ac.at/apps.html

TCL on TARMAC ??

tarmac still a trademark?

uwe

davidn...@gmail.com

unread,
May 14, 2007, 2:51:17 PM5/14/07
to
On May 14, 9:57 am, tcltk...@aol.com wrote:
> How about apache rivet? Is it dead?

It's maintained for Apache 1.3, because people do use it in
production, but I wouldn't write anything new with it at this point,
let's put it that way. Tcl is pretty much dead on the web outside of
some niches. That doesn't mean no one uses it, it means that new
installations are basically 0.

Like others say, Tcl would actually be a good language to create
something like Rails in, but those of us in the Tcl/Web world never
put all the pieces together like the Rails guys did, and it's too late
at this point.

Jeff Hobbs

unread,
May 14, 2007, 7:19:36 PM5/14/07
to Mark Roseman

I doubt that was the thinking David Heinemeier Hansson when viewing the
many other existing frameworks. "Impractical" is defeatist bunk. In
fact, you could make an equivalent. Yes, it would take time. Yes, you
could learn from others and make something even better. It really
depends on whether you want "something better" or what's there works for
you. I could give several reasons why making the effort to rebuild such
a framework in Tcl would be interesting and unique (<mumble>real
threads, real unicode, unique uses for vfs, ...</mumble).

Jeff

tclt...@aol.com

unread,
May 14, 2007, 7:32:37 PM5/14/07
to
* How about this?

Æjaks combines the server-side Ajax windowing system Echo2 with the
powerful simplicity of the Tcl langauge. The result is a rich
development environment in which to develop Ajax-based web
applications, often with much less code to write.

* But it says this

Running Æjaks requires Java 1.5 or higher. If you don't have Java
already, you can download Java from http://java.sun.com. Get the JRE
package if you just want to run Æjaks, or the SDK if you want to
develop. All of the code should be able to run under Java 1.4, but I
haven't compiled all of the libraries using a 1.4 compiler. Next
release should include Java 1.4 support.

~~~

So I'm not quite sure if I would use this sense it doesn't sound
feature complete yet. Has Æjaks been used in a real world application?
Could this suffer the same fate as Apache Rivet?

I really have to come up with something really fast otherwise I would
end up using Ruby On Rails.


sleb...@gmail.com

unread,
May 14, 2007, 9:35:07 PM5/14/07
to
On May 15, 7:32 am, tcltk...@aol.com wrote:
> * How about this?
>
> Æjaks combines the server-side Ajax windowing system Echo2 with the
> powerful simplicity of the Tcl langauge. The result is a rich
> development environment in which to develop Ajax-based web
> applications, often with much less code to write.
>
> * But it says this
>
> Running Æjaks requires Java 1.5 or higher. If you don't have Java
> already, you can download Java fromhttp://java.sun.com. Get the JRE

> package if you just want to run Æjaks, or the SDK if you want to
> develop. All of the code should be able to run under Java 1.4, but I
> haven't compiled all of the libraries using a 1.4 compiler. Next
> release should include Java 1.4 support.
>
> ~~~
>
> So I'm not quite sure if I would use this sense it doesn't sound
> feature complete yet. Has Æjaks been used in a real world application?
> Could this suffer the same fate as Apache Rivet?
>
> I really have to come up with something really fast otherwise I would
> end up using Ruby On Rails.

It's not about feature completeness. It's about how you do things.
Neither Rivet nor Aejaks nor WebSh does it the way it's done in Rails.

For example, assuming you have a simple database
"superblog_development" set up with the tables "users" and "blogs".
With Rails, without opening you code editor, from the command prompt
type:

> rails superblog
> cd superblog/
> ruby script\generate users users
> ruby script\generate blogs blogs

Now your "superblog" website is ready. If your webserver is configured
to serve it then you can already open your web browser and start
adding users to your database. All without writing a single line of
code. From here you only need to write code to tie users and blogs
together.

Where's the script that generates the UI and database processing code?
It's autogenerated by Rails. You just need to customize it.

It's a different way of doing things. It's like Dreamweaver but from
the command line. I do love Tcl and I don't really like Ruby but
currently I know of no other system apart from fancy GUI apps like
Dreamweaver that does what Rails does.

Having said that, if I were to write something like Rails from scratch
I'd most likely do it in Tcl. I mean, this is just fancy text
processing with smart database abstraction. Tcl would be perfect for
something like this.

Larry W. Virden

unread,
May 15, 2007, 11:19:23 AM5/15/07
to

>
> "Impractical" is defeatist bunk.

Certainly not impractical from a _technical_ point of view. However,
it is going to take a lot of time, by someone who is organized and
sets down to outline the requirements, etc.

To be done well, and to become popular, it will require someone with
an interest in writing code that will be used by others behind the
scenes - someone who isn't afraid to learn about interfacing with ODBC
and various database interfaces, someone who wants to learn about the
cross-browser problems that one has when writing (or at least
interfacing with), javascript and xml, etc.

It will take time, energy, focus and motivation. Will it bring fame
and glory? Likely not. Will the code written be appreciated by others?
Most likely. Will someone decide to work on something like this?
Possibly. It would make for a fun project... maybe someone out there
has an interest in doing a thesis on such a topic?

Robert Hicks

unread,
May 15, 2007, 2:09:06 PM5/15/07
to
On May 15, 11:19 am, "Larry W. Virden" <lvir...@gmail.com> wrote:
<snip>

> It will take time, energy, focus and motivation. Will it bring fame
> and glory? Likely not. Will the code written be appreciated by others?
> Most likely. Will someone decide to work on something like this?
> Possibly. It would make for a fun project... maybe someone out there
> has an interest in doing a thesis on such a topic?

If a serious project developed I am sure there would be some help for
it. I know I would just to take it as an opportunity to learn MORE
Tcl. : )

Robert

davidn...@gmail.com

unread,
May 15, 2007, 3:16:23 PM5/15/07
to

Rivet was a serious project for a number of years, and little to no
help was forthcoming.

Mark Roseman's point is that the "Tcl community" is basically not up
to the task of creating something like this. We define "community" as
a population of individuals large enough to produce a few that have
the time, energy, motivation and skills to create "Tcl on Toboggans",
rather than a group of people who all collaborate on something.

Robert Hicks

unread,
May 15, 2007, 3:25:37 PM5/15/07
to
On May 15, 3:16 pm, "davidnwel...@gmail.com" <davidnwel...@gmail.com>
wrote:

> On May 15, 8:09 pm, Robert Hicks <sigz...@gmail.com> wrote:
>
> > On May 15, 11:19 am, "Larry W. Virden" <lvir...@gmail.com> wrote:
> > <snip>
>
> > > It will take time, energy, focus and motivation. Will it bring fame
> > > and glory? Likely not. Will the code written be appreciated by others?
> > > Most likely. Will someone decide to work on something like this?
> > > Possibly. It would make for a fun project... maybe someone out there
> > > has an interest in doing a thesis on such a topic?
>
> > If a serious project developed I am sure there would be some help for
> > it. I know I would just to take it as an opportunity to learn MORE
> > Tcl. : )
>
> Rivet was a serious project for a number of years, and little to no
> help was forthcoming.
>

I know and I think that the Tcl community should have "supported" it
somehow. There is
a difference though. You wouldn't have to know "C" to hack on "Tcl on
Rails" where that
was something you had to have or had to learn to contribute to Rivet.
Not throwing excuses
or anything out as I wasn't around in Rivet's hey day.

> Mark Roseman's point is that the "Tcl community" is basically not up
> to the task of creating something like this. We define "community" as
> a population of individuals large enough to produce a few that have
> the time, energy, motivation and skills to create "Tcl on Toboggans",
> rather than a group of people who all collaborate on something.

I agree with him about the time and effort that nobody would want to
contribute. That is
why it isn't doable. It would take a lot of both of those.

Robert

Kevin Walzer

unread,
May 15, 2007, 4:15:58 PM5/15/07
to
Ruby on Rails is an interesting case to consider when people complain
that Tcl/Tk has lousy marketing.

There's no doubt that Ruby on Rails has terrific marketing. But I'm
wondering if a backlash will develop. Anything that is hyped so much as
RoR often goes through a "correction" (to borrow a stock market term)
before it settles in to a stable niche in the market.

I can definitely say that I've looked briefly at Ruby and found it
lacking in the areas that interest me, specifically desktop GUI
development. It has Tk bindings, but I can't find any substantial
examples of shipping Ruby/Tk applications; it seems less mature in this
respect that Tcl/Tk or Python/Tk. Nor can I find any tools for
deployment of standalone GUI Ruby apps that compare to
starkits/starpacks, or apps built with py2exe/py2app in Python.

Since I'm not a web developer, I don't have an opinion on the technical
merits of RoR. But I don't see much value in trying to recreate RoR in
Tcl. If Ruby on Rails addresses your problem domain, then learn Ruby and
deploy your app on that framework.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Michael Schlenker

unread,
May 15, 2007, 4:33:20 PM5/15/07
to
sp...@controlq.com schrieb:

> On Mon, 14 May 2007, Mark Roseman wrote:
>> "Larry W. Virden" <lvi...@gmail.com> wrote:
>>> If you are really asking "is there anything in the tcl community which
>>> is equivalent", that's a different question. And my first response to
>>> that question would be "I don't know anything about Ruby on Rails -
>>> describe the detailed specific requirements you have on comp.lang.tcl
>>> and ask if what existing tools come closest to meeting those
>>> requirements"...
>>
>>
>> Let me help... the answer is no, there is nothing that is equivalent or
>> even close. And, as you noted, the amount of energy and expertise
>> required to create one would be for all intents and purposes completely
>> impractical.
>>
>> Mark
>
> While true, Ruby/Rails is a large undertaking, there is nothing inherent
> about tcl/tk which prevents a similar package from being implemented
> other than lack of a community effort. Tcl/Tk has a number of things
> already going for it which may serve as components:
>
> SQLite and bindings for various databases

SQLite has a great DB binding for Tcl, but to compete with something
like Rails, take a look at tcldb (see http://wiki.tcl.tk/14972). It has
migrations similar to rails, nice support for various db backends and
works just fine.

> HTTP (various libraries)
HTTP is just one small part. Rails uses lots of Javascript with
Prototype (which could trivially be used with Tcl too).

> Apache/Rivet (a wonderful tool)
Rivet is fast and ok.

> AFAICT, Rails offers a limited (restricted) view of relational tables to
> provide a persistent object store (not in the strict sense) which
> assumes a key structure specific to rails, and if adhered to, will make
> coding web based dbms apps trivial from a programming effort. Great for
> the 85% of apps which require same, but a bear for the other 15% that
> require a bit more sophistication IMHO.

Its not too hard to get something Rails-like up and running in Tcl and
for example XOTcl. (I have done it at my last job, sadly not publicly
available). Its all the polishing and nice to haves of Rails that are
the hard stuff. The basics are easy.

The basic Rails stuff like ActiveRecord, Action Pack, Action Mailer are
are fast to do.
1. Write a simple dispatcher that can dispatch to objects on urls (Wub
or tclhttpd direct domains offer most of what you need)
2. Use a DB layer like tcldb and provide some simple accessors (tcldb
already contains some)
3. Write some simple metaclasses for common db access stuff (the typical
CRUD stuff of Rails and some find... etc. methods)
4. Use the Rivet templating engine for views (or use tdom + xslt or tml
or whatever you like)
5. Add lots of polishing...

Michael

Robert Hicks

unread,
May 15, 2007, 5:35:35 PM5/15/07
to
On May 15, 4:15 pm, Kevin Walzer <k...@codebykevin.com> wrote:
<snip>

> Since I'm not a web developer, I don't have an opinion on the technical
> merits of RoR. But I don't see much value in trying to recreate RoR in
> Tcl. If Ruby on Rails addresses your problem domain, then learn Ruby and
> deploy your app on that framework.
>

Maybe not, but it would be nice to have a viable web framework for
Tcl.

Robert

sleb...@gmail.com

unread,
May 15, 2007, 11:14:34 PM5/15/07
to

In addition,the real value in implementing libraries from a Tcl world
view is that other people, as side-effect, often gets the benefit
(even when those very people insist that tcl is bad). Take a look at
history: Tk, expect, swig, sqlite...

Most of the dispatching mechanism for Rails is similar to most of the
Tcl web frameworks. Currently we're missing a javascript/AJAX savvy
GUI library/framework (Aejaks is nice and all but still depends on
Java as it's back end), scaffolding generation and database migration
system (though, it's not that hard to script but it's still nice to
have an automatic tool that does it for you).

Tom Poindexter

unread,
May 16, 2007, 12:35:09 AM5/16/07
to
In article <1179285274.1...@w5g2000hsg.googlegroups.com>,
sleb...@yahoo.com <sleb...@gmail.com> wrote:

>In addition,the real value in implementing libraries from a Tcl world
>view is that other people, as side-effect, often gets the benefit
>(even when those very people insist that tcl is bad). Take a look at
>history: Tk, expect, swig, sqlite...

Agreed. How many folks knew anything about Ruby before Rails anyway?


>Tcl web frameworks. Currently we're missing a javascript/AJAX savvy
>GUI library/framework (Aejaks is nice and all but still depends on
>Java as it's back end), scaffolding generation and database migration

Small rant -
Tcl folk should stop thinking of Java as a boogey man. Aejaks lets you
write Ajax/GUI apps in Tcl. Funny thing, your Tcl code has no idea
it's being executed in a JVM. Jacl rocks.

--
Tom Poindexter
tpoi...@nyx.net

Donal K. Fellows

unread,
May 16, 2007, 3:57:12 AM5/16/07
to
Tom Poindexter wrote:
> Tcl folk should stop thinking of Java as a boogey man. Aejaks lets you
> write Ajax/GUI apps in Tcl. Funny thing, your Tcl code has no idea
> it's being executed in a JVM. Jacl rocks.

The one problem with Java is that it is much more awkward to deploy
applications with it, compared with Tcl. (OK, this reflects just how
thoroughly we've solved the deployment area in the Tcl community;
starpacks rock.) Typically, authors of Java programs accept these
sorts of limitations and they have spurred on a lot of work in
installers, but even so we've got them beat *utterly*.

(Now, can we do this for other areas, like webapp containers? ;-))

Donal.

sleb...@gmail.com

unread,
May 16, 2007, 6:26:38 AM5/16/07
to
On May 16, 12:35 pm, tpoin...@nyx.net (Tom Poindexter) wrote:
> In article <1179285274.198311.287...@w5g2000hsg.googlegroups.com>,

>
> slebet...@yahoo.com <slebet...@gmail.com> wrote:
> >In addition,the real value in implementing libraries from a Tcl world
> >view is that other people, as side-effect, often gets the benefit
> >(even when those very people insist that tcl is bad). Take a look at
> >history: Tk, expect, swig, sqlite...
>
> Agreed. How many folks knew anything about Ruby before Rails anyway?
>
> >Tcl web frameworks. Currently we're missing a javascript/AJAX savvy
> >GUI library/framework (Aejaks is nice and all but still depends on
> >Java as it's back end), scaffolding generation and database migration
>
> Small rant -
> Tcl folk should stop thinking of Java as a boogey man. Aejaks lets you
> write Ajax/GUI apps in Tcl. Funny thing, your Tcl code has no idea
> it's being executed in a JVM. Jacl rocks.

But why should we *need* Java simply for pushing *text* around? Come
on, if we're talking about C then it sort of makes sense. But strings
are supposed to be what Tcl is all about.

On a personal level I can't use Aejaks because Java is not installed
in my environment. And running Java on my server will consume heaps of
resources that I don't have (if you have to ask, I'm running Linux on
an ARM9 with 32M RAM, 8M of which are used for ramdisk mounted as /
var).

sleb...@gmail.com

unread,
May 16, 2007, 6:32:49 AM5/16/07
to
On May 16, 3:57 pm, "Donal K. Fellows" <donal.k.fell...@man.ac.uk>
wrote:

Admittedly this is a non-issue for this problem domain. Deploying your
website on Apache is about the same for any language (Rails is server
neutral and I'd prefer that any solution we up with to be server
neutral as well).

Arnulf Wiedemann

unread,
May 16, 2007, 6:59:51 AM5/16/07
to
tclt...@aol.com wrote:

my 2 Cents to that topic see: http://wiki.tcl.tk/18088
Arnulf (APW)

Larry W. Virden

unread,
May 16, 2007, 7:29:03 AM5/16/07
to
On May 15, 4:15 pm, Kevin Walzer <k...@codebykevin.com> wrote:

>But I don't see much value in trying to recreate RoR in
> Tcl. If Ruby on Rails addresses your problem domain, then learn Ruby and
> deploy your app on that framework.

I'm of two minds on this approach. I believe in using tools that fit
the need, certainly. However, I work in an environment where every new
language brought in has a cost, even if labeled as "free". One has to
invest in training, not just of one person, but several (backups,
maintenance, etc.), etc. So having a strong framework written in a
language already in place ends up being less expensive, overall, than
bringing in a new language like PHP, Ruby on Rails, etc.

Larry W. Virden

unread,
May 16, 2007, 7:41:54 AM5/16/07
to
On May 15, 4:33 pm, Michael Schlenker <schl...@uni-oldenburg.de>
wrote:
>
> take a look at tcldb (seehttp://wiki.tcl.tk/14972). It has

> migrations similar to rails, nice support for various db backends and
> works just fine.

Hmm - to which tcldb do you refer? The one at dqsoftware.sf.net
appears not to have a lot of updates in the past. That doesn't
necessarily mean a lot - I mean, the software might just be so
wonderfully stable that there are no bugs left, nor any new features
needed, nor any documentation improvements needed, etc.

It would be nice if tcldb, or something like it, could make its way
into ActiveTcl , so that more people would make use of it.


> HTTP is just one small part. Rails uses lots of Javascript with
> Prototype (which could trivially be used with Tcl too).

What about the Aejaks extension? Would it provide a comperable level
of Javascript access? I mean, I tend to be pretty enthusiastic of any
code associated with Tom P ;-)


>
>
> Its not too hard to get something Rails-like up and running in Tcl and
> for example XOTcl. (I have done it at my last job, sadly not publicly
> available). Its all the polishing and nice to haves of Rails that are
> the hard stuff. The basics are easy.

I was poking around on the xotcl site lately and there were a couple
of "built on xotcl" references which sounded intriging... but the
links were dead so I wasn't able to read more than a short semi-
sentence about them.


marc spitzer

unread,
May 16, 2007, 7:42:06 AM5/16/07
to
On 2007-05-15, Robert Hicks <sig...@gmail.com> wrote:
>
> I know and I think that the Tcl community should have "supported" it
> somehow. There is
> a difference though. You wouldn't have to know "C" to hack on "Tcl on
> Rails" where that
> was something you had to have or had to learn to contribute to Rivet.
> Not throwing excuses
> or anything out as I wasn't around in Rivet's hey day.
>

one thing, from what little I know about rails, 37signals paid for it.
They developed it as a tool to allow them to bang out websites quick
and then opensourced it for their own reasons. This is different from
people working on a project after work, even if it does the same thing.

marc
--
ms4...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

GN

unread,
May 27, 2007, 8:09:54 AM5/27/07
to

>
> I was poking around on the xotcl site lately and there were a couple
> of "built on xotcl" references which sounded intriging... but the
> links were dead so I wasn't able to read more than a short semi-
> sentence about them.

which links are dead?

The xotcl site contains under publications a couple of papers about
xotcl; related to web-environment, the following paper describes
actiweb, which is part of the xotcl source distribution.

G. Neumann, U. Zdun: Distributed Web Application Development with
Active Web Objects, in: Proceedings of Internet Computing 2001, The
2nd International Conference on Internet Computing, Las Vegas, USA,
June, 2001.

Concerning database based web applications, one could check xotcl-core
and xowiki in OpenACS (http://openacs.org). For a description of the
oo interface to the content repository, see e.g.
http://openacs.org/forums/message-view?message_id=346699, for some
more background about xowiki see http://alice.wu-wien.ac.at:8000/xowiki-doc/,
and some presentations on http://oacs-dotlrn-conf2007.wu-wien.ac.at/conf2007/.

Robert Hicks

unread,
May 28, 2007, 9:39:43 PM5/28/07
to
On May 16, 7:42 am, marc spitzer <ms4...@sdf.lonestar.org> wrote:

> On 2007-05-15, Robert Hicks <sigz...@gmail.com> wrote:
>
>
>
> > I know and I think that the Tcl community should have "supported" it
> > somehow. There is
> > a difference though. You wouldn't have to know "C" to hack on "Tcl on
> > Rails" where that
> > was something you had to have or had to learn to contribute to Rivet.
> > Not throwing excuses
> > or anything out as I wasn't around in Rivet's hey day.
>
> one thing, from what little I know about rails, 37signals paid for it.
> They developed it as a tool to allow them to bang out websites quick
> and then opensourced it for their own reasons. This is different from
> people working on a project after work, even if it does the same thing.
>

While that is true...I would not consider it a "barrier". It would
just take
more time.

Robert

Donal K. Fellows

unread,
May 29, 2007, 3:59:53 AM5/29/07
to
Robert Hicks wrote:
> While that is true...I would not consider it a "barrier". It would
> just take more time.

I'd go further and say that without a clear use case (like "banging
out basic websites for money") then the effort will likely fail to get
far enough to get traction. It is a sad fact that the hardest stage
for any Open Source project is getting it to the stage when there's a
band-wagon for others to jump on; lots of stuff just never gets there.

Pick that initial target and focus on hitting it. Make it trivial to
"bang out basic websites" and you'll find that the steps after that
become easier.

Donal.

marc spitzer

unread,
May 29, 2007, 7:16:24 PM5/29/07
to
On 2007-05-29, Donal K. Fellows <donal.k...@man.ac.uk> wrote:
>
> I'd go further and say that without a clear use case (like "banging
> out basic websites for money") then the effort will likely fail to get
> far enough to get traction. It is a sad fact that the hardest stage
> for any Open Source project is getting it to the stage when there's a
> band-wagon for others to jump on; lots of stuff just never gets there.
>
> Pick that initial target and focus on hitting it. Make it trivial to
> "bang out basic websites" and you'll find that the steps after that
> become easier.
>
> Donal.
>

The funny thing is that 37signals says the same thing in their book:
http://gettingreal.37signals.com/toc.php

It's not a particularly deep book, but I am not a particularly great
programmer. So it worked out in the end.

0 new messages