so about forth and the web, is it crazy to make websites outa forth?
gavino
Or is itcompletely cool to learn it and use it to whip up nice websites?
J Thomas
gavino wrote:
> I mean is forth for like mebedded things?
>
> Or is itcompletely cool to learn it and use it to whip up nice websites?
If you're using somebody else's server, and they're all hot on security
and control and not letting you crash their system and all, they may
not run a Forth for you or let you run one. So then you're out of luck
using Forth, unless you use it to create HTML pages or something on
your own system and upload the completed pages -- nothing dynamic.
If you're running your own server then Forth is a credible choice. It's
been done simply, it can work. Look at how other people have done it
and see how much complication you need on top of that. Maybe you can
get what you need simply.
Tarkin
gavino wrote:
> I mean is forth for like mebedded things?
>
> Or is itcompletely cool to learn it and use it to whip up nice websites?
FWIW & IMO - Forth(s) is/are like lathe(s). Things you can make are
limited only by your imagination, your time, and your setup.
Do not confuse it with more generalized, multi-purpose tools,
like C, Java, Python, Perl,or Ruby.
Forth has a 'tradition' of lending itself to embedded development,
as crafting a forth (for a target) is (somewhat) more straightforward,
and (somewhat) less strenous, than say, fitting a Small C or Pascal
(I'm thinking of a specific flavor of and Pascal, cannot remember it at
the
moment). I say this because, after contrasting the three, I felt like
by
the time I had made all the tough implentation decisions and gathered
the necessary compilation environments for (Small) C or Pascal
devlopment,
I could have written a (and learned about) a Forth.
There seems to be debate as to how much of a software base there
actually is for Forth in general; this is a multi-facted issue with
many
points to consider, not the least of which is the fact that are many,
many Forths. Another point to consider is that a lot of propietary
code exists, with all the legal/monetary consideration that that
entails.
However, glancing through some of the questions you have posted
thus far to this NG, I'm gueesing you're looking for some drop-in,
turnkey, OSS/FSS/Apache/BSD -licensed type of [app name here].
AFAIK, there is no such thing for Forth. However, you very *could*
DIY a 'J2EE'-style environment, if you started small. With a few
bat-belt
utilities, you could sprout a 'vanilla' webserver, implement the
necessary
RFC's, and then plan a servlet-esque extension.
HTH,
Tarkin
sl...@jedit.org
Please don't reply to gavino. He does the same thing in comp.lang.lisp
-- posting mindless, one-sentence posts every couple of days, always
something like "does lisp have application server", "is lisp used in
enterprise?" he is not interested in learning anything, he just posts
these turds to get a reaction out of people. If you don't reply to him,
he will go away.
Slava
Neal Bridges
news:1161825178.8...@h48g2000cwc.googlegroups.com...
> Please don't reply to gavino. He does the same thing in comp.lang.lisp
> -- posting mindless, one-sentence posts every couple of days, always
> something like "does lisp have application server", "is lisp used in
> enterprise?" he is not interested in learning anything, he just posts
> these turds to get a reaction out of people. If you don't reply to him,
> he will go away.
That's Gavin Schuette. The most charitable description would be "internet
pest". He's been at it for years. Here are some of the highlights from the
last day (these are the entire posts, not partial quotes):
comp.lang.scheme:
"Where are the free software scheme intperpreters, manuals, webapps,
appservers, databases?
I mean you can do all kinda killer stuff with scheme now SHOW ME tHe
APPS!!"
comp.lang.perl.misc:
"can someone unban me from freenode irc? #perl ?"
comp.lang.java.programmer:
"Why so many java frameworks?
Can't you just put all the good ideas into 1?
Jeesh"
comp.lang.apl:
"Where are the free software APL intperpreters, manuals, webapps,
appservers, databases?
I mean you can do all kinda killer stuff with APL now SHOW ME tHe APPS!!"
--
Neal Bridges
http://quartus.net
George Hubert
Neal Bridges wrote:
> <sl...@jedit.org> wrote in message
> news:1161825178.8...@h48g2000cwc.googlegroups.com...
> > Please don't reply to gavino. He does the same thing in comp.lang.lisp
> > -- posting mindless, one-sentence posts every couple of days, always
> > something like "does lisp have application server", "is lisp used in
> > enterprise?" he is not interested in learning anything, he just posts
> > these turds to get a reaction out of people. If you don't reply to him,
> > he will go away.
>
> That's Gavin Schuette. The most charitable description would be "internet
> pest". He's been at it for years. Here are some of the highlights from the
> last day (these are the entire posts, not partial quotes):
>
Very charitable. I would call him a Troll; and the give the advice
Do not feed the Trolls.
George Hubert
Cecil Bayona
Ping....testing my new ISP account.
This is about this subject is good about, I have also noticed this party
posting in other groups on line zingers.
--
Cecil
KD5NWA
www.qrpradio.com www.hpsdr.com
"Sacred Cows make the best Hamburger!" Don Seglio Batuna
Cecil Bayona
John Passaniti
>> Or is itcompletely cool to learn it and use it to whip up nice websites?
>
> If you're using somebody else's server, and they're all hot on security
> and control and not letting you crash their system and all, they may
> not run a Forth for you or let you run one. So then you're out of luck
> using Forth, unless you use it to create HTML pages or something on
> your own system and upload the completed pages -- nothing dynamic.
There are two cases here.
In the situation you describe, you're likely using Forth as a CGI
process. And as such, any crashes there would be much like crashes for
any other language-- the OS would kill the process and the CGI process
would fail. No big deal.
A bigger deal would be to write an extension to the server, such as
modules for Apache, or whatever Microsoft is using for server extension
these days on IIS. In that case, the extension runs in the same process
as the web server and it crashes. That's less likely however, since few
shared hosting web hosting services let you add extensions to the web
server.
> If you're running your own server then Forth is a credible choice. It's
> been done simply, it can work. Look at how other people have done it
> and see how much complication you need on top of that. Maybe you can
> get what you need simply.
There are two problems people taking your advice will have to face.
First, there is the usual confusion people in comp.lang.forth seem to
have with web servers verses web applications. Writing a web server
isn't hard. The simpler aspects of HTTP are easy to implement. But
once you do that you have... a web server. And if all you're doing is
serving static content, you're done.
But these days, most anything interesting that people want to do
involves some server-side processing. And that's where it gets
interesting, because now we're not just talking about Forth code that
implements HTTP. Now we're talking about Forth code that provides words
suitable for creating web applications. Specifically, there are words
one would want to deal with the most common issues, for example,
maintaining session state (since HTTP is stateless). And while none of
those issues are particularly difficult, someone has to write them.
To me, the only place I would use Forth for web applications would be in
embedded systems that have to present a web interface. In embedded
systems, the small size and purpose-built nature would be a good fit.
For other non-embedded applications, it is far more efficient (in terms
of programmer effort and time-to-completion) to tap the wealth of web
application frameworks and supporting libraries found with other languages.
sl...@jedit.org
John Passaniti wrote:
> But these days, most anything interesting that people want to do
> involves some server-side processing. And that's where it gets
> interesting, because now we're not just talking about Forth code that
> implements HTTP. Now we're talking about Forth code that provides words
> suitable for creating web applications. Specifically, there are words
> one would want to deal with the most common issues, for example,
> maintaining session state (since HTTP is stateless). And while none of
> those issues are particularly difficult, someone has to write them.
>
> To me, the only place I would use Forth for web applications would be in
> embedded systems that have to present a web interface. In embedded
> systems, the small size and purpose-built nature would be a good fit.
> For other non-embedded applications, it is far more efficient (in terms
> of programmer effort and time-to-completion) to tap the wealth of web
> application frameworks and supporting libraries found with other languages.
I've been working on and off on a web application framework for Factor.
It will have a feature set comparable to Rails or Seaside when its
done, hopefully.
Slava
Cecil Bayona
It is different, I'm looking for some small examples, no more than a
couple of pages so I can see the whole in action, right now I feel like
I'm too close to the trees and need to step back and see the forest.
sl...@jedit.org
Cecil Bayona wrote:
> That's good, I've been playing a little with Factor to get a feel for it.
>
> It is different, I'm looking for some small examples, no more than a
> couple of pages so I can see the whole in action, right now I feel like
> I'm too close to the trees and need to step back and see the forest.
There are a number of small examples in the examples/ directory of the
distribution. Larger examples are in contrib/.
Slava
Coos Haak
> Try it again PING!
This is the fo(u)rth time! Use a newsgroup like alt.test
**PLONK**
--
Coos
Cecil Bayona
Yes MOM, and I'll dry the dishes right after this show is over.
This thread is troll bait anyway, this guy post stuff all over with
single line zingers and skips town while everybody argues, but then I
noticed that many people in this group like to argue about minutiae.
Alex McDonald
You'll find a high quality of discourse on c.l.f with very little spam,
and a number of very helpful people -- as long as you don't hack them
off. This is not a good start.
--
Regards
Alex McDonald
Cecil Bayona
**PLONK** ?
Isn't upper case considered to be yelling at someone, I respond with a
small joke, and I'm not making a good start?
Interesting
Mike T
> There are two cases here.
>
> In the situation you describe, you're likely using Forth as a CGI
> process. And as such, any crashes there would be much like crashes for
> any other language-- the OS would kill the process and the CGI process
> would fail. No big deal.
>
> A bigger deal would be to write an extension to the server, such as
> modules for Apache, or whatever Microsoft is using for server extension
> these days on IIS. In that case, the extension runs in the same process
> as the web server and it crashes. That's less likely however, since few
> shared hosting web hosting services let you add extensions to the web
> server.
>
The second case is a more general problem of embedding Forth into an
application as a run-time scripting language. Certain applications
require crash proof operation. I know that some Forth's claim to be
crash proof, such as 4TH, but I've not investigated that claim.
Cheers,
Mike
Julian V. Noble
I do not believe there exists such a thing as a crash-proof
language. Certainly one could never demonstrate that a given
program was crash-proof without solving the stopping problem.
The best one can hope for is that a program is crash-tolerant,
so that it does little or no damage and can restart gracefully.
--
Julian V. Noble
Professor Emeritus of Physics
University of Virginia
John Passaniti
> I do not believe there exists such a thing as a crash-proof
> language. Certainly one could never demonstrate that a given
> program was crash-proof without solving the stopping problem.
Like in all things, the phrase "crash proof" means different things to
different people. You're talking about a language-theoretic view, while
most people take a more pragmatic approach, and focus on the common
kinds of problems that cause applications to crash. No, you can't
address 100% of the problems that can cause programs to crash. But if
you address 85% of it, it does certainly help to focus on the last 15%.
Don't confuse the marketing hype with the engineering reality. No
system is "crash proof" but that doesn't mean that by carefully defining
and addressing the problem, pragmatic solutions can't be enormously
helpful.