You are correct of course, Anonymous Coward. Thinking of Ruby as a Smalltalk dialect is obviously more metaphorical than literal. And actually, Matz himself has remarked that he accepts the comparison of Ruby to Smalltalk as a compliment.
Thanks for replying, phantomfive. Obviously I did not express my question clearly enough.
Lisp is not statically typed, and it's therefore a very different sort of language than Scala. There are interesting dialects like Racket, which allows you to "turn on" some type checking, and like Qi, which I didn't previously think of as an OO language. At least, you have given me something to think about.
ljw1004, Javascript is not statically typed. But, your suggestion of OCaml is a thoughtful one. I am not aware of how well a feature like Type Classes fits into the language. My suspicion is that they are more cumbersome than in Haskell or Scala, but it's an interesting thing to explore.
phantomfive, You have responded with a bit of vitriol that surprises me.
Can you please cite other examples of mainstream statically typed languages that are both OO and Functional? I ask this not to insist that no others exist, but rather to further engage you, and try to understand where you are coming from.
In other words, don't bother with Scala just yet since we haven't made up our minds about the syntax and will probably start all over.
Actually, no. It's not about modifying the syntax. It's about bringing some very exciting ideas from research into Dependent Object Types into a mainstream language.
No, I am quite certain that language designers respect Scala. Consider Peter Van Roy, for example, who is a leading expert on programming languages, and the co-author of a very influential book on programming paradigms. He highly recommends Scala.
Yes, compiler performance is an honest complaint from in-the-trenches Scala programmers, but that's a far cry from the "Scala is a joke" headline you use. If it were really a joke, then how could it continue to be used in the large scale applications of which you speak?
I am certainly an advocate of lifelong developer training and code reviews. But consider this. If a language permits these sorts of == vs equals errors, then perhaps that's a defect in the language design itself.
Groovy is not really very simple. But more importantly, it's not a simpler Java at all. Since Groovy is dynamic and Java is static, they are completely different languages that bear a superficial syntactic similarity.
Scala has type erasure, too, and IIRC it was designed by one of the guys who are responsible for the design of type erasure in Java.
You are correct. I believe that the Pizza language, which became Java generics in the Tiger release, was designed by Martin Odersky. Type erasure in Tiger was deemed necessary for backwards compatibility with Java 1.4 code.
And consequently, Scala has type erasure for interoperability with Java. IIRC, James Gosling wanted many features like generics in Java, but couldn't get them into the language without slipping Java's release date. It's sad that a modern language like Scala still suffers from this twenty year old decision.
However, Scala also has Manifests, which address some of the weaknesses imposed by type erasure. It's good to shake the dust from our sandals.
Well said. Of course, Professor Odersky *is* a language expert/theorist, and Scala already makes a real difference. Its successors may well continue to do so.
What's so fascinating about Scala is that the blending of OO and Functional ideas into a Modular language is (1) possible, and (2) innovative. There's an orthogonality of Scala language features (something Stroustrup strove for in C++) that allows for some real surprises. For example, Implicits make Type Classes possible very elegantly. Scoped type classes turn out to be an emergent language feature, which didn't have to be baked into the compiler.
Perhaps, but why should there even be an == operator for objects? This is not a flippant question, but a deep language design question. It may be the case that Java's decision to expose == introduced too much opportunity to get things wrong. It's possible to imagine a more robust language without such an operator. Just as it is possible to imagine one without null, which would surely be better.
Java has changed many times, with careful thoughts to backwards compatibility at the source level. But it's a verbose beast, living in the uncanny valley between dynamic languages and languages with type inference. So, Java essentially has many of the hassles of static typing with few of the benefits.
There hasn't been as much Scala written as Java, and it may never catch up. But I'm sure that the Scalaists care about backwards compatibility, too. There's already too much Scala written for there not to be a "flap." But somehow I think even breaking changes in Scala will be tolerated if they make the language more pleasant. The research being done right now on dependent types is just too exciting.
Yes, dynamic languages like Clojure are nice, but so are static ones. I actually consider Scala a dialect of ML, much in the way that Ruby is a dialect of Smalltalk.
I think you misunderstood what bradley13 wrote. Java pre-constructs the low valued Integer objects, so that == and.equals will always return the same answer. But for larger values, they don't. This is entirely independent of autoboxing.
Yes, one needs to demonstrate that Suzy is not doing her job. Documenting this requires actual effort on the part of Suzy's manager.
There is no need to make all Suzy's coworkers suffer. Unless the manager is taking a paycheck without actually managing, which is exactly what I'm arguing here.
Somebody somewhere in the organization is abusing the flexibility you all enjoy. So instead of addressing that one individual problem, management tried to "fix" the situation in the way you describe. This is simply management choosing not to do their jobs.
Kilobug, this is not so. Perhaps you are confusing entanglement with quantum teleportation.
Quantum teleportation requires that the sender perform measurements and send information to the receiver. The receiver uses this information to reconstruct the pre-measured state at her end.
Slashdot Mirror
The woman, who is also a programmer, criticized her husband for not coming home with THIRTEEN gallons of milk.
Thanks for the link.
Insightfully said, Anonymous Coward.
You are correct of course, Anonymous Coward. Thinking of Ruby as a Smalltalk dialect is obviously more metaphorical than literal. And actually, Matz himself has remarked that he accepts the comparison of Ruby to Smalltalk as a compliment.
Thanks for replying, phantomfive. Obviously I did not express my question clearly enough.
Lisp is not statically typed, and it's therefore a very different sort of language than Scala. There are interesting dialects like Racket, which allows you to "turn on" some type checking, and like Qi, which I didn't previously think of as an OO language. At least, you have given me something to think about.
ljw1004, Javascript is not statically typed. But, your suggestion of OCaml is a thoughtful one. I am not aware of how well a feature like Type Classes fits into the language. My suspicion is that they are more cumbersome than in Haskell or Scala, but it's an interesting thing to explore.
phantomfive, You have responded with a bit of vitriol that surprises me.
Can you please cite other examples of mainstream statically typed languages that are both OO and Functional? I ask this not to insist that no others exist, but rather to further engage you, and try to understand where you are coming from.
In other words, don't bother with Scala just yet since we haven't made up our minds about the syntax and will probably start all over.
Actually, no. It's not about modifying the syntax. It's about bringing some very exciting ideas from research into Dependent Object Types into a mainstream language.
No, I am quite certain that language designers respect Scala. Consider Peter Van Roy, for example, who is a leading expert on programming languages, and the co-author of a very influential book on programming paradigms. He highly recommends Scala.
Yes, compiler performance is an honest complaint from in-the-trenches Scala programmers, but that's a far cry from the "Scala is a joke" headline you use. If it were really a joke, then how could it continue to be used in the large scale applications of which you speak?
It depends on what we mean by "popular". If popular means that more lines of Scala are being written than Java, then, no, Scala is not popular.
But if we mean that the Scala programmers are in demand, then yes, Scala is popular.
I am certainly an advocate of lifelong developer training and code reviews. But consider this. If a language permits these sorts of == vs equals errors, then perhaps that's a defect in the language design itself.
Groovy is not really very simple. But more importantly, it's not a simpler Java at all. Since Groovy is dynamic and Java is static, they are completely different languages that bear a superficial syntactic similarity.
Scala has type erasure, too, and IIRC it was designed by one of the guys who are responsible for the design of type erasure in Java.
You are correct. I believe that the Pizza language, which became Java generics in the Tiger release, was designed by Martin Odersky. Type erasure in Tiger was deemed necessary for backwards compatibility with Java 1.4 code.
And consequently, Scala has type erasure for interoperability with Java. IIRC, James Gosling wanted many features like generics in Java, but couldn't get them into the language without slipping Java's release date. It's sad that a modern language like Scala still suffers from this twenty year old decision.
However, Scala also has Manifests, which address some of the weaknesses imposed by type erasure. It's good to shake the dust from our sandals.
Well said. Of course, Professor Odersky *is* a language expert/theorist, and Scala already makes a real difference. Its successors may well continue to do so.
What's so fascinating about Scala is that the blending of OO and Functional ideas into a Modular language is (1) possible, and (2) innovative. There's an orthogonality of Scala language features (something Stroustrup strove for in C++) that allows for some real surprises. For example, Implicits make Type Classes possible very elegantly. Scoped type classes turn out to be an emergent language feature, which didn't have to be baked into the compiler.
Perhaps, but why should there even be an == operator for objects? This is not a flippant question, but a deep language design question. It may be the case that Java's decision to expose == introduced too much opportunity to get things wrong. It's possible to imagine a more robust language without such an operator. Just as it is possible to imagine one without null, which would surely be better.
Java has changed many times, with careful thoughts to backwards compatibility at the source level. But it's a verbose beast, living in the uncanny valley between dynamic languages and languages with type inference. So, Java essentially has many of the hassles of static typing with few of the benefits.
There hasn't been as much Scala written as Java, and it may never catch up. But I'm sure that the Scalaists care about backwards compatibility, too. There's already too much Scala written for there not to be a "flap." But somehow I think even breaking changes in Scala will be tolerated if they make the language more pleasant. The research being done right now on dependent types is just too exciting.
Yes, dynamic languages like Clojure are nice, but so are static ones. I actually consider Scala a dialect of ML, much in the way that Ruby is a dialect of Smalltalk.
I think you misunderstood what bradley13 wrote. Java pre-constructs the low valued Integer objects, so that == and .equals will always return the same answer. But for larger values, they don't. This is entirely independent of autoboxing.
Yes, one needs to demonstrate that Suzy is not doing her job. Documenting this requires actual effort on the part of Suzy's manager.
There is no need to make all Suzy's coworkers suffer. Unless the manager is taking a paycheck without actually managing, which is exactly what I'm arguing here.
Somebody somewhere in the organization is abusing the flexibility you all enjoy. So instead of addressing that one individual problem, management tried to "fix" the situation in the way you describe. This is simply management choosing not to do their jobs.
0x537461746943, what you have described is not quantum teleportation.
I think you may be confusing entanglement with quantum teleportation.
Kilobug, this is not so. Perhaps you are confusing entanglement with quantum teleportation.
Quantum teleportation requires that the sender perform measurements and send information to the receiver. The receiver uses this information to reconstruct the pre-measured state at her end.
But only one you can count.
One thing college teaches you is how to write coherent easy to comprehend statements.
I found my new definition of irony.
I think Tony Isaac meant "MS = Master's Degree", not "MS = Microsoft"
So, are you using RogueWave? STL? You get the idea. There is plenty new to learn.