> I don't think complexity is as simple as that. It is > definitely true that Scala's type system is more > complicated than that of Python, but in exchange certain > kinds of refactoring can be simpler in Scala than Python, > figuring out what types are being passed to a method can > be simpler in Scala than Python, and so on. The complexity > of Scala's type system is there to make programmers lives > simpler when they are actually programming, just as the > complexity of the engine of your car is there to make the > lives of drivers simpler. > > I'll give you an example. In the old days, to start a car > you had to use a manual choke. And you had to take into > account the temperature outside, how long the engine has > been turned off to estimate how cold the engine is, and > the phase of the moon frankly, to try and get the car to > start. If you got this wrong in the direction of too much > air it wouldn't start, but if you got it wrong in the > other direction of too much fuel you could flood it, > making it even harder to get it to start. Nowadays the > starters that come with new cars are more sophisticated > (or as you might put it, "wildly complicated"), but in > exchange for that complexity starting a car is pretty darn > easy. You turn the key and it starts. I've been amazed at > how reliable this has become. I used to have a lot of > trouble getting cars to start when I was a teenager, but > now it just always works. > > What's most difficult about starters today, given their > complexity, is building them. Using one is easy. > Similarly, what the complexity of Scala's type system > really makes most difficult is writing a Scala compiler. > This also makes it harder to create IDE plug-ins and other > tools such as bug finders that need to analyze Scala > source code. But it is possible, and everyday programmers > don't write such tools, they just use them. > > One way tbe complexity of Scala's type system may in fact > add some complexity to your programming life, however, is > if you're designing a library. This is something > application programmers will indeed do from time to time, > though often on a team there will be more experienced > folks designing libraries and frameworks that the rest of > the team uses. So this task will often fall to more > experienced developers. But regardless, in the process of > designing a library you may find yourself scratching your > head over a tricky type problem. This is the process of > figuring out what the types should be for your library. I > can give two specific examples of type challenges from > when I was desgining ScalaTest that I found tricky if > you're interested. I had to think about these a bit, but I > was able to solve them, and they make using ScalaTest > quite easy. > > And that ease of use of ScalaTest has been my general > experience with Scala libraries. Writing code in Scala > that uses libraries is quite easy. You do need to learn > the language, and you'll need some level of understanding > of its type system to use it, but it isn't out of reach of > most programmers I've worked with. I think if someone can > program in Java they can learn to program in Scala. The > one place the complexity of the type system can rear its > ugly head for these folks is if you get a compiler error > message that is complaining about a type error. Most of > the errors you get, though, are simple enough, pointing > out a "typo" in a method call or what not. Sometimes they > aren't obvious, such as when they complain about not being > able to resolve an overloaded method call. But in my > experience very rarely does understanding a compiler error > message require a sophisticated understanding of the type > system. Most of the time the problem is you spelled a > method name wrong. Things like that. > > I know quite a few people who have done some actual > programming in Scala, and they all have complaints about > Scala. But you almost never hear them complain about "the > wild complexity" of Scala's type system. It just doesn't > turn out to be a problem in practice. The problems are > elsewhere. > > In my Devoxx talk from last December, which just came out > on Parleys today, I tried to show some ways in which Scala > makes your life simpler. You can get to it from here: > > http://tinyurl.com/dcfm4c
This is the most eloquent programming analogy I've ever read.
> > Groovy, Ruby, Python and other dynamic languages > can't. > > I don’t know, that’s going too far. Squeak has code > completion. I started learning Squeak recently and I found > eCompletion, a tool for code completion. You can see > screenshots here: > http://uncomplex.net/ecompletion/index.html > > Apparently it was Eclipse IDE that inspired it! You just > type Ctrl + Space to get a popup menu for class names, > method names, variables just like in Eclipse. It is more > fun learning that way.
Yeah, I was bit in a hurry so I didn't expand on that. I'm aware that refactoring browsers started in the Smalltalk ecosystem. But to get the level of sophistication that Java IDEs have for code completion, quick fixes, and refactoring is very, very hard or impossible in dynamically typed languages
e.g. (pseudocode)
def someFunc(obj) { return obj.someMethod() }
def anotherFunc() { var v = someFunc(new SomeObject()) v. // hard code completion someFunc can return about anything }
I know IDE plugins for some dynamic languages use some pretty cool heuristics to do refactoring, completion, quickfixes and stuff, but there's some things that are almost impossible.
Previous Topic
