Re: [colorforth] Adventures with Building Applications
- Subject: Re: [colorforth] Adventures with Building Applications
- From: vaded@xxxxxxxxxxxxxx
- Date: Wed, 20 Aug 2008 10:39:29 -0600
Thank you for the thoughtful and detailed post. Your explanations made
sense and given the context you're working within I see how JS is
necessary.
I have the luxury of not having to meet the needs of clients or having
to fit my projects within the available software infrastructures Thus my
thinking becomes absolutist but I appreciate and understand others are
working within different parameters.
I'm glad you find Forth fitting enough to what you're doing that it
makes sense to implement it and add it to the mix. I'm also grateful
you shared your experience on this list; our numbers here are small so
anytime someone shares some of their experience I find it very
interesting.
On Tue, 19 Aug 2008 16:37:20 -0400, "David J. Goehrig"
<dave@xxxxxxxxxxxxxx> said:
> vaded@xxxxxxxxxxxxxx wrote:
> > What I really mean is as long as there is this
> > dependency
> > on Javascript then that defeats the purpose of something like
> > colorForth.
> > Javascript becomes the weakest link and once you have to parameter
> > things
> > down to the level of Javascript you lost all the benefits of Forth.
> >
>
> The word dependency is kinda misleading. There's two directions,
> server side JS => Forth and client side Forth => JS. On the server
> side, the old code is written in JS and so is dependent on JS in that it
> is written in it. Hence translating JS => Forth! On the client side,
> well the client has a JS environment, so Forth => JS is the easiest way
> to get Forth on the client's system, so it is dependent on what the
> client has available.
>
> As for looking for alternatives, like getting a Forth based browser on
> everyone's PC and phone, that's essentially impossible. A lot of our
> applications have cellphone clients, and I do a lot of contract
> engineering for companies to port existing apps to things like
> Qualcomm's BREW. You'd never get your colorforth app through NSTL,
> simple as that. Apple won't put it on the iPhone either. On the other
> hand, those phones all have web browsers with some Javascript support.
>
> Javascript is everywhere, on the desktop, on the phone, and on the web.
> To view a viable client platform that can literally reach billions of
> people as "the weakest link" kinda misses the point. It is also the one
> programming language for which everyone with a browser can write
> software, and that nearly everyone can run. On the client side, it is
> simply the best target language. It has become the universal assembly
> language of the web.
>
> On the server side, I can do whatever I want. That's where I can
> leverage the benefits of Forth. I can produce tight code that does what
> it needs, and export that functionality to the JS users. The vast
> majority of the people who program web UIs know Javascript, but don't
> know Forth. Enabling them to write backend processing in JS and then
> behind the scenes implementing it in Forth means they remain happy and
> productive, and most importantly lets them invest in perfecting 1 skill
> JS programming, rather than trying to perfect 2 different skills JS +
> Forth. I reap the benefit of having more time to work on the Forth side
> of things, and my clients get their projects delivered on time. But
> that said, we still have a large base of legacy JS code that we have to
> support, so there's real incentive to port all of that to Forth.
>
> When you really get down to it, Javascript is just a bunch of C syntax,
> tacked on top of Self, which is itself just yet another LISP variant
> with a prototypal idiom for using assoc lists as objects. There's about
> five words you have to implement in Forth to handle the entire object
> model for Javascript, (new, get, set, apply, delegate). Nothing hard to
> mimic in Forth. While the programmer writing JS code can't take full
> advantage of the Forth engine, he at least can be as productive as he
> can be with the tools that he knows.
>
> From my point of view, the benefits of Forth are:
>
> 1.) I can quickly build a system that emulates the functionality of the
> old, and be able to run the old apps
> 2.) The resulting system will be substantially faster than, support more
> users than, and be more maintainable than the old
> 3.) Gives me a migration path to bare hardware in the event I need still
> more power
>
> The benefits of supporting Javascript are:
>
> 1.) I can continue to hire people who are Javascript experts, who can
> contribute their best effort
> 2.) I don't have to rewrite all the applications for existing clients
> (at great expense and no additional gain)
> 3.) It is everywhere, and as a target language, forth that generates
> javascript gives me the best of both worlds.
>
> Hope that makes sense.
>
> Dave
> ---
>
> David J. Goehrig
>
>
> Email: dave@xxxxxxxxxxxxxx
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
> Main web page - http://www.colorforth.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com