3 ms·

> Racket does not suffer from the issues of incompatibility Just pick any language implementation exclusively -> no more incompatibilities. > With Common Lisp

by lispm 9y ago

> Racket does not suffer from the issues of incompatibility Just pick any language implementation exclusively -> no more incompatibilities. > With Common Lisp it comes much earlier than is typically expected by programmers today. StackOverflow is more likely to be a first attempt at problem solving than Steele's Common Lisp the Language. Well Steele's Common Lisp the Language is outdated anyway. Today one uses the ANSI CL standard, which is less confusing than CLtL2, which was documenting a language in flux. Actually I don't think Common Lisp users will need to refer to documentation earlier than Racket or any other complex programming system (Java, Scala, Haskell, ...). I have seen now a lot of people coding Java and I can tell you that documentation-less attempts at development don't work well. Many of the programs and coding styles I have seen are just horrible. It's actually kind of sad. I have seen senior Java developers not knowing how the language works at basic levels, even though they claim to work with complex frameworks. Recently I have interviewed a professional Java programmer with a few years experience and he had lots of free time at work. He could have read some books to learn something instead of looking out of the window, but he said that he wasn't interested in computer science anyway... though it might have been a joke, I fear it was serious... Anyway, he was a nice person and had some potential.

pjmlp 9y ago
You are kind of right, the problema is when that great library that would solve your problem that should already been written last week, doesn't work with your implementation of choice. This is one of the reasons I started to only use vendor SDK languages for production code, in spite of the languages not being as good as some alternatives.
brudgers 9y ago
There are a host of good reasons not to choose Racket. An intent to explore the Lisp family of languages is not among those within a standard deviation or two of the median. Likewise approaching the Lisp family of languages with tooling expectations in the fat part of today's Bell Curve probably makes Common Lisp a more frustrating tool than is necessary. In different circumstances, the value of tradeoffs would be different...for example reading an ANSI Standard might be perfectly acceptable as an alternative despite being on the long tail of ordinary practice for someone coming from "the JS, Java, Python world" -- with particular attention to the ECMAscript standard.

by lispm 9y ago

pjmlp 9y ago

You are kind of right, the problema is when that great library that would solve your problem that should already been written last week, doesn't work with your implementation of choice. This is one of the reasons I started to only use vendor SDK languages for production code, in spite of the languages not being as good as some alternatives.

brudgers 9y ago

There are a host of good reasons not to choose Racket. An intent to explore the Lisp family of languages is not among those within a standard deviation or two of the median. Likewise approaching the Lisp family of languages with tooling expectations in the fat part of today's Bell Curve probably makes Common Lisp a more frustrating tool than is necessary. In different circumstances, the value of tradeoffs would be different...for example reading an ANSI Standard might be perfectly acceptable as an alternative despite being on the long tail of ordinary practice for someone coming from "the JS, Java, Python world" -- with particular attention to the ECMAscript standard.