Scala example is wrong, wouldn't even compile; should be:
def blubExtra(a: Int, b: Int): Int = blub(inc(a), inc(b))
The original would need an equals thrown in there, otherwise it's procedural syntax (IIRC, has been deprecated or will be in the next release) which has a return type of Unit, thus not compiling when specifying a return type of Int.
You can do it in Ruby with 4 parens, or even 0 if inc is really just +1. I wouldn't ever write it with so few but if we're really going down this rabbit hole then we ahould get it right.
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.
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.
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".
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"}
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.
> 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?
The braces become "invisible" after some training.
Different elements of the program are distingishable.
"+" is different from "if", which is different from "42".
It's all about people, so there are likely not cut and dried answers, but I know I have always found C style code a bit easier to read than Lisp style code. Part of this may be due to other conventions, such as larger indents in C code.
Like you say, with training, the differences are probably not that big a deal, but I don't think they are something to completely ignore, either.
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-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.
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...
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
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.
80% of the problems I had to deal with (in a live, real-life Clojure system that had to be maintained and supported, not a hobby-happy-slappy-project-thing) were caused by putting square pegs in a round hole. You're telling me I need to get a macro-based library and add :pre and :post conditions that check the structure of a map, as opposed to using a language with types?! Really??? Oh, and guess what, I am sure there is a Javascript library that does that too...
I don't really use anything in production, I am just a learner right now :)
There are some people using some of extensions for Haskell inspired by "dependently typed" systems in production.
Dependent typing is an active research topic right now, and I doubt any fully fledged dependently typed language is used "in production".
However, I was just pointing out that it is possible for types to express a wide variety of things that we do not normally associate with them. Even without full dependent typing, Haskell types are wonderfully expressive and powerful.
Oh, god, thanks for reminding me about the whole agent/atom/ref hell - another reason I'd rather erase the whole Clojure experience from my brain altogether...
Jesus, maybe you were not able to read a clojure book befor you started. Its amazingly simple to explain how to write thread safe code with clojure, and pretty easy to add concurrency safly.
There are 3 concepts that are all diffrent, and a couple yours ago core.async was added. All in all thats a amazingly simple and powerful combination. Everybody I have heard is pretty happy with these tools. What is your problem?
Agree to disagree. I do not enjoy the impossible to prove defensive coding around threads and callbacks. The core.async library made threading in Clojure for me to now be simple and pleasant compared to difficult to test mutexes and deadlocks.
You're the first person I've seen that is vocal about having a truly bad experience with Clojure. Even from other people who prefer strongly typed language, I've mostly seen them expressing it as "not their taste", rather than actively dislike it. Do you mind sharing your experience and what was wrong with Clojure? You put js as an alternative, but in term of typing, js is borderline one of the worse type system out there.
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)).
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:
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.
Clojure:
8 parens + 2 bracketsScala:
8 parens + 2 bracesJava:
8 parens + 2 bracesRuby:
8 parensPython:
8 parens, one colonC:
8 parens + 2 bracesIt's roughly the same numbers of brackets (or equivalent) in Clojure, Scala, C and Java. A bit less in Python and Ruby.