I want to learn scheme but that is too much for me. So either 1. That is badly written code. 2. I'm a bad programmer. 3. Scheme's syntax is ugly. What do you think?
4. The syntax is unfamiliar.
Does anybody find this Scheme code readable?
11–20 of 23 posts
Re: Does anybody find this Scheme code readable?
#12Yep, although I only use Common Lisp, this is still readable to me.
A couple of things could be improved for me; I almost never use abbreviated variable names unless it's for simple iteration.
Also things like this being repeated on 8 lines, just screams for some sort of abstraction:
(set! rsc (+ rsc 3)) (set! rsc (+ rsc 0))) (set! rsc (+ rsc 0))Re: Does anybody find this Scheme code readable?
#13Yes, although I'm not sure why they had to use single letter symbols to identify the different types of chess pieces. Also it seems like they could've applied the DRY principle a bit with all of those conditionals. Also the use of set! is a little bit ugly.
Re: Does anybody find this Scheme code readable?
#14I want to learn scheme but that is too much for me. So either 1. That is badly written code. 2. I'm a bad programmer. 3. Scheme's syntax is ugly. What do you think?
I think "it's hard to read code in a language you don't know." You're fooled on this because so many languages are so similar -- if you know C++, you can trivially read Java and C# and Python, and even languages that are a bit further afield like Javascript and Perl still are heavily influenced by C, so don't seem too odd. But Scheme is a whole new family of languages. It's like being an English reader and looking at…
People say this and it's not really true.
Scheme has mutable state. Scheme has unmarked side-effects. Scheme has variables, as opposed to tags applied to constant values.
Scheme was an entirely new kind of language back when lambda expressions were Heavy Deep Magic and dynamic typing was something you did when your Flexowriter was well-oiled (hyperbole intentional). These days, it's no weirder than Javascript or the more modern dialects of Java or Visual C#.Net. Hell, even C++ is getting lambdas and closures, and that's a Serious Business COBOL-Replacement Language.
Modern Algol dialects are Scheme in everything except syntax, and now that metaprogramming (Ruby, to begin with) is beginning to catch on, I fully expect language designers to re-invent some shambolic version of s-expressions when they realize that metaprogramming in Algol syntax is hard.
Scheme won. It's just that its victory was suppressed for political reasons.
Re: Does anybody find this Scheme code readable?
#15I want to learn scheme but that is too much for me. So either 1. That is badly written code. 2. I'm a bad programmer. 3. Scheme's syntax is ugly. What do you think?
1. From glancing at it: this is a pretty ugly solution.
On the plus side: It's minimal and doesn't spend much time building abstractions on top of the basic lists/etc. that scheme provides. However, it certainly isn't pretty.
For instance: Things like the king & knight checks are really pretty ugly brute force solutions.
Similarly, the variable & function naming really is rather unclear and very poorly commented--some of that may be use of things idiomatic to scheme that I'm unfamiliar with though.
2. Always a possibility, I certainly don't know you. ;)
3. Some people certainly have said that before and probably will again. This is really just a personal preference thing, I think.
Re: Does anybody find this Scheme code readable?
#16I can somewhat make sense of that code, but the code of function ch-hof is a bit hard to read - and the function name is not helping. I guess he's trying to see if the king is under check, and if so by which piece(s).
Also I notice code like:
(- (cdr kpos) 1))
For example:
#;4> (- (cdr '(1 2)) 1)
Error: (-) bad argument type: (2)Re: Does anybody find this Scheme code readable?
#17I can somewhat make sense of that code, but the code of function ch-hof is a bit hard to read - and the function name is not helping. I guess he's trying to see if the king is under check, and if so by which piece(s). Also I notice code like: (- (cdr kpos) 1)) How is that possible? If kpos is a list of two elements to represent the king's position, so (cdr kpos) should be a list, not compatible with subtraction. For…
kpos is a pair, not a list (or if you prefer, is an improper list). It's (cons 1 2), while '(1 2) is (cons 1 (cons 2 empty)).
Re: Does anybody find this Scheme code readable?
#18Looks fine to me, though I tend to write my lisp narrower and taller. Part of that is breaking long argument lists out onto multiple lines with proper indentation.
Here's some Racket code in DrRacket: http://i.imgur.com/GKveHtl.jpg
You get used to it pretty quickly, and good editors will provide paren matching and completion.
Re: Does anybody find this Scheme code readable?
#19I can somewhat make sense of that code, but the code of function ch-hof is a bit hard to read - and the function name is not helping. I guess he's trying to see if the king is under check, and if so by which piece(s). Also I notice code like: (- (cdr kpos) 1)) How is that possible? If kpos is a list of two elements to represent the king's position, so (cdr kpos) should be a list, not compatible with subtraction. For…
The lists are made of cons, but you can make arbitrary trees with cons.
After looking carefully, the kpos is the result of the function find. In this case it's a cons with the row and the column of the king. So the code that runs is more like
(define kpos (cons 1 2))
(- (cdr kpos) 1)
(struct cell (row col))
(define kpos (cell 1 2))
(- (cell-col kpos) 1)Re: Does anybody find this Scheme code readable?
#20I don't think this is code that someone learning Scheme should be reading, it's pretty damn unreadable. Some obvious issues, just starting from the top and continuing for a while:
- Defining a new iteration macro FOR that's used in just a single function, has a very odd syntax, and that's way too generic for uses.
- The first parameter to the PICK function (the position) is a pair. That might make sense if those pairs were values that had been passed throughout the program. But actually every place where PICK is called constructs a totally new pair just for that call. It should be split to separate ROW and COLUMN parameters. This would remove a lot of noise at the call sites.
- Or alternatively, if the parameter is kept as is, all of this boilerplate: (cons (- (car kpos) 1) (- (cdr kpos) 1)) should be replaced by calls to a function that does both the consing, caring and cdring. Something like (add-to-position kpos -1 -1)
- The is-piece-foo functions use eq? and equal? inconsistently.
- The CH-HOF function is full of copy-paste boilerplate with each instance having tiny tweaks. Turning these into calls to sensibly parametrized functions would make a big difference.
- There's like 20 instances of (set! rsc (+ rsc 0)) . What in the world is that supposed to achieve?
- The indentation of IFs is horrible. Putting the THEN branch on the same line as the test, and then putting the ELSE on the next line is just criminal. Especially given how deeply nested some of the condition expression are, it's very hard to notice that it's in fact a two-branch rather than one-branch IF. It's as if this code was deliberately written to be obfuscated.