>> Erlang has Wings 3D.
>
> That's not quite a large app, but I digress.

Not "large", but certainly widely used, and not just by Erlang fans.

>> I have literally no idea what a "web framework" is. I don't know
>> anything about Ruby, and I have no idea what Rails actually does.
>
> We all know how much you enjoy knowing nothing and still brag about it. :)

I'm just pointing out that I have nothing else to compare it to, that's 
all. Not *everybody* has used Rails before. :-P

>> 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.
>
> Just imagine letting thousands of different users compiling their own
> "pages" into your single blob exec.

Yeah, I'm guessing the result is extremely fast page loading times, and 
a system administration nightmare behind the scenes...

Then again, presumably the answer is to split the server into smaller 
components, and have them talk to each other via SCGI or something.

>> 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.
>
> yeah, well, guess at some point in our lives we all did the pure C
> approach to web programming, just to better understand how it all works.
> Blazing fast, but slow as hell workflow...

Except that in C, you will waste most of your time tracking down silly 
typos that the compiler isn't smart enough to protect you from. In 
Haskell, you "just" have to worry about the sheer inefficiency of trying 
to repeatedly tweak code that has to go through a compiler.

[Well, no... you *can* actually run it interpretted. I'm guessing that 
would be spectacularly slow.]

>> It still seems like a rather heavyweight approach.
>
> still better.

Sure. But perhaps not "best". For example, the person who writes the 
HTML templates needs to know Haskell. Not just the guy who writes the 
application logic.

>> The templates make use of Haskell's "quasi-quoting" feature.
>
> quasi-quoting is a TM from Lisp industries... :)

I doubt that what Haskell calls "quasi-quoting" actually works the same 
way as Lisp. Much like C++ functors are nothing like what Haskell calls 
functors...

>> One of the features the manual makes a big deal of is "typesafe URLs".
>> Essentially, instead of using strings to refer to things, you create
>> data structures which represent valid URLs.
>> And I *don't* mean that you have a data structure which represents the
>> parsed pieces of a URL. I mean you have a dummy data type called
>> "HomePage", and then a data type called "UserProfile" with a user ID
>> field, and then a "Topic" with a topic ID field. And then you tell
>> Yesod how to convert "UserProfile 42" into a URL, and how to convert a
>> URL into a UserProfile 42 again.
>
> that is a fine feature. But I still prefer regex. :)

And I still hate regex with a passion. :-P

Being more objective... Haskell can warn you at compile-time if your 
patterns overlap. Or do real parsing on data fields. And the order in 
which you specify patterns is guaranteed not to matter. And the compiler 
can optimise out repeated tests at compile-time. And...

>> Yesod provides other goodies. For example, it has a "widget" concept.
>
> oh, how original.

I know, right? Who would have thought of that?

>> There's also a "session" feature which lets you store key/value pairs
>> in a cookie.
>
> OHMY, php devs should sue them!

I don't know, most systems I've seen [i.e., not many] make it 
unnecessarily difficult to do something as trivial as set or get a 
cookie value.

>> Given this assumption, it comes as no surprise that Yesod hasn't even
>> considered the possibility that a schema might change at run-time. But
>> then again, if it does, what can you actually do about it? Either the
>> tables and fields you need are present, or they aren't. If they
>> aren't, that's pretty much *got* to be a fatal run-time error.
>
> every framework has their own way of doing things. You either comply or
> go on your own. Don't battle the tool, use it.
>
> anyway, most frameworks have the same problems with databases.

Yeah, figures. After all, a database is only for running websites, 
right? It's not as if at some point somebody in the back office is going 
to want to know how many users logged in today or something like that...

>> Then there's JMacro, which allows you to embed JavaScript directly in
>> your Haskell source file, and have it syntax-checked at compile-time.
>> (I.e., the final JavaScript sent to the web browser will never have
>> syntax errors; these errors are caught at Haskell compile-time.)
>
> the amazing thing about these typesafe nuts are that they are so
> determined to the point of even basically writing syntax checks for
> foreign languages! o_0

What, like it's hard? JavaScript is a fairly small language.

> but they are too lazy, why not also provide type safety for javascript?
> Do not stop at syntax checks, go down to the guts of type checks as
> well! :D

Not possible. Determining whether an arbitrary program is safe-typed is 
undecinable in the general case. (Type systems make it decidable by 
arbitrarily rejecting certain safe-typed programs because they are not 
well-typed, and well-typeness is [designed to be] decidable.)

>> So there you have it. It seems there's quite a few web frameworks out
>> there now. And I just can't help noticing that *all* of the example
>> code I've looked at is really very, very long and difficult to follow,
>> considering the trivial amount of functionality it actually
>> implements... o_O
>
> ruby on rails is simpler. :)

Perhaps. But is it *better*? ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message