[racket] "lab notebook on learning process" (was: Re: Macros baffle me)

On May 5, 2014, at 3:05 AM, Artyom Kazak <yom at artyom.me> wrote:

> First of all: I really hope that people won't get dissuaded from learning
> Racket after seeing some posts written by a person who genuinely enjoys
> learning Racket. 


I enjoyed your notes, otherwise I wouldn't have bothered to re-read 
them and write comments. And I can say that others on the 'dev' list
also enjoyed scanning your comments. 


> > ?? I don't get the "Uniform syntax is harder to read" comment.
> > More highlighting, hmph? 

... 

> I completely
> understand that uniform syntax has its benefits, but I imagine there could be
> ways to make it less uniform-*looking* without having to compromise.
> DrRacket's feature which changes colors based on depth of nested brackets is
> awesome at the first glance, but somewhat unusable at every glance after
> that.


I do come from the ugly-syntax world (that's what I call Algol-style, 
sorry C-style, sorry Java-style, or is it Javascript now to younglings?) 
and once I got used to uniform syntax, I miss it every time I read and
want to touch the code. 

I grant you that reading it w/o Algol-style highlighting is hard. That's
what colors in DrRacket are for and S-expression navigation and navigation 
via lexical context (anyone else have that?). 

I will also grant you that when I compare code, say Haskell vs Racket, 
-- without wanting to touch it -- I find Racket code overly 'dense' for 
a lack of a better word, but that is _not_ a problem of uniformity but 
length of naturally chosen [library] identifiers, some choices in keywords, 
and such. 

[I have spent an hour trying to figure out why SML/NJ was blowing up
on me because I used o as an identifier. I am sure Haskell suffers 
from similar problems for novices. Once I realized TABs mattered, I 
switched from Haskell to ML for the Little book.]



> > He wants an Arc-style lambda function. Hmph.
> 
> Does it mean that I'll get an Arc-style lambda function eventually, or that
> I'll get an explanation why it's a bad ide— wait, nevermind, I can get
> whatever I want, 'cause it's Racket. Mwa-ha-ha.

> (I'd still welcome an explanation, tho.)


I don't think saving key strokes in Arc-style fashion is good for
the future reader of my software. But go ahead and re-create the 
syntax or borrow it from the Arc implementation (which is some 
large Racket macro). 


> > He doesn't know what type safety is. I understand that C++ers don't get
> > it. Why do Haskellians don't get it?
> 
> I could argue that there are other shades of “type safety” besides “won't
> attempt to make spaghetti out of your data at runtime”, but since the
> definition on Wikipedia doesn't agree with me, I've updated the post instead.


You shouldn't make this argument. Do something productive instead. 

The phrase 'type safety' has a well-established meaning. If we don't accept 
well-established words we can't communicate. (Google 'progress and
preservation' in this context.) 



> > Why does he think "Performance sucks"?
> 
> Because here's the list of things that are slow


DrRacket is an operating system running on top of your other OS
to make life for Racket developers simple. It was originally developed
for beginners, but I eat my own dog food, and I find it good (tm) for
every day Racket work. 

To evaluate performance, run the programs at the command line. Measure
there. Compare with other dynamically typed languages and report back 
what you find. If you still report performance problems, try to be precise. 
We are proud of Matthew and how far he has pushed Racket's performance on
real software, the kind you use on a daily basis, not just minibenchmarks. 

[Someone else has said so]


> In Haskell it'd be
> 
>    mapM_ (printf "source file: %s\n") $
>      filter (regexpMatch "[.]rkt$") inDirectory
> 
> Not saying one is better over the other,

Laziness is an expensive way to program control flow, but I will 
admit that it looks elegant. The cost of laziness is so large in 
my mind, however, that its benefits are pointless. So when someone
makes an unqualified comment about such issues, I take exception
because I have thought about this since meeting Dan Friedman (he
co-invented laziness and spent a decade exploring its advantages, 
which is when I met him and he became my advisor). 





> And again, an admission of my own impatience and unwillingness to learn the
> basics before going for... well, less basic basics seems to have been taken
> for a criticism of the language. Hm, I am tempted to make a poll at the end
> of third part of this “lab notebook” to see how level of concern that I'm
> “dissuading people from learning Racket” is correlated with reader's
> knowledge of Racket.


It would be much more useful if you simply admitted up front that 
this learning experience is unique and biased because of your way 
of skipping and hopping around material instead of learning the 
basics. A reader can then read your post for the wonderful 
entertainment that it is instead of as the somewhat negative 
treatise on Racket that some think it is. [I don't; I could 
write much worse about Haskell.]



Thanks for undertaking this blog writing task. When you resume
this process, I urge you to post your questions on this list and
I am sure you will get fast and furious feedback -- Matthias