On Thursday, December 25, 2014 12:44:37 PM UTC-6, WJ wrote:
> Very nice analogy, but disciples of ANS Forth won't understand it.
> I'm afraid that they are too simple-minded to grok high-level
> languages.
>
> They are the worst enemies that Forth has ever had.
>
> If Forth is to live, then ANS Forth must die.
Here we have the most readily and naturally extended language on
the planet, and the criticism against it is ever "This language
[without extension] is less expressive or less capable of this
task than that that language (with some libriaries) is." I wonder
in how many languages and for how many tasks you can make that
point. If you were more productive I guess you would already have
the next Factor or RetroForth or blah.
Meanwhile... just so you have some idea at all of the kinds of
things that actually *do* go through the heads of the 'disciples
of ANS Forth':
Have you heard of PHP? It sucks. One of the biggest things it
sucks is CPU time and memory. It is the absolute suckiest on
shared hosting, because the hacks to make it suck less aren't safe
to use when you don't trust your users and your users also don't
trust each other. That it sucks is actually a big problem for a
lot of its users. Nonetheless, PHP is a big deal, because people
have put a lot of work into content management systems (WordPress,
Joomla, Drupal, Magento) that use it to let ordinary people do
creative stuff and make money, with very minimal investment.
Those people don't care that they're using PHP.
How much does PHP suck? It sucks so hard that if you direct
enough traffic at a .php file that contains straight HTML -- that
contains no PHP at all -- that the CPU cost of firing up PHP and
having it look at this file and decide do nothing but regurgitate
it will cause your account to be suspended on shared hosting. And
not unreasonably; 'overselling' doesn't have a whole lot to do
with your ability to rack up ten times more CPU seconds than
anyone else on the server. OK, it requires a lot of traffic, but
it happens, and people are surprised when it does.
The proposed answers to PHP's suckage (e.g., from CMS producers,
from Zend, from alleged competitors like CMS systems in Perl) all
go like this: first, get dedicated resources; second, hire a
developer; third, set up this elaborate system, and then--
basically they miss the point from the get-go. One of the hot
things in Perl is the Dancer framework, and I spent ages looking
for a quick tutorial on how to get that running on shared hosting,
and there isn't any such tutorial. You can do it though - badly;
And if you complain, the only way they know how to help you make
it better is to miss the point.
But shared hosting, these days, isn't just a little web UI with a
button that you can use to install your PHP CMS of choice.
They give you an account on a normal-ish unix box and you can run
all kinds of stuff, provided that you understand the environment.
Typically, under shared hosting, PHP sites aren't using persistent
processes. A PHP process is fired up on every individual request
that isn't for a static asset like an image or a CSS file, and it
generates some HTML. It might also generate a cache file of the
generated HTML that mod_rewrite rules (or another PHP process) can
pull the HTML from instead. Even if you have process limits (and
you always have SOME resource limit that concurrent running PHP
processes would eventually hit), you can handle large numbers of
requests per second because each request's PHP process finishes
fast enough for all the rest of the requests to come through.
So you want a process to start up, do its work, and then go away
as quickly as possible, while consuming as little CPU as possible.
(memory usage is much less important, yes even on shared hosting.)
You use standard I/O and environment variables to do this;
possibly, you connect to a database server or an SMTP server over
the local network.
So I'll just leave this here:
https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Startup-speed.html
.... oh, and ANS Forth is such an obstacle that a Forth CMS might
come with a little slot that customers can put money into to make
their sites work more betterer. I sure wish I could discard that
potentiality for no benefit whatsoever.
-- Julian