A Haskell Programmer Tries to Learn Racket

I've recently worked on a few web apps which use ClojureScript/Clojure on the the client/server. Prior to that I mostly worked on web apps that were CoffeeScript/Python.

The first difference I took note of was how easy and seamless it was to move EDN structures back and forth between the client and the server. Of course this is a pretty minor difference as it's not exactly hard to pass JSON back and forth from CoffeeScript (or Javascript) to Python.

But then I started using Prismatic's Schema library. Schema is essentially a lightweight (gradual/optional) type system. Schema is written in cljx which means it works with both Clojure and ClojureScript. This means I could write my schema definitions once (also in cljx) and use them on both sides of the pipe. Schemas end up being similar to class hierarchies in an OO language. (So, for example, in one project I had a User schema and a Project schema and Project's had an "owner" fieldthat was a User, etc).

This ended up being really nice because now I still get the full dynamicity of Clojure(Script) but everywhere that I'm dealing with these core "types" I can validate the schemas. So I validated them going in/out of database access functions, I validated them going in/out of the server, in/out of the client, in/out of various specific functions on both the client and the server, etc. Wherever it made sense.

Of course in my old CoffeeScript+Python days there was nothing stopping me or anyone else from writing something like Schema and implementing both CoffeeScript and Python versions but it would be a lot more work upfront and in perpetuity to maintain 2 versions. But be that as a it may, for whatever reason, this type of tool doesn't actually get created that often in more heterogenous environments. (And I would argue they on balance, not as powerful/effective/simple/etc when they are created in those environments).

But honestly, for me personally, I think the biggest benefit of using a single language is just the reduction in mental baggage and context switching you have to deal with. I never found CoffeeScript+Python (or Javascript+Ruby or Javascript+Java or whatever) particularly challenging or wearisome while I was working with them, but having now accumulated a significant number of hours on the ClojureScript+Clojure combo it's very noticeable when I go back and work on old heterogenous projects.

Of course the plural of anecdote is not data, and my experience is definitely biased by the fact that Clojure and ClojureScript are just such a pleasure to work with all around. In the end though, while I'm not personally a fan of Javascript or Node.js, I now fully understand why the people that like Javascript love Node.js for giving them the gift of single language development.

And a lot of the use cases aren't sharing code or even have a client/server setup. Like crappy non-parallel build systems being written from scratch using Nodejs.

This thread's been a bit illuminating. I guess I'm not missing anything technical. Some people like JS I guess and Node exists so why not use it.

It's an ugly-ass buggy website, but that is largely to do with the implementation and PG's propensity for live-modifying production sites in the REPL and not the runtime itself.

I think the most important line for me is about wanting computers to be like lego blocks. I think that's an admirable goal and I think that if Node as a community of programmers and projects owned that more ("We're Mindstorms, not NASA, here!") it'd get a great deal of love from the rest of the community.

Sadly, that probably won't happen since Mindstorms sounds diminutive and no collection of people has an ego so in check.

It's not exactly an advanced and polished system, but it still has a feature that is hard to get with others.

Even in an environment like the JVM which specifies a lot of stuff for you, it's awkward to call into Clojure from Java because of the semantic differences.

    (define side-effect (cons print "This is not an IO monad"))

    (define its-already-generic (cons number->string 4))

The mistake is to take the ideological fanaticism of Lispheads for ideological purity of the language. There is none. Even the great schism of Lisp1 versus Lisp is rooted largely in arguments from precedent...and precedent for Lisp is largely that it can shave a few precious bytes and register loads by allowing a single symbol to point to more things.

[1] Or Cobol.

I think their usage is sometimes a code smell (the ad-hoc structs I mentioned), but they're really useful when you want to deal with an "unlispy" list of tokens (say, a parser for a language that isn't Lisp).

About the same.

    (defn message [text & {:keys [style color]}]
      ...)

    (message "Text" :style :bold :color :red)

http://frank.kank.net/essays/hash.html

Mind you - reader macros should be used with a degree of care otherwise you basically create completely new language. I remember working on a project where I got a drop of some code from one of the other organizations in the project (by tape, this was a long time ago) opening the file and wondering what language the code was written in and taking a while to realize that it was indeed Lisp - but one that had used reader macros to do strange and terrible things.

Mind you, once I learned about reader macros I went on to do my own crazy stuff with them - they are almost too powerful a feature (almost!).

http://en.wikipedia.org/wiki/First-class_data_type

Hash-tables are part of the standard, and available in conforming implementations out-of-the-box. (make-hash-table) produces an instance of a table which can be passed as argument to function, be assigned to variables, ... I don't think syntax defines what feature is or isn't first-class, even though it has an impact on it's usage.

Adding support for litteral hash-tables is possible, as it was already said: define a reader macro; that macro could even simply use the utility function "plist-hash-table", from Alexandria, which is used like this:

     (alexandria:plist-hash-table '(:a 1 :b 2))

On the first hand, people say that CL is bloated, but on the other hand, they want to have everything available by default. Do you expect Python or C++ implementations to come with regular expression built-in, or is it okay if you need to add an 'import' statement or link with Boost?

CL allows you to define libraries that can change even the basic surface syntax, for your convenience. Considering that there is more than enough defined in the specification, what benefits would be in having an "official" hash litteral syntax? consistency accross different projects? many people use the "cl-ppcre" regex library without problem.

Yes, regular expressions come in a library even though they could easily be labelled as a fundamental feature of a language, and hence be expected to be "first-class", or "built-in"; but again, that is not the case in CL, which is neither Perl nor Lua.

And about keyword parameters, this is just the surface syntax, which is on purpose based on a simple, basic representation of the syntax tree as lists of expressions.

Then, the compiler will work with the argument list in your function definition and take one or another approach to represent them in the object code. And I doubt that they are stored in a hash-table, which is unlikely an appropriate way to handle a couple of keyword arguments.

Similarly, when you define a class, everything is declared by a simple list of slots, where slots are lists of parameters: but in fact, the class might store the actual instance slots in a hash-table, an array, a list, a database or a memory mapped file.

The fact that you are mainly manipulating lists does not mean that everything is eventually represented as supposedly inefficient linked-list at runtime.

Named arguments had been introduced to Lisp with MDL (a Lisp dialect, brought to Lisp Machine Lisp and then to Common Lisp).

Using hash-tables for it is a step back from the view of development support.

Yes I agree with your later comment about syntactic blessing and all, but I think you picked a terrible example by choosing the single place in lisp where plists make more sense than hash tables.

So I think that is actually a good argument for introducing option types (like Haskell's Either a b) into the language. I think Typed Racket has something like this, but in either case you'd want some nice syntax to handle it as well.

Hash tables make this sort of thing fairly easy though (at least in Racket)

(define h #hash{["a" . 3] ["b" . 5]})

(hash-ref h k "failed")

I think most lisps support this right? I remember seeing something similar in pg's bayesian spam filter code.

This makes no sense. You want feature X (the ability to return multiple values) without having to either (a) pick apart a simple structure containing those values or (b) assign names to those values, letting the runtime system pick them apart (or never stick them together, its choice) for you. So what more do you want?!

You want an option type, right? Well what's an option type? Let's consider Haskell:

data Maybe a = Nothing | Just a

No matter what kind of cleverness you do in memory or whatever, in the end this type is a tuple of two values: (constructor, data). The only special thing going on is that the type system makes sure that (a) constructor == Maybe or constructor == Just, and (b) if constructor == Maybe the data field is meaningless (has no type, can't be read, does not effect equality, whatever).

But it's still a tuple. The cons cell is the exact same thing in the absence of a strict compile-time type system, except for your code example we have it flipped: (data, constructor) (well, actually you seem to have a flipped 'Either String a' going on there, but let's stick with option for now) where data is actual data or nil when meaningless, and constructor is like Just when nil and like Nothing when true (btw, lisp convention is the other way around; second value is true like Just and false/nil like Nothing).

Just like the original linked article, what your complaint boils down to is "non-compile-time-typed systems allow you to do things which would break compile-time-typed systems"—and while I love compile-time typing as much as the next Haskell aficionado, I don't demand compile-time typing in a language [family] whose very essence is its absence.

EDIT: if you could reply and explain what would resolve this "shortcoming of the language", maybe I could understand better what you're trying to say...