5 ms·

Dynamic typing and parentheses are what keep me away from Clojure or Lisp like languages. How can I get over them?

yawnt 12y ago
parentheses, at least in my exp, just fade away after a while.. there's core.typed which is static typing for clojure [0] [0] https://github.com/clojure/core.typed https://github.com/clojure/core.typed
- namelezz 12y ago
  Thank you for the link. I will look into the core.typed.
- threeseed 12y ago
  Also Prismatic's schema. It achieves some of the same goals for why you would want strong typing: https://github.com/Prismatic/schema https://github.com/Prismatic/schema
  - escherize 12y ago
    +1 for Prismatic Schema. It's not only an awesome way to validate your maps, but it is an extremely good way to write documentation.
- minikomi 12y ago
  It's also very worth looking at Typed Racket and Racket's contracts system! [1] http://docs.racket-lang.org/ts-guide/ [2] http://docs.racket-lang.org/guide/contracts.html?q=contracts
59nadir 12y ago
If you truly have been shunning Lisps because of parentheses I can only tell you that it will start to make sense once you see that they're just lists and that the fact that everything (including your code) is some variation of a list means that you are now (sometimes in the background) able to modify everything as if it was a list. S-expressions are uniform in that they all look the same way. This means you have one form for literally everything in the program and you will have no problem parsing that form. It makes reading, mentally parsing and editing easier because everything is neatly delimited by parentheses. In terms of readability, do you have any particular difficulties parsing the following code? (define (sum/recursive lst [sum 0]) (if (null? lst) sum (sum/recursive (rest lst) (+ sum (first lst))))) We are defining a function, sum/recursive, that will take a list and return the sum of all the numbers in that list. We use a default value of 0 for a function parameter called sum to store the sum. When the input list is empty ('(null? lst)' returns true) we return that variable. There is no return keyword, we just specify that variable and it will be returned. If the list isn't empty, we apply sum/recursive on the rest of the list and as a second parameter we add the first number in the list to the already accumulated sum ('(+ sum (first lst))'). Using matching parens in your editor will make it obvious when you have matched the right amount of parens. It should be noted that Racket, this Lisp variant, uses '[]' as well to delimit certain parts, for readability.
- currywurst 12y ago
  Lisp's super power (homoiconicity) comes at a trade-off of reduced discriminability. A good syntax highlighter and well-indented code (like you provided) reverses this effect considerably, but imho, it still takes a lot of getting used to for beginners. In any case, the bigger part of the being productive in a codebase is to figure out how it encodes the domain, what idioms and patterns are favoured etc. So sometimes, it's just not worth adding another source of aggravation for "new arrivals".
  - escherize 12y ago
    I disagree with regard to Clojure. IME, the fact that it's a lisp doesn't seem as hard for noobs to grasp as immutability by default, or pickup up the functional programming mindset. We usually go for folks who use Emacs, so they may already have an indoctrination. When you compare Clojure to other lisps, I think you'd agree it's more discriminable, given the plethora of literals that dont use parenthesis: vectors [1 2 3] sets #{1 2 3} maps {:key "value" :name "Bryan"}
    - grandalf 12y ago
      I've used clojure for some weekend hacking and have found that the biggest challenge is feeling like my code is non-optimal. I can get stuff to work and could build real stuff in clojure, but I hesitate because I feel that it's not necessarily idiomatic. I guess I need a clojure mentor for the first non-trivial project. There really isn't that much idiomatic web-related code out there to read, and with clojure there is also quite a lot of variation in how systems get designed (b/c of the power and expressiveness available). This is not an excuse, just noting the factor that has turned out to slow me down. If i had more leisure time I'd just power through and build stuff until I arrived (through trial and error) at my own sense of best-practices / design tradeoffs. That has yet to happen but will someday.
- davidw 12y ago
  > S-expressions are uniform in that they all look the same way. If you treat the language as a user interface to your computer, shouldn't things that do different things have different appearances, to help you distinguish them at a glance?
threeseed 12y ago
Time. With Clojure/Lisp languages you are basically starting from the beginning. Most of the approaches you would take to constructing your applications don't work. It just takes a lot of practice for you to recognise patterns and then both the typing and parentheses will seem natural.
lmm 12y ago
Compile-time typing really is valuable, IME. Maybe you should look at Shen? (Can't help you on the brackets. I mostly stick to Scala myself)
afandian 12y ago
There aren't many languages that have radically fewer parentheses than Clojure / LISP. Clojure: (defn blub-extra [a b] (blub (inc a) (inc b))) 8 parens + 2 brackets Scala: def blubExtra(a: Int, b: Int): Int { blub(inc(a), inc(b)) } 8 parens + 2 braces Java: Integer blubExtra(Integer a, Integer b) { return blub(inc(a), inc(b)); } 8 parens + 2 braces Ruby: def blubExtra(a, b) blub(inc(a), inc(b)) end 8 parens Python: def blubExtra(a, b): return blub(inc(a), inc(b)) 8 parens, one colon C: int blubExtra(int a, int b) { return blub(inc(a), inc(b)); } 8 parens + 2 braces It's roughly the same numbers of brackets (or equivalent) in Clojure, Scala, C and Java. A bit less in Python and Ruby.
- forki23 12y ago
  as someone already pointed out on twitter: F#: let blubExtra a b = blub (inc a) (inc b) 4 parens.
  - forki23 12y ago
    Usually we would write it as: let blubExtra a b = inc b |> blub (inc a) which 2 parens less, but at the cost of using the (very idiomatic) pipe operator.
- bjz_ 12y ago
  I think it's the positioning of them that makes them stand out to people, plus the fact that they tend to bunch up at the end of things.
  - afandian 12y ago
    Of course, I know. But most people express it as 'too many parens', without (I believe) actually thinking too hard. I was just trying to provoke a few thoughts! The position of parens is something to get used to, but then again so is Python's indentation, Scala's type system, etc etc. Every language has something unique to get used to.
- gleenn 12y ago
JackMorgan 12y ago
I think Clojure is actually a lot safer by default than most people expect for a Lisp. Check out this comparison I wrote up between C#(or Java), F#, Clojure, and JavaScript on common edge case safety. http://deliberate-software.com/programming-language-safety-algorithm/ http://deliberate-software.com/programming-language-safety-a... In most ways I care about, Clojure is actually safer than C#. Now, if you're coming from an ML HM language, sure, you'll be taking a step back perhaps.
- smenko 12y ago
  Clojure is horribly unsafe. I spent a year writing Clojure and half the time we were fixing bugs where someone had wrapped a map in another map or changed the shape of a data structure. For all that's worth, I'd rather use Javascript. To add insult to injury (the amount of wasted time on something that could be easily checked by a compiler and a sane type system) there's all the bad habits you acquire and the general lack of confidence in your code, which took a good six months after that to cure. I'm sticking with types now, thank you very much...
  - JackMorgan 12y ago
    Sounds like you needed Schema, which can ensure the shape and contents of a map as :pre and :post assertions in every function you annotate, then be turned off for production use. https://github.com/Prismatic/schema https://github.com/Prismatic/schema That's why I come back to Clojure every time, if I need anything, it's available as a library. Need better typesafety? Just add in what you need with a macro or two. (Schema is not much more than that). That's not really possible easily with Javascript, and Javascript has a lot more unsafe by default edge cases than Clojure. I'm not sure why if a mostly safe dynamic language bothers you, you'd now prefer an extremely unsafe dynamic language? Lastly, types only give you a single dimension of safety, is this that exact shape, and ensuring I don't put a square peg into a round hole: both of which Schema adds in easily. Clojure is ALSO safe along many other dimensions, like thread saftey, immutably, null reference exceptions, etc.
    - smenko 12y ago
NhanH 12y ago
I don't know where this trick come from, but I've read it a long time ago, and you might find it helpful. Lisp languages in fact have the same(ish) amount of parentheses as any other language, the trick is that the placement slightly differ: the opening parentheses come before the function name, rather than after it. Ie foo(bar) => (foo bar) . foo(bar(baz)) => (foo (bar baz)).
- bbradley406 12y ago
  This trick is very helpful, but I would argue that there are still a lot more parentheses due to almost everything being written as a function in lisp. When I started programming in Racket arithmetic and comparison expressions tripped me up frequently. My tip to beginners in this area would be to use the dot-notation first, then switch to the standard way once comfortable. for example: (20 . > . (10 . / . 5)) may be more clear than (> 20 (/ 10 5))

yawnt 12y ago

parentheses, at least in my exp, just fade away after a while.. there's core.typed which is static typing for clojure [0] [0] https://github.com/clojure/core.typed https://github.com/clojure/core.typed

namelezz 12y ago
Thank you for the link. I will look into the core.typed.
threeseed 12y ago
Also Prismatic's schema. It achieves some of the same goals for why you would want strong typing: https://github.com/Prismatic/schema https://github.com/Prismatic/schema
- escherize 12y ago
  +1 for Prismatic Schema. It's not only an awesome way to validate your maps, but it is an extremely good way to write documentation.
minikomi 12y ago
It's also very worth looking at Typed Racket and Racket's contracts system! [1] http://docs.racket-lang.org/ts-guide/ [2] http://docs.racket-lang.org/guide/contracts.html?q=contracts

59nadir 12y ago

If you truly have been shunning Lisps because of parentheses I can only tell you that it will start to make sense once you see that they're just lists and that the fact that everything (including your code) is some variation of a list means that you are now (sometimes in the background) able to modify everything as if it was a list. S-expressions are uniform in that they all look the same way. This means you have one form for literally everything in the program and you will have no problem parsing that form. It makes reading, mentally parsing and editing easier because everything is neatly delimited by parentheses. In terms of readability, do you have any particular difficulties parsing the following code? (define (sum/recursive lst [sum 0]) (if (null? lst) sum (sum/recursive (rest lst) (+ sum (first lst))))) We are defining a function, sum/recursive, that will take a list and return the sum of all the numbers in that list. We use a default value of 0 for a function parameter called sum to store the sum. When the input list is empty ('(null? lst)' returns true) we return that variable. There is no return keyword, we just specify that variable and it will be returned. If the list isn't empty, we apply sum/recursive on the rest of the list and as a second parameter we add the first number in the list to the already accumulated sum ('(+ sum (first lst))'). Using matching parens in your editor will make it obvious when you have matched the right amount of parens. It should be noted that Racket, this Lisp variant, uses '[]' as well to delimit certain parts, for readability.

currywurst 12y ago
Lisp's super power (homoiconicity) comes at a trade-off of reduced discriminability. A good syntax highlighter and well-indented code (like you provided) reverses this effect considerably, but imho, it still takes a lot of getting used to for beginners. In any case, the bigger part of the being productive in a codebase is to figure out how it encodes the domain, what idioms and patterns are favoured etc. So sometimes, it's just not worth adding another source of aggravation for "new arrivals".
- escherize 12y ago
  I disagree with regard to Clojure. IME, the fact that it's a lisp doesn't seem as hard for noobs to grasp as immutability by default, or pickup up the functional programming mindset. We usually go for folks who use Emacs, so they may already have an indoctrination. When you compare Clojure to other lisps, I think you'd agree it's more discriminable, given the plethora of literals that dont use parenthesis: vectors [1 2 3] sets #{1 2 3} maps {:key "value" :name "Bryan"}
  - grandalf 12y ago
    I've used clojure for some weekend hacking and have found that the biggest challenge is feeling like my code is non-optimal. I can get stuff to work and could build real stuff in clojure, but I hesitate because I feel that it's not necessarily idiomatic. I guess I need a clojure mentor for the first non-trivial project. There really isn't that much idiomatic web-related code out there to read, and with clojure there is also quite a lot of variation in how systems get designed (b/c of the power and expressiveness available). This is not an excuse, just noting the factor that has turned out to slow me down. If i had more leisure time I'd just power through and build stuff until I arrived (through trial and error) at my own sense of best-practices / design tradeoffs. That has yet to happen but will someday.
davidw 12y ago
> S-expressions are uniform in that they all look the same way. If you treat the language as a user interface to your computer, shouldn't things that do different things have different appearances, to help you distinguish them at a glance?

threeseed 12y ago

Time. With Clojure/Lisp languages you are basically starting from the beginning. Most of the approaches you would take to constructing your applications don't work. It just takes a lot of practice for you to recognise patterns and then both the typing and parentheses will seem natural.

lmm 12y ago

Compile-time typing really is valuable, IME. Maybe you should look at Shen? (Can't help you on the brackets. I mostly stick to Scala myself)

afandian 12y ago

There aren't many languages that have radically fewer parentheses than Clojure / LISP. Clojure: (defn blub-extra [a b] (blub (inc a) (inc b))) 8 parens + 2 brackets Scala: def blubExtra(a: Int, b: Int): Int { blub(inc(a), inc(b)) } 8 parens + 2 braces Java: Integer blubExtra(Integer a, Integer b) { return blub(inc(a), inc(b)); } 8 parens + 2 braces Ruby: def blubExtra(a, b) blub(inc(a), inc(b)) end 8 parens Python: def blubExtra(a, b): return blub(inc(a), inc(b)) 8 parens, one colon C: int blubExtra(int a, int b) { return blub(inc(a), inc(b)); } 8 parens + 2 braces It's roughly the same numbers of brackets (or equivalent) in Clojure, Scala, C and Java. A bit less in Python and Ruby.

forki23 12y ago
as someone already pointed out on twitter: F#: let blubExtra a b = blub (inc a) (inc b) 4 parens.
- forki23 12y ago
  Usually we would write it as: let blubExtra a b = inc b |> blub (inc a) which 2 parens less, but at the cost of using the (very idiomatic) pipe operator.
bjz_ 12y ago
I think it's the positioning of them that makes them stand out to people, plus the fact that they tend to bunch up at the end of things.
- afandian 12y ago
  Of course, I know. But most people express it as 'too many parens', without (I believe) actually thinking too hard. I was just trying to provoke a few thoughts! The position of parens is something to get used to, but then again so is Python's indentation, Scala's type system, etc etc. Every language has something unique to get used to.
gleenn 12y ago

JackMorgan 12y ago

I think Clojure is actually a lot safer by default than most people expect for a Lisp. Check out this comparison I wrote up between C#(or Java), F#, Clojure, and JavaScript on common edge case safety. http://deliberate-software.com/programming-language-safety-algorithm/ http://deliberate-software.com/programming-language-safety-a... In most ways I care about, Clojure is actually safer than C#. Now, if you're coming from an ML HM language, sure, you'll be taking a step back perhaps.

smenko 12y ago
Clojure is horribly unsafe. I spent a year writing Clojure and half the time we were fixing bugs where someone had wrapped a map in another map or changed the shape of a data structure. For all that's worth, I'd rather use Javascript. To add insult to injury (the amount of wasted time on something that could be easily checked by a compiler and a sane type system) there's all the bad habits you acquire and the general lack of confidence in your code, which took a good six months after that to cure. I'm sticking with types now, thank you very much...
- JackMorgan 12y ago
  Sounds like you needed Schema, which can ensure the shape and contents of a map as :pre and :post assertions in every function you annotate, then be turned off for production use. https://github.com/Prismatic/schema https://github.com/Prismatic/schema That's why I come back to Clojure every time, if I need anything, it's available as a library. Need better typesafety? Just add in what you need with a macro or two. (Schema is not much more than that). That's not really possible easily with Javascript, and Javascript has a lot more unsafe by default edge cases than Clojure. I'm not sure why if a mostly safe dynamic language bothers you, you'd now prefer an extremely unsafe dynamic language? Lastly, types only give you a single dimension of safety, is this that exact shape, and ensuring I don't put a square peg into a round hole: both of which Schema adds in easily. Clojure is ALSO safe along many other dimensions, like thread saftey, immutably, null reference exceptions, etc.
  - smenko 12y ago

NhanH 12y ago

I don't know where this trick come from, but I've read it a long time ago, and you might find it helpful. Lisp languages in fact have the same(ish) amount of parentheses as any other language, the trick is that the placement slightly differ: the opening parentheses come before the function name, rather than after it. Ie foo(bar) => (foo bar) . foo(bar(baz)) => (foo (bar baz)).

bbradley406 12y ago
This trick is very helpful, but I would argue that there are still a lot more parentheses due to almost everything being written as a function in lisp. When I started programming in Racket arithmetic and comparison expressions tripped me up frequently. My tip to beginners in this area would be to use the dot-notation first, then switch to the standard way once comfortable. for example: (20 . > . (10 . / . 5)) may be more clear than (> 20 (/ 10 5))