Comments on Scala Blog: Scala the statically typed dynamic language

As of 10/2009, I don't see any follow-up postings ...

2009-10-02T13:00:30.978-07:00

As of 10/2009, I don't see any follow-up postings that cover method_missing, open classes, or other features that I tend to expect in dynamic languages. Wassup?

Just wondering when that next post about method_mi...

2009-02-18T14:23:39.370-08:00

Just wondering when that next post about method_missing and open classes (like in Ruby) will be ??

I am holding my breath to see that magic in scala ...

I thought I had a handle on Scala, having read my ...

2009-01-24T09:33:27.722-08:00

I thought I had a handle on Scala, having read my way through most of the online tutorial, but this post made my eyes pop out — I did not realize that Scala's static typing was this flexible.

Currently my favorite/primary language is Objective-C 2, with some straying into Ruby and Python, but Scala increasingly looks like it'll give me the best of both worlds.

I just got the big fat Artima book in the mail yesterday, so it's time to practice my Scala this weekend! Thanks again for writing this.

Nag nag! ;)

2008-03-24T10:55:31.580-07:00

Nag nag! ;)

And I'm eagerly awaiting writing it, but I've been...

2008-01-31T22:56:15.153-08:00

And I'm eagerly awaiting writing it, but I've been sidetracked by paying clients, new business development and a couple of very charming 3 year olds. Maybe I'll get to something this weekend. :-)

David, eagerly looking forward to the next post in...

2008-01-31T22:44:18.544-08:00

David, eagerly looking forward to the next post in this series.

Paddy,The advantage of view bounds is that they wo...

2008-01-02T12:18:52.628-08:00

Paddy,

The advantage of view bounds is that they work for any type A for which there is an implicit function from A -> B in scope (where B is the required type). The function that requires a B doesn't need to be changed to add a case for each different type A.

Thus there is no need for handling exceptions or if-then-else'ing.

Jeremy

If you compare your definition of duck typing:"So,...

2008-01-02T11:19:29.101-08:00

If you compare your definition of duck typing:

"So, one of the places that dynamic languages shine is the ability to pass an object (or a collection of objects) to a method and as long as the objects implement particular methods (e.g., name and age), the method will execute just fine."

With that from the
Wikipedia article, specifically the "Comparison with other type systems", you would find that Ruby and Python, being dynamic, don't have to rely on a statically determined interface, or method signature as Scala does.

If you take a look at
this example You will see some of the extra flexibility you get.

-

On the Scala "non-uniform naming scheme handling feature" then you are rigth in that Python does not do it that way. The Python developers haven't yet seen the need to explicitely support this kind of thing in the language, (maybe they haven't been introduced to Scala); but the normal way of handling this would be to try and call the first method - catch the exception due to the method not being present and in the exception handler, try the alternative.

- Paddy.
--
P.S. My tone is meant to be informative, supportive of Python, and certainly not denigrating.

Well, I thought I'd have to wait till es4 to play ...

2007-12-31T07:40:18.645-08:00

Well, I thought I'd have to wait till es4 to play with static verification/structural typing in a live project — and it turns out I can already have it in Scala. Very cool.

Looking forward dynamic dispatch!

You said: "Over the next few postings, I'm going t...

2007-12-30T22:22:36.898-08:00

You said: "Over the next few postings, I'm going to demonstrate that most of the safe (taking input off the wire and doing method lookup on that input is not safe) constructs that dynamically typed languages have are available in Scala."

David: do you mean "safe" in a programming language sense or a security sense? Because the security of taking input off the wire and doing method lookup depends on a host of factors outside of the language. (firewalls, for a start) If we were to conflate type safety and security-safety then we'd have to discard relational databases as "unsafe" because SQL is more or less "dynamic method lookup."

Along the same lines: Java has some tools that allow you to circumvent type safety and do dynamic method lookup and calling when appropriate (e.g. when Java code is being called by a dynamic language). Does Scala have equivalents? And in particular, will you discuss dynamic loading of Scala and/or Java code?

Even strongly Java-centric systems like Eclipse and Tomcat rely on dynamic code modules which may throw type exceptions at (dynamic) link time.

Ben and Reginald - you'll get method_missing and "...

2007-12-30T22:04:43.015-08:00

Ben and Reginald - you'll get method_missing and "open classes" (changing the dispatch table) in my next post.

David,I agree with Reginald. I think the point yo...

2007-12-30T20:39:17.692-08:00

David,

I agree with Reginald. I think the point your making is a good one, and I like Scala, but I was confused by the use of the word dynamic. I'm a Squeak hacker at the moment, and I was waiting for something like method_missing or open classes.

Still, I like the post.

Ben

David:I like the post, but the title left me a lit...

2007-12-30T20:13:17.483-08:00

David:

I like the post, but the title left me a little confused. You seem to be describing how Scala provides the benefits of latent or implicit typing while also guaranteeing type safety.

I like that.

When I think of "Dynamic" typing, I think of actual run-time changes to type, such as method_mising handling, singleton classes, and the oft-maligned open classes.

As David pointed out, the problem with interfaces ...

2007-12-30T20:09:18.881-08:00

As David pointed out, the problem with interfaces (or virtual base classes, or anything else along the same lines) is that you have to declare each class as implementing the interface.

This quickly creates a thicket of interfaces for each class. besides the verbosity, they do not add much value to the class declaration, as David points out it's the method you want to document.

IMO, interfaces associated with concrete classes should be semantically significant. I don't think "ICanHazNameAndAge" adds any value since you can already see that in the declaration :-)

Alex,I avoided List(a,b) just because the type of ...

2007-12-30T19:31:14.766-08:00

Alex,

I avoided List(a,b) just because the type of the collection is immaterial to the discussion and I didn't want to sidetrack on Array vs. List vs. ???.

One can do this with Interfaces, but it starts getting really messy and it's one of the, IMHO, solid points that dynamic languages have going for them. You don't have to add the INamePrice interface or have an interface for every field and have some wacky ICost with IName nonsense that COM devolved into.

Put another way, Scala is statically typed with optional duck typing... the opposite of Objective-C et. al. with their duck typing with optional static typing.

Although I know that ... :: ... :: Nil is creating...

2007-12-30T18:29:02.786-08:00

Although I know that ... :: ... :: Nil is creating a list, I'm betting most of the people having done a few hours of a Ruby class won't.

Why not use the equivalent but slightly less punctual List(a,b) instead?

Also, whilst you can do this in Scala, arguably one could do the same in Java with interfaces, right?

If your view is on a structural subtype, you can r...

2007-12-30T17:02:29.358-08:00

If your view is on a structural subtype, you can replace the case class with an anonymous class:

implicit def priceToCost(in: {def price: Int}) = new { def cost = price }

Good stuff Dave!And I think it's great you left th...

2007-12-30T16:49:47.775-08:00

Good stuff Dave!

And I think it's great you left the term "Structural subtyping" out of the post! :)

Cheers,

Viktor