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

Jonah Thomas wrote:
In the old days the complicated tools were inevitably buggy, so you'd
spend a lot of time working around the compiler bugs etc. Maybe now the
complex languages have the bugs removed so that they're easy to use, and
then you can ignore any complexities you aren't interested in. That
would be good.

You're being vague here so I don't know exactly what "complicated tools" you're talking about. I have certainly in my experience had to deal with things such as compiler bugs, but the last time I checked, Forth was the product of human beings and as such is subject to bugs in various implementations. I vividly remember some spectacular bugs in some of the past commercial Forths I've used (valForth, UR/Forth, MMSForth and some Apple II Forth that I've long since forgotten the name of).

No, the real issue with why Forth isn't used as much is something I touched on before. People want to spend their time solving
interesting problems, and endlessly reimplementing jellybean code and
common utilities isn't interesting.

I doubt that. I think it's more that employed programmers don't use
Forth much because managers don't like it.

Yes, I know that's one of the common conspiracy theories regarding Forth. And it wouldn't surprise me if you could actually produce a manager or two who disliked Forth. The world is full of irrational people who dislike things for trivial reasons.

But I seriously doubt this is in any way widespread. First, most managers likely don't even know what Forth is because Forth has been marginalized to just embedded systems (ironically by Forthers themselves). So no, the reason why the manager looking to hire a programmer to do web applications isn't hiring Forth programmers is because Forth isn't on their radar screen. Not because they "don't like it."

> And unemployed programmers
don't use Forth much because it doesn't look good on a resume.

Again, this doesn't make sense to me. Explain to me why someone reading over the typical bloated resume-- where most people will put down nonsense like HTML as a programming language-- would care in any way that someone added Forth to the litany of what they know. Most won't know what Forth is. Those who do will either judge it as relevant or not.

Listing proficiency in Forth on my resume has never presented a problem to me, but I've already had discussions in comp.lang.forth that indicate I apparently live in some bizarre rift of the universe where people are rational. Apparently everyone else lives in Silicon Valley where apparently the mere mention of Forth causes people to froth. Or at least it's a good story and feeds into some people's persecution complexes.

Here's a crazy idea. The next time someone writes in comp.lang.forth that they lost a job because they had Forth on their resume, try this experiment. Look over their past messages. Can they communicate well? Get their resume. How do they present themselves and their experience? Ask them some questions. Does it sound like they have a clue?

Do this, and I'll bet cold hard cash that FAR MORE OFTEN THAN NOT, the people who complain that Forth make them lose a job are the same people you yourself wouldn't want to hire. But like the black person who was convinced they didn't get the job because the company had racial biases or the woman convinced she didn't get the job because of sexist attitudes, the truth may be more basic.

Nah, don't. It would hurt people's feelings and it might start a cascade of critical questions being asked challenging other cherished assumptions around here. Yeah, they didn't get the job because of Forth. Yeah, that's it.

of the problem? Which would you find more satisfaction in-- implementing yet another minimal HTTP server, or designing the application that rides on top of that server?

Depending on the application, it might make sense to intertwine the app
with the server. Depending. Maybe a typical server interface is just
what you need, and there's no reason to have any different interface. It
depends on what you're doing.

EXACTLY! The key here is that while *some* people only need a HTTP server to serve up static content, *other* people are doing far more sophisticated things. And while *some* people think a five line Fahrenheit to Celsius temperature converter CGI script demonstrates the state of the art in web-based user interfaces, there are other people doing very sophisticated applications that do far more.

The notion that "it depends on what you're doing" is something I would think would be so fundamental to most of the discussions here in comp.lang.forth, but all too often, it seems it's the last thing discussed. Bernd comes out with his webserver and we have people-- both neophyte and experienced-- who look at that and say, "gawd, why would anyone want Apache?" These are the same people who likely have never written a significant web application who would understand that the webserver component is *trivial* compared to the real challenges that a significant application takes.

If you care about the server's security it might make sense to have a
minimal server that does just exactly what you want and no more. It
seems like that ought to be the easiest to make reasonably secure. Or
you could use somebody else's server and let security be their problem.
That's certainly the easy way, provided it doesn't cause *you* security
problems.

Again, there is a time and place for everything. There are applications where I might take the same approach Bernd did. We have an upcoming project that needs to do little more than serve up a static web page with a Java app embedded in it. For that, a simple server is perfect and something like Apache (even a stripped down embedded version) is grotesque overkill.

Right tool for the right job. It's a basic lesson, but when that tool happens to be written in Forth, all critical thinking and skepticism seems to go flying out the window here. Note how few people here ask questions that probe the boundaries of where Forth makes sense. It's a rare and special thing when it happens.

I haven't seen any significant antagonism against libraries.

Then you haven't paid attention.

> Not like
people hear somebody's building a library so they pick up the torches
and pitchforks. It's more that there aren't that many libraries, and a
lot of people scrape along without them rather than build them, and some
people talk like they wouldn't use them if they were available.

Yes, and that's antagonism. And depending on who those people are and the perceived clout they have, their opinions influence others. The end result is that the Forth community has largely internalized the notion that "libraries are bad," supplemented with the usual array of pejorative, sour-grapes statements to go to justify it.

> Not like
there's a Forth cabal, and when somebody says "I don't care what anyboyd
thinks, I'm going to build a string libarary!" then they get him
blacklisted from all the Forth blogs and Forth wikis and his credit
cards are all cancelled and DHS investigates him as a terrorist suspect.

No, it works the other way. You start with some of the more unquestioning hero-worship of Charles Moore, toss in some of the negative soundbites against the use of libraries ("they are for lazy, stupid, incompetent programmers"), mix in people who lack the sophistication to understand the skills needed to build libraries that are useful, and whirl in a blender. Pour into a glass and sprinkle with the fact that aside from highly marginal examples like the FSL and a handful of people's toolbelts, there are in fact no serious public libraries. There-- you have all the motivation any right-thinking Forther needs to ignore libraries.
.

Relevant Pages

  • Re: gforth webserver, why isnt forth used all over ecommerce?
    ... Just because Java provides a collection class ... I think it's more that employed programmers don't use ... implementing yet another minimal HTTP server, ... I haven't seen any significant antagonism against libraries. ...
    (comp.lang.forth)
  • Re: how to prevent the allocation of previously used memory by malloc?
    ... by the programmers of your library. ... Libraries shiped with a compiler ... that practically all bugs are discovered ... before you discover one in the base library. ...
    (comp.lang.cpp)
  • Re: If I get memory card, will email be stored on it?
    ... Microsoft cared about Windows Mobile quality, ... I've had Nokia phones that had more bugs than the Dash. ... in an IMAP mailbox, then when you send IMAP messages the copy ... Like many cellcos, AT&T offers their own SMTP server for customers whose ISPs block "off network" SMTP so any mail sent through AT&T's servers would NOT show up in your IMAP Sent folder, since your IMAP provider didn't actually "send" the mail- AT&T did on your behalf. ...
    (microsoft.public.pocketpc)
  • RE: Perf Library and connectivity errors
    ... Thanks you for posting in SBS newsgroup. ... between Exchange server and Client outlook application after installing SBS ... 9099 event can indicate a WMI issue on your Exchange ... connected are pasted below - where can I update the libraries? ...
    (microsoft.public.windows.server.sbs)
  • Re: Quality of FreeBSD
    ... Since then numerous bugs were fixed, ... large file systems, 64-bit support on newer AMD and Intel hardware, ... Since 6.x is maturing in pretty good synch with their deployment timeline ... as a virtual server product at an ISP. ...
    (freebsd-stable)