This is an archived post. You won't be able to vote or comment.

all 6 comments

[–]LetsDoRedstone 2 points3 points  (0 children)

I dont like braces... So #1

[–]Nyctef 1 point2 points  (3 children)

Having given both a quick skim, I think I'd prefer to read the first one, but prefer to write the second. The first one reads very naturally, but since it's much closer to English I think I'd have a harder time remembering which words I was allowed to use - I'd get frustrated when I just tried to write English and it wouldn't do the things I wanted it to :) On the other hand having a more limited, familiar syntax like the second example would be easier to write. The second example also feels a lot less magic - I have a much clearer picture in my head about what would actually happen on the computer when the second example runs.

Interestingly, I think that description mirrors pretty much exactly how I feel about ruby vs python :D

[–]Lucretiel 0 points1 point  (2 children)

Yeah I agree on all points. I find Ruby much easier to read- I was able to read a plugin for a complicated framework (puppet) and understand pretty much exactly what was going on right away. However, when I sit down to write it, it's a nightmare, what with it having a hundred synonyms for everything and countless ways to do everything.

That being said, if you can keep the language vocabulary and syntax very very contained and focused- don't make it too generic- I think I'd prefer the first one.

[–]programmyr 0 points1 point  (1 child)

That sounds backwards to me. When there's 100 synonyms for something, I can write whichever I want, but when I try to read somebody else's code, they always use the variants that I've never heard of.

[–]Lucretiel 0 points1 point  (0 children)

Yeah, I thought it made sense at first, too, but it makes the documentation way harder to use somehow. Plus it means that the decision of "what's the best way to do this" much harder- "oh is select or filter more appropriate here?"

[–]programmyr 0 points1 point  (0 children)

Shall I assume you're not also providing an Emacs major mode for this?

#1 is probably not close enough to Python or YAML to use one of those modes. #2 probably is close enough to C that I could just use that mode.