The Artima Developer Community
Sponsored Link

Weblogs Forum
Static Typing, Guard Rails and Street Signs

13 replies on 1 page. Most recent reply: Oct 4, 2011 1:33 PM by James Watson

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 13 replies on 1 page
Ian Robertson

Posts: 68
Nickname: ianr
Registered: Apr, 2007

Static Typing, Guard Rails and Street Signs (View in Weblogs)
Posted: Sep 22, 2011 8:02 PM
Reply to this message Reply
Summary
My thoughts on the battle between dynamic languages and those with Turing complete type systems after attending StrangeLoop.
Advertisement

I had the pleasure of attending StrageLoop 2011 this week. One theme that seemed to keep coming up was that of type systems. I had a fascinating hallway conversation with Daniel Spiewak about the Turing-completeness of Scala's type system; he argued that while this had not been intentional, it is actually inevitable that any sufficiently developed type system will be Turing-complete. Andrey Breslav's talk on The Kotlin Programming Language (slides in pdf) was interesting; Kotlin seems to be heading in the same direction as Scala, but is willing to sacrifice some of the more esoteric type system features in the interest of keeping things manageable. Andrey mentioned that one goal for Kotlin is to keep the type system from becoming Turing Complete. As much as I love Scala, I have to concede that this may be a wise choice.

Gerald Sussman gave a great talk with many themes; one of them was that we should stop trying to think in terms of provable correctness; it's just too hard. Finally, Rich Hickey finished off with a wonderful presentation that discussed the nature of complexity in Software Development. One point that Rich stressed in his talk was that static type checking and unit tests are often viewed as "guard rails", and he observed that relying on these to ensure correctness is akin to driving randomly along, careening off the sides of the road in hopes of reaching one's destination. Moreover, he pointed out that guide rails do nothing to help you plan your trip; actual planning is required.

All of this has had me pondering the cost and value of static typing. I've long been a proponent of it, and not strictly for theoretical reasons. I once had the misfortune of maintaining a website with its front end written in Perl. The lack of static typing made it much more difficult to understand what was going on; it also lead to what one StrangeLoop speaker referred to as "Typo Oriented Programming" - it was far too easy for a misspelled method or class name to make it into production on a rarely accessed code branch. Nowadays, I program mostly in Java. I cannot honestly say that I rely much on static typing to prevent errors per se, but I do rely on it to help me understand the structure of my code. Being able to find all references to a given type or method in a code base has many uses, ranging from aiding in discovery of how a system is structured to understanding the impact of a change under consideration.

At the same time, static typing can have definite drawbacks. I've at times had to jump through some hoops to maintain type safety, and I have many hours of discussions with colleagues about how one could possibly avoid having to make a single cast in a particular situation. Using functional programming techniques, the issue can become more challenging, especially when writing library code. While in theory, the "average" developer will not need to worry about these issues, it seems that in practice, static typing tends to be a leaky abstraction.

I think the right approach might be to avoid the extremes. At a minimum, I think a language should require explicit declaration of user-defined symbols (class names, method names, etc), and helpfully fail when a user attempts to use an undeclared symbol; this can help to keep Typo Oriented Programming in check. More complex type systems allow for additional expressiveness, which in turn can be used to provide additional insights into the code. At the same time, an excessive focus on static typing can start to yield diminishing returns with ever increasing complexity costs. While using a type system as guard rails might be misguided, using it as a set of street signs can be quite helpful.

This approach, to use static typing, but only to a point, has an unsatisfying element of impurity to it. It lacks both the simplicity of systems which avoid typing, as well as the mathematical elegance that complex type systems can provide. It requires that we make trade-offs, in some cases accepting a bit of extra effort to satisfy the type system, and in other cases choosing to let the type system complain, under the presumption that the work to "fix" the problem would be greater than any additional benefit that fix would likely yield. But while part of our craft involves seeking the most elegant solutions available, another part is steeped in the art of compromise.


Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Static Typing, Guard Rails and Street Signs Posted: Sep 23, 2011 2:04 PM
Reply to this message Reply
One of the great things about ActionScript is that you got the benefits of static typing -- very helpful when using the IDE -- but if you needed to, you could turn off the static typing. Typically you would only do this for the duration of one function that needed to do dynamic things. You have the benefit of static typing when that works, but if you needed to be dynamic, it didn't involve swimming upstream through molasses (like Java).

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Static Typing, Guard Rails and Street Signs Posted: Sep 26, 2011 4:19 AM
Reply to this message Reply
> At the same time, static typing can have definite
> te drawbacks. I've at times had to jump through
> some hoops to maintain type safety, and I have many
> ny hours of discussions with colleagues about how
> one could possibly avoid having to make a single cast in
> in a particular situation.

Can you give us a concrete example of where you had to jump through hoops in order to maintain type safety?

> Using functional
> programming techniques, the issue can become more
> re challenging, especially when writing library
> code.

Example, please?

> While in theory, the "average" developer will not
> ot need to worry about these issues, it seems
> that in practice, static typing tends to be a leaky
> ky abstraction.

Not at all. I am afraid that what you are actually talking about is design issues that lead to problems.

Circumventing the type system is not a solution to a problem, for the simple reason that the solution that circumvents the type system has an equal solution that doesn't circumvent the type system.

> At the same time, an
> excessive focus on static typing can start to yield
> ld diminishing returns with ever increasing
> complexity costs.

That never happens. When complexity reaches the levels you mention, a dynamic type system only helps to mask problems. The failures are transferred to the run time, instead of the compile time.

> This approach, to use static typing, but only to a
> a point, has an unsatisfying element of impurity
> to it. It lacks both the simplicity of systems which
> ch avoid typing, as well as the mathematical
> elegance that complex type systems can provide. It
> It requires that we make trade-offs, in
> some cases accepting a bit of extra effort to satisfy
> fy the type system, and in other cases choosing
> to let the type system complain, under the presumption
> on that the work to "fix" the problem would be
> greater than any additional benefit that fix would
> ld likely yield. But while part of our craft
> involves seeking the most elegant solutions available,
> e, another part is steeped in the art of
> compromise.

I think that speaking without concrete examples about such things only diminishes the credibility of the speaker.

There have been many discussions about static/dynamic type systems, but there has never been a conclusive proof that dynamic systems help alleviate the problems of static type systems.

First of all, that static typing can lead to problems has not been proven. In every example presented, the problem is actually the lack of insight from the programmer.

Secondly, it has not been proven that dynamic typing can actually solve the problems. Sure, if you type less, you can get your code out faster, but that's about it really. Properly tested software requires functional testing, and testing a dynamic program in such a way requires a hell of a lot more tests, which are not done due to cost. Therefore, dynamically typed programs can potentially contain a lot more bugs than statically typed ones.

Ian Robertson

Posts: 68
Nickname: ianr
Registered: Apr, 2007

Re: Static Typing, Guard Rails and Street Signs Posted: Sep 26, 2011 11:40 AM
Reply to this message Reply
> Can you give us a concrete example of where you had to
> jump through hoops in order to maintain type safety?

A few examples where a cast class is required:

Guava's ImmutableClassToInstanceMap (http://guava-libraries.googlecode.com/svn-history/r9/trunk/src/com/google/common/collect/ImmutableClassToInstanceMap.java) requires casting.

A more complicated one. I have a class maintaining such a ClassToInstanceMap. I have a java method
  public void set(Object instance)
which will examine the type hierarchy of instance to look for a superclass with a given annotation, and assign instance to that class in the map. I've spent a couple of hours trying to accomplish this without needing a @SupressWarnings annotation, and I am 98% certain that this cannot be accomplished in Java without an "unsafe" cast.

> > Using functional
> > programming techniques, the issue can become more
> > challenging, especially when writing library
> > code.
>
> Example, please?

From the scaladoc for Traversable:
def flatMap [B, That] (f: (A) ⇒ GenTraversableOnce[B])(implicit bf: CanBuildFrom[Traversable[A], B, That]): That
A lot of cleverness went into constructing the Scala Collections API. Section 25.3 of the second edition of Programing in Scala goes into depth about the the various tasks required to get your own collection to play well with the API. At one level, I'm impressed by the Scala Collections API, and I definitely find it cool. However, I do worry that the result is more complex than a set of core APIs ought to be.

> > While in theory, the "average" developer will not
> > need to worry about these issues, it seems
> > that in practice, static typing tends to be a leaky
> > abstraction.
>
> Not at all. I am afraid that what you are actually talking
> about is design issues that lead to problems.
>
> Circumventing the type system is not a solution to a
> problem, for the simple reason that the solution that
> circumvents the type system has an equal solution that
> doesn't circumvent the type system.

I'm a bit perplexed by this statement, for two reasons. The first reason is that it presumes the type system is completely expressive. This is definitely not the case in most languages (for example, the ClassToInstanceMap mentioned above requires an "unsafe" cast in it's implementation). The second reason is that it implies that the existence of another solution makes circumventing the type system a non-solution. At worst, it's an inferior solution. If the non-circumventing approach is overly complicated, circumvention may even constitute the better solution for the problem at hand.

> > At the same time, an
> > excessive focus on static typing can start to yield
> > diminishing returns with ever increasing
> > complexity costs.
>
> That never happens. When complexity reaches the levels you
> mention, a dynamic type system only helps to mask
> problems. The failures are transferred to the run time,
> instead of the compile time.

I should make clear that I'm not advocating dynamic typing; I still strongly prefer statically typed systems. What I am suggesting is that there may be a point at which adding additional expressiveness to the type system brings more in cost than it does in benefit. Ideally, these compromises should be isolated as much as possible to small sections of code, so that extra care can be taken to avoid runtime failures. A sufficiently expressive type system could be used to avoid them, but the additional cognitive effort required to handle the added complexity introduced can result in errors slipping in in other ways.

> There have been many discussions about static/dynamic type
> systems, but there has never been a conclusive proof that
> dynamic systems help alleviate the problems of static type
> systems.

I'm not even sure what a conclusive proof in this debate (for either side) would look like. I think that we have to rely on our experiences to make judgements. My experience at the moment is telling me that static typing is good, but that it can be taken too far. To be more precise, I believe Java probably doesn't go quite far enough, while I'm beginning to suspect that Scala may take things too far.

> First of all, that static typing can lead to problems has
> not been proven. In every example presented, the problem
> is actually the lack of insight from the programmer.

A completely elegant type system which can handle all situations, but which requires a high level of programmer insight, may not be making the best use of our finite intellectual capacity.

> Secondly, it has not been proven that dynamic typing can
> actually solve the problems. Sure, if you type less, you
> can get your code out faster, but that's about it really.
> Properly tested software requires functional testing, and
> testing a dynamic program in such a way requires a hell of
> a lot more tests, which are not done due to cost.
> Therefore, dynamically typed programs can potentially
> contain a lot more bugs than statically typed ones.

I completely agree with you here. I apologize for not making it more clear in my initial post that I was not advocating for dynamic typing.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Static Typing, Guard Rails and Street Signs Posted: Sep 27, 2011 6:30 AM
Reply to this message Reply
> I've at times had to jump through
> some hoops to maintain type safety, and I have many
> hours of discussions with colleagues about how
> one could possibly avoid having to make a single cast in
> in a particular situation.

When I first started with generics in Java (which of course is a pretty flawed implementation) I tried to make everything generic to such a degree that I found I could not use the code in the way I intended and had to unwind a lot of it.

After a I spent this time, I realized that this was not a good use of my time and I just use @SuppressWarnings (judiciously). There's a cost to doing this in that I must spend more time making sure what I do in those sections is correct.

I think you are spot on with the real value of static typing. It helps you understand the structure of an application in ways that are difficult to emulate reliably with dynamic code. So using @SuppressWarnings to allow for that information to enrich the code without the need for awkward incantations is a very pragmatic trade-off.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Static Typing, Guard Rails and Street Signs Posted: Sep 27, 2011 6:54 AM
Reply to this message Reply
> A few examples where a cast class is required:
>
> Guava's ImmutableClassToInstanceMap
> (http://guava-libraries.googlecode.com/svn-history/r9/trunk
> /src/com/google/common/collect/ImmutableClassToInstanceMap.
> java) requires casting.

I guess you mean this line of code:

return (T) delegate.get(type);


From what I understand, the class ClassToInstanceMap is used to map a class T to a value of type T, right?

Well, the cast could have been avoided if the map's value type was returned via a virtual function that invoked a user-defined function that accepted (and perhaps returned) the requested type.

> which will examine the type hierarchy of
> instance to look for a superclass with a
> given annotation, and assign instance to that
> class in the map. I've spent a couple of hours trying to
> accomplish this without needing a @SupressWarnings
> annotation, and I am 98% certain that this cannot be
> accomplished in Java without an "unsafe" cast.

Perhaps if Java had pattern matching, you could do it without casts.

My point is that it's not static type systems at fault, but specific static type systems of languages.

> The first reason is that it presumes the type system is
> completely expressive. This is definitely not the case in
> most languages (for example, the ClassToInstanceMap
> mentioned above requires an "unsafe" cast in it's
> implementation).

It's not a matter of the type system being static though. As you say, it's the specific language implementation.

> The second reason is that it implies that
> the existence of another solution makes circumventing the
> type system a non-solution. At worst, it's an inferior
> solution. If the non-circumventing approach is overly
> complicated, circumvention may even constitute the better
> solution for the problem at hand.

It depends on how dangerous the circumvention is. Preferably, the error shall be caught at compile time.

> What I am suggesting is that there may be a point at which
> adding additional expressiveness to the type system brings
> more in cost than it does in benefit.

An example of this?

I disagree with the above. Additional expressiveness can be added without making it the most usual cases more difficult to express.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Static Typing, Guard Rails and Street Signs Posted: Sep 29, 2011 9:01 AM
Reply to this message Reply
> From the scaladoc for Traversable:
>
def flatMap [B, That] (f: (A) ⇒
> GenTraversableOnce[B])(implicit bf:
> CanBuildFrom[Traversable[A], B, That]): That
A lot of
> cleverness went into constructing the Scala Collections
> API. Section 25.3 of the second edition of Programing in
> Scala goes into depth about the the various tasks required
> to get your own collection to play well with the API. At
> one level, I'm impressed by the Scala Collections API, and
> I definitely find it cool. However, I do worry that the
> result is more complex than a set of core APIs ought to
> be.
>
You left out the entry before that scaladoc signature.

def flatMap [B] (f: (A) ⇒ GenTraversableOnce[B]): CC[B]

[use case] Builds a new collection by applying a function to all elements of this collection and concatenating the results.


That's all a library user needs to worry about. I would turn your argument around: The fact that we have the signature you present is because the Scala collection library is much simpler than any of the alternatives. What could be simpler than always returninng the same collection type you started with as long as it makes sense? "Do what I mean", no need to introduce clutter and conversions back to your type.

In a sense your argument is analogous to claiming that the touchscreen on an iPhone is really too complicated because there's some sophisticated circuitry to make it work. Of course we know that this is false, my own two year old is an expert in working with my phone. The same holds for Scala's collections. They are universally acclaimed to be a fantastic blend of simplicity and power. In practice, the unwieldy signature never shows up for a user, unless that user sets out explicitly to play tricks with the system. If people don't believe me, I invite you to spend some times using Scala collections and judge for yourselves.

Now, you need to know about the long flatMap signature only if you intend to implement collection types that have the same seamless behavior as Scala's built in ones. Clearly you can't get something for nothing. If you want sophisticated behavior for your types you have at least to understand the technology. If you do not care about the sophistication and are happy for your collection ops to always return a standard type, no need to understand about CanBuildFrom either.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Static Typing, Guard Rails and Street Signs Posted: Sep 29, 2011 10:02 AM
Reply to this message Reply
> In a sense your argument is analogous to claiming that the
> touchscreen on an iPhone is really too complicated because
> there's some sophisticated circuitry to make it work.

Completely independent from whether I agree or disagree with either of your stances, I don't think this is a fair analogy. An iPhone touchscreens may be complex internally but the user completely shielded from that complexity. The point that I believe Ian is making is that the complexity of the type system is right in the users face. You could argue that the user doesn't need to understand what all of that means but it's visible all the same.

Ian Robertson

Posts: 68
Nickname: ianr
Registered: Apr, 2007

Re: Static Typing, Guard Rails and Street Signs Posted: Sep 29, 2011 10:41 AM
Reply to this message Reply
> I guess you mean this line of code:
>
> return (T) delegate.get(type);
> 

> From what I understand, the class ClassToInstanceMap is
> used to map a class T to a value of type T, right?

Right.

> Well, the cast could have been avoided if the map's value
> type was returned via a virtual function that invoked a
> user-defined function that accepted (and perhaps returned)
> the requested type.

This somewhat underscores my point. It's possible to write code which is completely type safe, but that can sometimes introduce additional complexity. In this case, it would mean either writing a custom map class, or adding an additional parameter to the Map.get method to handle and edge case. My argument is that in this case, we introduce less complexity with a @SuppressWarnings annotation than we would introduce by a completely type safe solution. It's true that maintainers of the class have to think more carefully when dealing with the code, but they don't have to maintain a custom map class, nor do their edge case needs pollute the general contract for Map.

> My point is that it's not static type systems at fault,
> but specific static type systems of languages.

Yes - a richer static type system makes it possible to reduce or possibly eliminate the need to ever step outside the type system. Unfortunately, this additional richness isn't free. It makes part of the language "experts only", and its difficult to keep complexity from leaking outside of the experts-only areas.


> > The second reason is that it implies that
> > the existence of another solution makes circumventing the
> > type system a non-solution. At worst, it's an inferior
> > solution. If the non-circumventing approach is overly
> > complicated, circumvention may even constitute the better
> > solution for the problem at hand.
>
> It depends on how dangerous the circumvention is.
> Preferably, the error shall be caught at compile time.

Here, I think we agree. Yes - it is preferable, as a rule of thumb, to catch errors at compile time. However, as you say, it depends; there can be situations where a carefully chosen cast is worth it.

I think our disagreement surrounds the question of whether a languages type system should be capable of handling any type constraints that a user might wish to express. Flexibility inevitably comes with a cost.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Static Typing, Guard Rails and Street Signs Posted: Sep 29, 2011 12:38 PM
Reply to this message Reply
> > In a sense your argument is analogous to claiming that
> the
> > touchscreen on an iPhone is really too complicated
> because
> > there's some sophisticated circuitry to make it work.
>
> Completely independent from whether I agree or disagree
> with either of your stances, I don't think this is a fair
> analogy. An iPhone touchscreens may be complex internally
> but the user completely shielded from that complexity.
> The point that I believe Ian is making is that the
> e complexity of the type system is right in the users
> face. You could argue that the user doesn't need to
> understand what all of that means but it's visible all the
> same.

So, you are arguing that if Apple published the technology behind their touchscreens, two year olds would not be able to use them anymore? I agree that being open and extensible is a difference between Scala and the iPhone, but I do not think it makes a substantial difference for my analogy.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Static Typing, Guard Rails and Street Signs Posted: Sep 30, 2011 4:32 AM
Reply to this message Reply
> This somewhat underscores my point. It's possible to write
> code which is completely type safe, but that can sometimes
> introduce additional complexity. In this case, it would
> mean either writing a custom map class, or adding an
> additional parameter to the Map.get method to handle and
> edge case. My argument is that in this case, we introduce
> less complexity with a @SuppressWarnings annotation than
> we would introduce by a completely type safe solution.
> It's true that maintainers of the class have to think more
> carefully when dealing with the code, but they don't have
> to maintain a custom map class, nor do their edge case
> needs pollute the general contract for Map.

But the actual problem here is the language. I do not see how it is an argument against static typing.

> Yes - a richer static type system makes it possible to
> reduce or possibly eliminate the need to ever step outside
> the type system. Unfortunately, this additional richness
> isn't free. It makes part of the language "experts only",
> and its difficult to keep complexity from leaking outside
> of the experts-only areas.

I really doubt that. It does not do so.

> I think our disagreement surrounds the question of whether
> a languages type system should be capable of handling any
> type constraints that a user might wish to express.

Why not? if some type constraints may be expressed by a language, then they should be expressed, by all means.

> Flexibility inevitably comes with a cost.

Really? I think Haskell proves otherwise. Cases like the example you've shown are clearly and concisely expressed in Haskell (and perhaps in Scala, I am not familiar with it).

If Java had been designed in a different way, it would be possible to do the things in your example very easily and without any cost.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Static Typing, Guard Rails and Street Signs Posted: Sep 30, 2011 2:59 PM
Reply to this message Reply
> So, you are arguing that if Apple published the technology
> behind their touchscreens, two year olds would not be able
> to use them anymore? I agree that being open and
> extensible is a difference between Scala and the iPhone,
> but I do not think it makes a substantial difference for
> my analogy.

I'm saying that if the iPhone screen displayed a schematic for it's circuitry over top of the actual application images, it would be rather intimidating to the user, regardless of whether understanding the schematic is necessary to use the touchscreen. In reality, I don't see anything hinting at the complexity of my iPhone's touchscreen (assuming it exists.) I'm not sure how you can say that is analogous to:
def flatMap [B, That] (f: (A) ⇒ GenTraversableOnce[B])(implicit bf: CanBuildFrom[Traversable[A], B, That]): That

On a slightly different tack, if the complex generics declarations do not need to be understood to use the method (which I believe you have argued in the past), why are they such a prominent part of the documentation of that method?

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Static Typing, Guard Rails and Street Signs Posted: Oct 1, 2011 1:00 AM
Reply to this message Reply
> > So, you are arguing that if Apple published the
> technology
> > behind their touchscreens, two year olds would not be
> able
> > to use them anymore? I agree that being open and
> > extensible is a difference between Scala and the
> iPhone,
> > but I do not think it makes a substantial difference
> for
> > my analogy.
>
> I'm saying that if the iPhone screen displayed a schematic
> for it's circuitry over top of the actual application
> images, it would be rather intimidating to the user,
> regardless of whether understanding the schematic is
> necessary to use the touchscreen. In reality, I don't see
> anything hinting at the complexity of my iPhone's
> touchscreen (assuming it exists.) I'm not sure how you
> can say that is analogous to:
def flatMap [B, That]
> (f: (A) ⇒ GenTraversableOnce[B])(implicit bf:
> CanBuildFrom[Traversable[A], B, That]): That


Both you and Jan are disregarding the fact that the scary signature comes after the easy one, which I have shown. Why do we still show the hard one? I have been arguing that ScalaDoc should hide full signatures better than it does now: make them available only by clicking on a link in the easy signature's comment. I think we will raise the priority of that change request now, given that the signatures of map and flatMap have become the new favorite evidence in the "Scala is too complex" argument.

When we first released collections 18 months ago I shared many of your concerns: Have we gone overboard with smart types? Will the implementation details shine through? Will naive users get confused? The experience since then has put these fears to rest. Collections are really super easy to use and the complexity does not shine through, neither in the usage patterns nor in the error diagnostics. The only place where you can see it is that second ScalaDoc signature that so many people latch on. You convinced me we should put it out of sight. I'd like to convince you and everyone else to give Scala collections a serious try and see whether you find them complex after that.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Static Typing, Guard Rails and Street Signs Posted: Oct 4, 2011 1:33 PM
Reply to this message Reply
> > I think we will raise the
> > priority of that change request now, given that the
> > signatures of map and flatMap have become the new favorite
> > evidence in the "Scala is too complex" argument.

My intent was to only critique your argumentation, not your argument. I haven't actually said that Scala is too complex. If you are interested in my opinion, I think Scala is too complex for certain contexts. This is not really a criticism, though, because I don't believe that there can be a single language that will be appropriate for all problem domains.

I think that Scala:

1. Is extremely powerful
2. Is very well designed
3. Provides the value of static typing with minimal effort
4. Is pragmatic/practical

What I don't think it is is simple. But I don't think you can create a language with this level of power and make it truly simple. There are plenty of good simple programming tools. There aren't many good powerful programming tools. I think Scala leader in it's class.

I've come to believe that there is an essential complexity to software that cannot be abstracted away. If you are holding Scala to defying that assertion, I commend you for trying but I honestly think it's a Quixotic pursuit.

I really have a hard time imagining someone learning Scala as their first programming language. It's a great tool for expert developers. I always recommend Scala to people who are in that class or on their way.

> The only place where you can see it is that second ScalaDoc
> signature that so many people latch on. You convinced me
> we should put it out of sight. I'd like to convince you
> and everyone else to give Scala collections a serious try
> and see whether you find them complex after that.

I've delved into Scala a couple of times and I plan to do so again in the near future. The idea of having dual layers of documentation may be a good one.

Flat View: This topic has 13 replies on 1 page
Topic: More on Remote Procedure Calls Previous Topic   Next Topic Topic: Scala: The Static Language that Feels Dynamic

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use