5 ms·
> Focus more on libraries, frameworks, and applications I think this is the most important thing. Say I'm writing a web app -- I want a language that can run o
by cabalamat 5y ago
> Focus more on libraries, frameworks, and applications
I think this is the most important thing. Say I'm writing a web app -- I want a language that can run on both the server and browser and that has a web framework.
Or say I have a database -- I want a language that can talk to it.
Or say I have to interface with some data format, such as .png -- I want a language that has libraries that can read and write it.
- lycopodiopsida 5y agoIt is maybe unfair to Racket, since it seems to have a lot of batteries included: it can produce stand-alone executables out of the box, has a working cross-platform UI toolkit, a packet manager, good documentation and an IDE... All this while being, strictly speaking, an academic research language.
- rscho 5y agoAnd constantly improving despite the small size of the Racket community!
- mumblemumble 5y agoIt's maybe also speaking past what Racket really is? It's first and foremost an academic project. It's not really the job of the core team - mostly academics - to implement a all those utilitarian bits on top of the language. Their job is to work on ideas in the design of the language itself. Ideally, then, that work enables whatever wider community of non-academics it can attract to build web frameworks and database bindings and whatnot. That said, I do get the impression that Racket hasn't done anywhere near as good a job of carrying things through to that second step as comparable communities such as Haskell and Pharo have. The rumor mill would seem to suggest that the project's leadership engenders an ivory tower culture; and perhaps there's something to that? By contrast, even as someone who still hasn't finished learning Pharo and isn't really active in its community, I've still managed to have some direct (if small) interactions with Stéphane Ducasse, and that does, in some subtle way, leave me feeling more personally motivated to contribute to the project.
- rscho 5y agoMatthew Flatt and most of the core team are readily available through slack or the mailing list and often answer themselves, even to newbies. Being a hobbyist myself, I think this ivory tower reputation is undeserved. Few people really understand racket under the hood because it's the product of the greatest minds in scheme. That makes the pool of 'experts' people can query very small, and I think it's honestly too much to ask from the core team to answer to everyone. Racket teaches humility and perseverance, which I find to be a very good thing.
- memling 5y ago> > Focus more on libraries, frameworks, and applications > I think this is the most important thing. Say I'm writing a web app -- I want a language that can run on both the server and browser and that has a web framework. One of the things that bugged me initially about Racket (and still kind of does) is the implicit typing of some of the functions. Take `length` for example: $ racket Welcome to Racket v7.2. > (length "asdf") ; length: contract violation ; expected: list? ; given: "asdf" ; [,bt for context] If I wanted to get the length of the string, I have to use `string-length` instead. (Same with vectors and other sequences.) I personally favor default abstract protocols over explicit type: $ sbcl * (length "asdf") 4 I know that Racket's `sequence-length` will do the same thing, but it feels like a misnomer to have `length` really mean `list-length`. It introduces cognitive load where it's not desired, usually, and tends to make my code longer (slower to read, slower to type, etc.). Maybe this is a silly peccadillo, but as I wrestled with Racket over time I found myself frustrated by this in a way that Python, say, didn't. It's these sort of bits that I'd like to see sanded away, and not the parentheses, to make for cleaner, easier-to-read, easier-to-write code. More concise syntax for indexing and other such things could be nice, too! Standard means for accessing nested hash tables (here's looking at you, deeply nested JSON! Who wants to `(hash-ref (hash-ref some-hash key1) key2)`? Yes, the language can accommodate more concise idioms through macros, but it seems reasonable to have standards around this access. I really, really want to use Racket: I'm attracted to DSLs (maybe moth to flame) and boilerplate reduction, but it's been a challenge to get over these humps.
- samdphillips 5y agoYou're critique is valid. `length` `vector-length` and `string-length` are from the very monomorphic old Scheme libraries. The Racket module system does provide ways to use the names you want without having to change the core language. The `collections` package (https://pkgs.racket-lang.org/package/collections https://pkgs.racket-lang.org/package/collections) also smooths over some of these issues.
- memling 5y agoThanks for the tip! I'll look over the collections package for sure. It looks like some of the things of interest to me are there already. I knew there were historical reasons behind some of these things (just like the old complaints about car and cdr not being called first and rest). Sometimes it feels like this hewing to history comes with some baggage that makes adoption a little more challenging. I find myself writing the following in some of my projects, for example: (define-syntax (hash-ref* stx) (syntax-case stx () [(_ hsh k1) #'(hash-ref hsh k1)] [(_ hsh k1 k2 ...) #'(hash-ref (hash-ref* hsh k1) k2 ...)])) So that I can do something like: > (define hsh '#hash((a . #hash((b . c))))) > (hash-ref* hsh 'a 'b) 'c I feel a little silly each time because it seems like the sort of thing that should just "be there," in the way you can do something like hsh['a']['b'] in Python. Of course there are ways to make it a bit more like Clojure--I think Greg Hendershott created a Clojure-like layer called rackjure--so that you can access using the variable name, etc. It would be nice to have something standardized to make the ergonomics nicer.