
The Perils of Partially Powered Languages - ColinWright
http://www.yesodweb.com/blog/2011/08/perils-partially-powered-languages
======
polymatter
I find it a little embarrassing that a blog about a web framework fails to
load (though perhaps that's a little unfair considering a HN traffic spike).
Especially since I thought one of Yesods main advantages was performance.

For the lazy (pun intended) his Conclusions are:

\- Java-the-language and Java-the-libraries make a number of simple tasks very
complicated. \- Therefore, we have a number of helper languages, like XSLT and
Ant, to avoid the pain of a pure Java solution. \- However, these tools are
all purposely missing some features we'll inevitably need. \- The result will
be either missing proper handling of some features, a polyglot that will miss
the point of using Java in the first place, or most likely both. \- There are
great use cases for non-general-purpose languages, but they should have tight
integration with a real language. \- Haskell's flexible syntax and great
typing make it very powerful here.

I just spent last weekend putting together a Yesod web app and am very
sympathetic to his mantra. Hamlet is a lovely language (valid HTML is valid
Hamlet so very easy to pick up) that does one thing well, one thing well, and
nothing else. It very easily allows me to go back into Haskell if I need to.
The key is that Hamlet is merely syntactic sugar. Ant isn't just syntactic
sugar, its far more than that, which makes it different.

~~~
jcromartie
If Yesod is about performance, it's not showing:
[http://www.techempower.com/blog/2013/04/05/frameworks-
round-...](http://www.techempower.com/blog/2013/04/05/frameworks-round-2/)

~~~
DannoHung
Be sure to check community commentary on the implementations that were tested
before deriving any conclusions:
[http://www.reddit.com/r/haskell/comments/1bqsvi/web_woes_for...](http://www.reddit.com/r/haskell/comments/1bqsvi/web_woes_for_haskell)

~~~
profquail
_For the lazy:_

The reason for Yesod's poor showing in that benchmark was due to a flaw in the
implementation of the benchmark. A certain function (newSTDGen) was called
repeatedly within each request, even though it should have only been called
once; it's a relatively "expensive" function so this had a large impact on the
results of the test.

In addition, the Yesod test used TCP sockets to communicate with MySQL while
the other frameworks were set to use UNIX sockets. This has also been found to
have a non-trivial impact on performance, as discussed in this SO thread:

[http://stackoverflow.com/questions/257433/postgresql-unix-
do...](http://stackoverflow.com/questions/257433/postgresql-unix-domain-
sockets-vs-tcp-sockets)

~~~
papsosouid
>A certain function (newSTDGen) was called repeatedly within each request

It is called zero times in the json benchmark, which yesod still did quite
poorly on. That is only a factor in the "pull a random thing from the DB"
test. I believe the biggest underlying issue was that sessions are enabled,
which means transmitting more data (the cookie) as well as doing encryption
and HMAC on the cookies. Disabling sessions doubled the performance.

------
fusiongyro
I'm glad I read it, because I never would have known about XProc otherwise,
but a lot of his specific complaints are moot today. XProc apparently supports
directory listing out of the box and there is now a zip module for it. In any
case you could extend these tools with your own code if you wanted to continue
to use them, they all offer extension points (mostly in Java, sadly, but a
directory listing is just a directory listing).

His overall point is not moot but at the same time I'm not all that
sympathetic. As you dig deeper and deeper into the XML ecosystem you learn
that more and more of it is really only there so that there can be an XML
answer for every problem. I doubt many people see the benefits of a
comprehensive XML ecosystem (frankly, I doubt that the benefits are all that
meaningful) but if you don't see the point then you're engaging in pointless
masochism by trying to use it. That he solved his problems by going outside
the XML ecosystem suggests that he doesn't really perceive the benefit of it,
which makes the whole exercise a little circular. "I like sweets and I don't
like vegetables, and I discovered that if I put sugar on my vegetables I like
them better than if I don't." Yeah, that's what I'd expect you'd find.

------
16bytes
I think this article is oh-so-close to making some great points. Using a DSL
like XSLT for XML transformation is a _lot_ more productive than in Java.

"Quite simply, each language is good for its specific task, but can't (easily)
do anything else."

Correct, let XSLT do what XSLT does (transform XML), and fill in the rest with
Java. I've been paying attention to XProc for a long time and seems to be good
fit for what _it_ does, (manage series of XML transformations).

"All I need to do is use that XSLT directory listing function... that function
that doesn't exist."

Well, that's true. I'm surprised that somebody extolling the virtues of
Haskell would miss this point, but XSLT is supposed to be a pure-functional
language. You should't make side-effect/non-deterministic calls during a
transformation. Furthermore, since he discovered the ability to write to
multiple output documents in XSLT 2.0, I'm surprised that he didn't think of
multiple _input_ documents.

The answer here would be to use java to produce all of the necessary input
before the xslt/xproc pipeline. Create a temporary DOM filled with just a
directory listing, you can configure Saxon to select on arbitrary documents
that you create, and do it all in memory. Xproc is meant to make
transformations composable in case you don't explicitly know everything
beforehand, like if there's dynamically generated file content that gets
populated from earlier transformations, but I think it's less useful than
XSLT.

"Contrast this with the DOM model from Java."

Well, an API discussion on Java/DOM is a different matter entirely.

"Ant and XSLT are not designed for modularity."

Yes, they are. They are modular with respect to their domain models.

If the point was "Well, a client mandated the use of Java, but it wasn't so
bad because I was able to do everything in XSLT and XPROC", it would have been
interesting. Furthermore, one might have said, "If XSLT was a DSL written as
an embedded API in a friendly language with extensible syntax like haskell,
ruby or scala, it would have cut out the middle man".

To claim, however, that languages that aren't general purpose are dangerous
becuase, well, they aren't general, is bit of a stretch.

------
chewxy
It's not responding. here's the google cached version:
[http://webcache.googleusercontent.com/search?q=cache:5Jcrt8T...](http://webcache.googleusercontent.com/search?q=cache:5Jcrt8TgClAJ:www.yesodweb.com/blog/2011/08/perils-
partially-powered-languages+&cd=1&hl=en&ct=clnk&gl=au&client=ubuntu)

~~~
gizmo686
That version still tries loading resources from the down domain. Adding the
parameter 'strip=1' (or following the 'text only' link) does not.

[http://webcache.googleusercontent.com/search?q=cache:5Jcrt8T...](http://webcache.googleusercontent.com/search?q=cache:5Jcrt8TgClAJ:www.yesodweb.com/blog/2011/08/perils-
partially-powered-languages&hl=en&client=ubuntu&hs=JrY&gl=au&strip=1)

------
moomin
I think the missing concept here is composability. Hamlet composes cleanly
with Haskell, XSLT doesn't. Although it should be pointed out that Microsoft's
XSLT implementation is more than capable of running arbitrary code.

------
loup-vaillant
> _The magic features that's missing here is sum types. There is no good
> replacement in Java, and it precisely the right tool to model nodes in XML.
> Added to that the requirement to use mutable data structures here and it's
> painful. And don't even get me started on the difference between a null
> string and an empty string in the API._

Yess! <http://loup-vaillant.fr/articles/classes-suck>

Maybe learning Java and its ecosystem isn't worthwhile after all.

------
kodablah
"Contrast this with the DOM model from Java"

More like from w3c (<http://www.w3.org/TR/DOM-Level-2-Core/>), but yes,
shipped with Java. This is like complaining about DOM traversal in JS. There
are other libraries/interfaces one can use for traversing XML other than what
is shipped with the lanugage.

Seems strange to compare languages based on nsomething in a core lib of one
and not in a core lib of another.

