Code should not look like that. Such code is too difficult to understand - even in C I've rarely seen such a mess.
The style of programming that in any way values a lot of weird unreadable characters is a relic of the past, and it is not in any way related to skill level or intelligence, as a lot of people seem to think.
Code should always be made as clear as possible first, and should only be made more obscure when performance is critical, and there is no clear way of writing the same block.
You're entirely right, of course. But I don't think Camping designed to be used for normal applications. Camping is Camping partly because its unusual and hacky. It's a little more like an experiment than a business solution.
There is no "code should". Code is just a medium; it is under no obligation to you.
I think sometimes developers forget about coding as a means of artistic expression. I love Ruby for pretty much the exact same reasons so many of you dislike it: It's an amazingly expressive language and code like this is nothing but art.
It's not better, it's _awesomer_. I'm so tired of all this scalable, readable, fully tested code (which of course is good), that I find these small, wicked snippets so entertaining for the hacker part of my brain; and after all, this is the true reason I code: for fun.
this kind of thing is good to write a blog post on, but when else is it useful? I think it is irresponsible to choose "_awesomer_" over "scalable, readable, fully tested" for anything that is supposed to be production quality (don't know the status of the particular project in question).
You may end up with non-scalable, unreadable, and/or untested code in a production system for a number of reasons. Some I can think of off the top of my head include performance and schedule pressure. Introducing it for fun sounds like bad news bears to me.
Most of the time you get non-scalable, unreadable, and/or untested code in a production system because you're not very good and you don't step back and look at interesting/different ways to do things. "Awesomer" isn't a good reason to do things, but it's probably the original source of some of the things we like about Python and Ruby and Lua and IO and Potion . . .
In our daily lives, we strive for quality in what we do. We cook aiming to make delicious food; we build to produce something durable and attractive. When I program, I aim to produce something of high quality: Performant, readable, simple, and reliable.
We also get drunk and do stupid things. Some of us also enjoys reading obscure poetry. Or listen to brain dead No Wave-music or spends two hours listening to this new awesome Japanese records played on two spoons. That's not 'attractive' or 'simple' or anything else that would fit into your hipster life in that black/white attic of yours, listening to 'hip' music and drinking that fabulous red wine (which probably sucks) and enjoying the shit out of your Good Life (tm)
let Right x = paramTree [("a[x]","b"),("a[b]","c"),
("a[b][c]","d"),("bc[de]","f")] in putStrLn (drawTree x)
{ "a" => { "b" => <conflict>, "x" => "b" }, "bc" => {
"de" => "f" } }
Interesting. Could you have implemented drawTree with Language.Haskell.Pretty? Also I get the following error with ghc:
yc.hs:35:34:
No instance for (Monad (Either String))
arising from a use of `mapM' at yc.hs:35:34-52
Possible fix:
add an instance declaration for (Monad (Either String))
In a 'do' expression: keys <- mapM parseKey names
In the expression:
do keys <- mapM parseKey names
return (toTree (zip keys values))
In the definition of `paramTree':
paramTree nameValues
= do keys <- mapM parseKey names
return (toTree (zip keys values))
where
(names, values) = unzip nameValues
(Edit: I'm sorry that the error message's whitespace gets messed up here.)
Also your groupings function is only used in conjunction with Data.Map.fromList. Did you consider using something like
Data.Map.fromListWith (++)
instead? Of course you'd have to wrap your would-be Map values in singleton lists first.
This is how I would approach such an issue with php. This assumes it would be run through eval or written to file and included. Obviously to make this valid php I would replace { with Array( and } with ) -- but I decided to stick to the spec above for arguments sake.
The style of programming that in any way values a lot of weird unreadable characters is a relic of the past, and it is not in any way related to skill level or intelligence, as a lot of people seem to think.
Code should always be made as clear as possible first, and should only be made more obscure when performance is critical, and there is no clear way of writing the same block.