Arc Forumnew | comments | leaders | submitlogin
2 points by thaddeus 4121 days ago | link | parent

I can only contribute my opinion for a few items:

> "I would say Racket is exactly the language the article is begging for"

Racket does not provide any real depth for libraries. There's a lot of promoting for library depth, but as soon as you attempt to do anything practical you soon realize the available libraries are either really rough drafts or are largely out of date. So I don't believe racket meets this criteria highlighted in the article.

> "This also means Lisps should have an object system."

I'm guessing here, but I believe he's referring to an object system that incorporates high level features such as objects + instances with inheritance etc etc. He should probably read pg's Common Lisp book where I believe pg suggests that a oo-system is a great architecture that is well suited to a small set of projects and unfortunately programmers have learned to apply that system to everything they do simply because the oo-languages force them to do so (what they learn is what they know). He goes on to suggest that most projects would be more aligned with FP language paradigms (ie don't force extra layers of complexity where it's not required). And additionally that these oo features are easily implemented in FP languages should you want them ... Don't quote me on all this...I'm going off memory from reading his book over 5 years ago.

It also could be that he sees other FP languages having oo-systems ... I.e. Doesn't racket have the cobra or corba? for an oo-system? Never used it; so again I'm just going off memory here.



2 points by rocketnia 4121 days ago | link

"Racket does not provide any real depth for libraries. There's a lot of promoting for library depth, but as soon as you attempt to do anything practical you soon realize the available libraries are either really rough drafts or are largely out of date."

I've gotten the same impression of Racket libraries, but going by the article, mass-marketing of Racket would be a good way to end up with active libraries: "In other words, if you have people who need libraries, hackers will write them. When you have more libraries, your language looks more attractive to people who need them, so hackers write more of them[...]"

This rings true for me. I think Arc has experienced this phenomenon firsthand.

Anyway, although Racket lacks a variety of libraries, it has an impressive selection of features out of the box.

---

"Doesn't racket have the cobra or corba? for an oo-system?"

Racket has at least a few systems for stateful values with user-defined fields:

Scheme-style structs -- http://docs.racket-lang.org/guide/define-struct.html

Hash tables -- http://docs.racket-lang.org/reference/hashtables.html

Classical OO -- http://docs.racket-lang.org/guide/classes.html

Personally, I consider some of Racket's other systems to be on par with object systems in terms of supporting whole styles of program development:

Contracts -- http://docs.racket-lang.org/guide/contracts.html

Types -- http://docs.racket-lang.org/ts-guide/index.html

Reactive event handling -- http://docs.racket-lang.org/frtime/index.html

Continuations of various kinds -- http://docs.racket-lang.org/reference/cont.html

I haven't used any of these systems (aside from hash tables, I guess). I rarely use Racket, and when I do, I'm still getting the hang of its module system, lol....

-----