Re: gforth webserver, why isn't forth used all over ecommerce?

John Passaniti wrote:
Elizabeth D Rather wrote:
We use Apache for FORTH, Inc.'s web site. It's a very good program. We never really considered a Forth solution for that. But the issue is when a general, fairly complete solution is or is not necessary and appropriate for an embedded application.

That may be your issue, but in this thread, we're not just discussing embedded systems (note the subject line and past conversation in this thread).
...

I wish people could get past the specific examples given and abstract to the larger questions being raised. The real question here is when is it appropriate to build from scratch and when is it better to reuse existing code. I've been making what I would hope would be an entirely uncontroversial statement: That there is no general answer-- that in order to answer that question with any intelligence, you have to start with project requirements and a consideration of where effort is best spent. That is, you have to answer the question by asking questions, or at the very least you have to be able to see the edges between the two and use your intuition and experience to make the decision.

Yes, I agree with your concern to focus on the general issue, which is why I brought up embedded systems. And I also agree with your "uncontroversial statement".

I consider that uncontroversial. But when the discussion comes up in comp.lang.forth, thoughtful reflection seems to rub people the wrong way. To ask the question is to fly in the face of Forth dogma and romanticized ideals-- that it's *always* better to build from scratch, and that reuse of code (which dives into the parallel discussion about libraries) is bad.

I'm not really sure folks here are as absolutist and dogmatic as you think. The people who have practical, professional problems to solve are pretty pragmatic about cost/benefit tradeoffs and will certainly use pre-existing code when it makes sense. But there's also a community of folks here for whom Forth is more of an intellectual exercise. For them, there's a subjective value in doing it from scratch just as one might walk to the store for exercise rather than take the bus.

....

> Apache, with all its goodness,
is pretty big, and expects OS services which are even bigger and more complex. We provide specific web services for some embedded apps, and found it much easier to write the subset of functionality we needed than to figure out how to shoehorn Apache into the resources available to us, and provide an interface to it (not to mention the issue of per unit costs to our customer for bigger products). And we did study for a while before reaching that conclusion.

Did that study look at webservers other than Apache? I assume you realize there are many others out there, including those designed to be used inside embedded systems.

Yes, we looked at several approaches. Most had costs in complexity, size, and interfacing issues that made our approach more practical and cost-effective.

Did you also look into building Forth into the webserver? There are modules (like mod_perl, mod_python, mod_ruby, etc.) that build those respective languages into the webserver, allowing it to have dynamic content driven by code in those languages. Nothing would prevent someone from doing the same for Forth and getting the same benefits users of those other languages have.

I assume that since you used the phrase "web services" that the embedded webserver you looked at wasn't serving just static pages, but something driven by Forth code (perhaps using templating or other techniques). Is this the case?

The needs in this case were pretty limited and specific. The embedded system was primarily doing data acquisition, supplying data to a host and getting configuration info from it. A small subset of the protocol was all that was needed.

My point in asking these questions isn't to suggest your study's conclusion was wrong. My point is to find the edges of your study so that the peanut gallery here who hangs off the advice of experts can understand the limits of what that study looked into.

We would never claim that what we implemented was a complete web server or a general solution to any problem, but it did contain some code that will be very easy to reuse for similar projects in the future.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================
.

Relevant Pages

  • Re: Value of C-C++ over Java in the general cases
    ... > other languages. ... majority of software written is for embedded systems. ... memory than Java if that is a limiting factor for the target platform. ... fact there are still many hardware components that cannot support C++ ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Programming language popularity
    ... Python is an infix LISP. ... compiles fast and can be tested interactively. ... mainstream languages, ... It can't be used in embedded systems. ...
    (comp.lang.forth)
  • Re: NORAD SGP4/SDP4
    ... languages are published, but Forth isn't one of them? ... aerospace and embedded systems as prime application areas, ... What Marcel is proposing is equivalent to what a diploma mill does. ... If someone who needed SGP4 were to choose Forth because they judged Forth to be the best way to get their application done, ...
    (comp.lang.forth)
  • Re: Spreading the word
    ... they are the players who should be servicing the embedded systems ... other languages now than they were a few years ago, ... English is now the lingua franca of spoken languages. ... Looking at the questions asked on the MSP430 Users group, ...
    (comp.lang.forth)
  • Re: Asynchronous Transfer of Control in SOA (Web Service)
    ... I was thinking about this concept from point of view of Embedded Systems ... If we have Timer Web Service as Server. ... should act accordingly to the client requirements. ... I don't think you're going to find Web Services useful to you. ...
    (microsoft.public.dotnet.framework.webservices)