"Adam D. Ruppe" <destructiona...@gmail.com> wrote in message
news:iqji6m$1se1$1...@digitalmars.com...
> Jacob Carlborg wrote:
>> How is it working out with a static type system, compared to a
>> dynamic, for web development?
>
> It's *much* better, especially for rapid development. The compiler
> will tell me if my changes anywhere break things anywhere else,
> so I can modify with confidence.
>
> I can't tell you how many times I've made a minor mistake in PHP,
> Ruby, or Visual Basic and had it slip through to production because
> the code path was obscure enough to evade testing.
>
Yea, it all just comes from dynamic being sloppy and overly-permissive.
Before I switched my web development to Haxe (not remotely as good as D, but
it beats the hell out of straight PHP/ActionScript), I had to do some stuff
in ActionScript2. Anytime anything would go wrong (other than a syntax
error), the compiler would accept it, and the *runtime* would accept it and
just simply ignore it and move on. Not even an exception or log notice or
anything. That alone turned development into an absolute nightmare. Nothing
ever worked, you never had the slightest clue why, and it took forever to
track the problem down to something that, invariably, would turn out to be
something D would have caught immediately, usually at compile-time. And that
was all in the name of being "forgiving". Blech. Bottom line, whether
dynamically-typing or anything else: being overly-permissive sucks. What D
permits you to do is tighten the damn leash.
>
> The to!() template in Phobos makes this pretty easy, or if you
> want default value and get/post combined, my cgi class has a request
> template:
>
to!() is absolutely awesome. OTOH, thanks to to!(), the conversion functions
in every other language out there seem irritatingly poorly designed. ;)
Anytime I have to do a conversion in Haxe, I always end up needing to reach
for the std API reference. And even Haxe's API for conversions is pretty
good compared to some other langauges.
> int a = cgi.request!int("a");
>
> That's similar to this in PHP:
>
> $a = 0;
> if(isset($_POST['a']))
> $a = (int) $_POST['a'];
> else
> if(isset($_GET['a']))
> $a = (int) $_GET['a'];
>
>
> PHP is so outrageously verbose. And the PHP is buggy compared to
> the D... if you do cgi.request!int("a", 10) and the user does a=txt,
> the PHP result is wrong. It's not quite fair to compare a function
> to a code collection though. A php function could do it right too.
>
Be glad it's not VB6, or worse, VBScript. I've had to do a lot of web dev in
those languages in the past, and as horrible as PHP is overall, for outright
verbosity it doesn't even compare to VB6/VBScript.
auto myVar = "foo";
$myVar = "foo";
vs:
Dim myVar As String
myVar = "foo"
Seriously?!
And don't get me started on VB's million-and-one different things you have
to check for to see whether or not a string actually contains anything.
And then there's its arrays, which wouldn't be *too* bad if they didn't
allow the staring index to be chosen completely at random. So, wanna find
the length of an array? In D it's:
myArray.length
In PHP it's probably about the same as D. In VBScript, if you want to do it
correctly, it's:
(UBound(myArray) - LBound(myArray))+1
Or you can do UBound(myArray)+1 and just pray that some stupid jackass
doesn't actually try to use the "choose your array's lower bound", ahem,
"feature".
I can just feel my sanity fading...
>
> auto table = cast(Table) document.getElementById("data-table");
> assert(table !is null); // fails if it isn't a <table> tag
>
> // use the table class's special functions
>
>
> Forms, Links, and other types of nodes are handled similarly. The
> Element base class though does most the simple operations. Being
> plain old inheritance, the virtual functions act dynamically
> enough.
>
You know, I used to absolutely love doing the rails-like thing of using HTML
templates. And Terence Parr's StringTemplate even managed to convince me for
awhile that such templates shouldn't have imperative logic.
But the more I watch your DOM approach and then continue using HTML
templates (very mercifully, one that thankfully *does* allow imperative
logic), the more fed up I'm starting to get with the template approach.
Granted, I haven't used it yet, but I think you've got the right approach
with your DOM stuff.
>
> And more stuff is packed in there too. Best of all: D, through
> CGI, consistently does well or better than mod_php in my speed
> benchmarks. I've barely tried to optimize too; there's a lot of
> untapped potential.
>
One of the things I've noticed never even seems to get mentioned is that
even though CGI has had a stigma of high startup costs, *MANY* php
installations, even on commercial shared hosting, have php set up to run as
CGI. So even if php interpretation wasn't much slower than good compiled
code, it *still* wouldn't usually have the speed advantage people have
attributed to it.
>
> If your host doesn't suck, dive into D on the web. You won't want
> to go back.)
Won't want to go back to dynamic web scripting? Hell, I haven't even done
any D CGI beyond a trivial hello world (for which I had to jump through
*enormous* hoops to get working with my damn shared web hosts - and one of
them, turns out, won't even support compiled CGI at all), and yet, I just
plain don't want to *remain* with dynamic web scripting. :)
Another thing, too, that's really good about D being faster is that you can
do a lot more before Apache/PHP/whatever decides to kill you off for taking
too long. And you can realistically try to anticipate it, finish up any
atomic operations, and die gracefully instead of risking corruption from
broken atomicity.
That's getting to be a problem in my Haxe/PHP stuff. I have my code set up
so that when there's an unhandled exception, it automatically tries to log
it to three separate places: a logfile, the DB, and email. (And if any one
of those fails, it still attempts the others and then tries to notify the
others that the one failed. I'm really proud of the whole system :)) And, of
course, a stack trace is included. But the problem is, this all takes
(noticable) time, especially on PHP, so I risk loosing all the info that
anything even went wrong at all just because the server killed it off for
taking too long. And that's actually happened a few times on my local dev
system (I *hope* it hasn't happened on the server...) Heck, I can usually
tell when it's crashed even before I get the error page just because it'll
take noticably longer than usual.
But what makes all that really bad is there seems to be a bug in either Haxe
or PHP that causes stack traces to include *all* the functions called...ie,
even the ones that have returned, instead of just the current call stack. So
the *ahem* "call stack" ends up huge (and hard to use). And there's two
things that make it far bigger than it even needs to be:
1. There's a big data structure I sometimes need (data that doesn't actually
change - so it's converted automatically at build-time from a raw datafile
to a direct hard-coded Haxe source file). But Haxe, and presumably PHP,
doesn't allow compex literals. And even if it did, there's no such thing as
pre-compiled PHP, so there's no such thing as a statically-initialized data
segment. So the generated Haxe code has to actually build up the data
structure at runtime. And the structure is somewhat large...and there's a
limit on function size (don't recall if it's a Haxe or PHP limit)...so each
piece of the data-building has to be put into it's own function. And there's
currently hundreds of these little functions. So that makes the "broken
stack trace" that much bigger and slower to build.
2. Haxe has runtime reflection, which is needed for it's, rather good,
object database API. But the reflection works by keeping the info stored
as...get this...XML...and then the XML is parsed to retrieve the actual
data. Which is incredibly stupid, of course, but that's how it's done. And,
of course, there's recursion involved in that XML parsing, so that bloats
the big slow broken stack trace even more.
Although, all that reminds me, servers (especially shared hosts) can also
have memory limits on scripts and CGI. But D's GC likes to just keep
grabbing system RAM and only release back to the OS when really necessary,
or when you tell it to. And even that can be blocked by false pointers. Have
you had any problems with server memory caps and D's memory behavior?
