On 11/17/2011 6:21, Invisible wrote:
> Erlang has Wings 3D.

Errr, no. Erlang has the north american telephone switching system. :-)

> this becomes an interesting instance of Darren's "static typing is
> pointless" problem.)

Indeed, this is exactly the point I was making.

> an API reference document generator

And that is why documentation sucks these days. Those aren't documentation 
generators. Those are documentation extractors. If you don't put the 
documentation in before you run it, you don't get any documentation out.

> Yesod does it differently. Templates are Haskell source code. They can be in
> separate files or inline in your main program, but either way, every
> template gets compiled into executable machine code.

This is how most systems that compile templates work, including Java and 
ASP.NET.

> damned time you change anything in any template anywhere, you have to
> recompile that template, and relink the entire executable.

Except that because Java and .NET don't do type erasure, you don't have to 
actually relink anything but the one script. And ASP.NET even notices the 
executable changed and reloads it (or notices the source changed and 
recompiles it and reloads it), letting existing transactions finish and new 
transactions power up the new code.

> By default, the Warp web server is used. Since this is written in Haskell,
> the end result is that the web server, application logic, presentation
> templates and static files are all compiled into one giant binary
> executable. When you run this, it opens a TCP port and starts listening for
> HTTP requests.

Very convenient for deployment, you must exist. If you're writing an 
application (like, a wiki manager say), distributing it this way is an 
excellent way of doing it.

> It also means that any time anything in any template changes, that template
> must be recompiled, and then the entire program relinked. And then you have
> to shut down the running server and fire up the newly compiled on.

Generally not a problem, really.

> All of which seems... a bit strange, to me. Then again, if you want to use
> Apache, you can build your application for Fast-CGI instead. Then only the
> application logic and presentation templates get linked into a giant binary
> blob, and you don't have to restart the entire server to update. It still
> seems like a rather heavyweight approach.

If you need better than that, you're probably doing it wrong anyway. Or you 
should be using something like Erlang instead.

> worst thing that can happen is that you say UserProfile 138, and there
> *isn't* a user number 138 at the moment.

Or the user dicks with the URL and bypasses something in your code you 
thought would be enforced.

> Similar to all this, Yesod uses the type system to distinguish between raw
> text which needs to be escaped before being inserted into HTML / CSS / JS
> (with the correct escaping rules for each one), and text which is already in
> such a format (and must /not/ be escaped, because that would mangle it). So
> there's one syntax for inserting stuff into a web page, and the type system
> detects whether it needs to be escaped first.

*That* is the sort of thing static typing is good for. That's the problem 
hungarian naming conventions were trying to solve for languages that 
couldn't distinguish "integer number of elements in the array" and "integer 
value of blue component of that pixel".

> Amusingly, there's a system to run a template, take an MD5 hash of the
> inputs to it, and save the output to disk so it can be cached on the server
> side for faster delivery, and on the client side for reduced server load.

I was doing that many, many years ago. Before HTML had <FORM> tags. Indeed, 
if you look up "REST" interfaces, that's basically what they're about.

> Why can't you do that already?

Because you can? :-) Heck, "widget" is even the standard term for it. Heck, 
sophisticated systems like ASP.NET even have compile-time attributes on the 
widgets so you can use tools to lay them out on the screen at compile time. 
(E.g., your calendar widget would declare how big it is and what type it 
manipulates so your IDE can do the right thing with displaying it while 
you're designing the web page and dragging stuff around.)

> widget concept handles taking lots of widgets and putting all the CSS in one
> place, all the JS in another place, etc.

And GWT takes Java, compiles it into javascript and CSS and HTML, compresses 
each of those, and bundles it into one big file. Same idea.

> Again, I'm unconvinced of how well
> it really works, but I admire the idea.

Given that pretty much everyone in the world does it this way, yah, it seems 
it's an idea that's here to stay. :-)

> There's also a "session" feature which lets you store key/value pairs in a
> cookie. The interesting part is that the cookie is encrypted with a key only
> the server knows (so clients can't see what's in it), and signed (so clients
> can't change the contents). It adds overhead, but I don't think I've ever
> seen it this easy before...

ASP.NET.  It's exactly that. You just tag the variables you want to store 
there, and when the user posts back, the framework fills in those variables, 
then gives you notifications as if it's a desktop app and the user just 
typed new values in.

> The interesting question, of course, is "what happens if the schema
> changes?" It seems Yesod is *assuming* that the schema will never change
> unless Yesod changes it. (I presume I don't need to point out how
> jaw-droppingly flawed such an assumption is.)

That's the other half of the "static typing isn't that useful" rant, you 
see. That's exactly what I was talking about there, if you go back and read 
again. :-)

> - Just blindly munging the schema as you see fit is fine for small toy
> applications. I wouldn't dare do such a thing in a production environment,
> however. Perhaps the extra fields in the DB but not in Haskell are used by
> somebody else? We really shouldn't just go and delete them just like that...

Exactly. Almost nobody who builds these things ever thinks as the database 
as soemthing other than a convenient place to store their data. All the 
"NoSQL" people who don't need ACID all assume they are the only application 
using the database.  As soon as sales and manufacturing and shipping and 
warranty returns and customer billing are all updating the same database, 
you probably don't want to be randomly changing the schema.

> Still, given the current crazy for "no-SQL databases" (i.e., "we don't need
> no stinking coherent theory of operation!"), I guess this point is lost on
> most designers...

Everyone thinks they're google. :-)  Funny thing is, even the nosql data 
storage at google has schemas, because you couldn't even manage it 
otherwise. "Why is my database suddenly 3x the size it should be?"

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message