Hacker News Reader

Comment by camus2 | Hacker News Reader

Well the problem with Scala is at first it looks like a concise java but it's not. Truth is it's closer to Lisp with a C syntax. If you dont understand some idioms like lazy evaluation, everything is a method or pattern matching you probably should use it. I think scala rocks. The only downside is the slow compiler. But SBT , worksheets , stuff like that are just awesome to toy with stuffs in an interactive manner.

View on HN

Scala is much closer in spirit to ML / OCaml / Haskell than a LISP dialect, but I do agree w/ you that Scala rocks. It's my favorite language I've picked up since O-Caml.

I totally agree on the slow compile times. It's simply painful.

> Truth is it's closer to Lisp with a C syntax.

The only similarity that Lisp and Scala have are that they are both functional programming languages[0].

Scala is a heteroiconic language. At least until recently, Scala didn't even have macros (I think they may have added that recently).

Scala is a nice language, but saying that Scala is somehow like Lisp is doing a disservice to both languages.

[0] Even the statement that Scala is functional is itself debatable - one can make the argument that it is "just" more purely object-oriented than Java, but that's a whole separate discussion.

Why do people think Lisp is a functional programming language? If anything, traditional Lisp is the antithesis of a functional programming language. What Lisps are you referring to?

Maybe we're just defining our terms differently, but the closest Lisp comes to a functional programming language is Clojure and before that Scheme.

This is not meant to deride Lisp in any way (Clojure is my language of choice, after all) - I think all Lisps enable a fundamentally unique way to reason about programs, but that's a characteristic of Lisp and not of functional programming languages.

I think the biggest thing is that most lisps return values for most things.

    (if a x y)

which is composable to

    (let ((val (if a x y)))
      ...)

as opposed to

    (let ((val nil))
      (if a
          (setf val x)
          (setf val y))
      ...)

That said, not everything returns value(s), and there's nothing enforcing immutability. I'd say you can be functional in (most?) lisps if you are careful, but the language family is more geared towards general purpose programming than functional.

People think of Lisp as an implementation of lambda calculus, which is at the theoretical core of pretty much all functional programming languages.

Unfortunately we've overloaded the term 'functional programming' a bit too much. Foundation on the lambda calculus is definitely core to most functional languages, and I see how it would be reasonable to think of that as their defining feature, but it seems that the community has instead gravitated towards 'referential transparency' as the key thing. With the former definition, Lisps are definitely functional; with the latter, most of them are definitely not. Most Lispers I know consider e.g. Common Lisp to be a multi-paradigm language, not a functional one, for this reason.

Lisp is the original functional language. Functional language traditionally meant a language that emphasised functions as values, in particular supporting higher-order functions. Hence the word "functional".

More recently, people have confused "functional" with other features of languages like Haskell (sometimes called "purely functional"), leading to some confusion about what defines functional programming.

Here's an interesting post about the more recent changes in the phrase's meaning:

http://wcook.blogspot.co.uk/2012/07/day-functional-programmi...

Could you explain why you think Scala is not homoiconic?

I checked a few common definitions of homoiconicity and it seems like Scala is within the ruleset.

How do you figure? What scala data type is scala source code?

Those types from scala.reflect.

No it isn't. Those tell you what types the values represent. We're talking about the actual source code itself. In lisp, the source code is itself a perfectly ordinary lisp value. That is what homoiconicity is. That is not something scala has, nor is it something scala wants to or claims to have.

> In lisp, the source code is itself a perfectly ordinary lisp value.

Isn't quoting necessary to "reify"/refer to the actual code as data?

Yes?

So what's the difference then? I need to quote in Lisp, I need to quote in Scala.

This bizarre lisp fetish where everyone wants to call every language "basically lisp but..." needs to die. Scala is not basically lisp. Neither is python, or ruby, or javascript. Lisp is not just "has lambdas".

Reply on news.ycombinator.com