Re:When in doubt, turn to _why
by markessien on Wednesday January 21, 2009 @04:58PM
(#443884)
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.
Re:When in doubt, turn to _why
by jon_dahl on Wednesday January 21, 2009 @05:45PM
(#443959)
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.
Re:When in doubt, turn to _why
by cubicle67 on Wednesday January 21, 2009 @09:57PM
(#444259)
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.
Re:When in doubt, turn to _why
by judofyr on Wednesday January 21, 2009 @05:16PM
(#443909)
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.
Re:When in doubt, turn to _why
by jacobscott on Wednesday January 21, 2009 @06:33PM
(#444029)
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.
Re:When in doubt, turn to _why
by bjclark on Wednesday January 21, 2009 @11:28PM
(#444359)
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 . . .
Re:When in doubt, turn to _why
by thomasmallen on Thursday January 22, 2009 @12:05AM
(#444389)
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.
Re:When in doubt, turn to _why
by ichverstehe on Thursday January 22, 2009 @05:30AM
(#444611)
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" } }
Re:When in doubt, turn to _why
by eru on Thursday January 22, 2009 @05:38AM
(#444616)
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.
Re:When in doubt, turn to _why
by shaunxcode on Wednesday January 21, 2009 @10:51PM
(#444322)
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.
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.
This was the first time I’ve ever heard of the merge block. It’s not even properly documented! But it’s a very simple and very powerful feature...
...doesn't inspire confidence. :)
Some context might help: http://redhanded.hobix.com/bits/campingAMicroframework.html http://github.com/why/camping/tree/master
How is it better then?
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.
The same applies for code.
Valid keys would be:
I hope I got the spec right. Pretty tired right now, been coding all day. :)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.
$parsed = str_replace('{', '{"', '{'.str_replace(Array('[', ']'), Array('" => {', ''), $string)) .str_repeat('}', substr_count($string, '[')+1);
Here's an example of a nested hash: "XXX". Here's what normally happens in Rack: "XX". Here's what we want to happen: "XX". Here's a couple solutions.
Ding, now everyone is clearly on the same page, instead of reading the article twice trying to figure out what's going on.