- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: Scala Joe - a profile for regular Joe
Fri, 2010-10-01, 09:57
#52
Re: Scala Joe - a profile for regular Joe
On Thu, 2010-09-30 at 15:47 -0700, Russ Paielli wrote:
[ . . . ]
Not a direct response to Russ' comments, more a general response to the
thread overall . . .
> Python is great for getting something out the door fast (as you said
> about Perl), but as others have said, it is not very good for
> maintainability (for larger projects at least).
I suspect it is becoming a "known truth" that dynamic languages are
great for swift creation of small highly functional applications, but
for larger code bases static typing comes into its own even if the total
code is more verbose. Whether or not this is actually true seemingly
doesn't matter compared to the "truth" of this fact so often espoused.
There is though a factor that is missing in this debate I think and that
is the JVM.
Although Jython brings Python to the JVM, Python doesn't really fit that
well on the JVM compared to the Java/Scala/Groovy/Clojure collective.
Comparing Python to Scala is therefore comparing apples and sugar cubes.
> I am converting some of my own Python code to Scala. Part of the
> process is declaring method argument types, of course. I had always
> assumed that would be simple, but sometimes it is not. In some cases,
> figuring out the argument types in my own code is a non-trivial
> problem. But I now realize that just having those types explicitly
> declared reduces confusion and improves readability considerably. In
> fact, if the return type of a method is not trivially clear,
> explicitly declaring it also improves readability.
Another part of this is that you are shifting from non-JVM to JVM, this
is not just a Python -> not-Python debate.
For me the first question is not which language but whether the JVM
should be used. This is a simple yes/no question. If the answer is yes
then some combination of Scala, Groovy, Clojure and Java is the
implementation language team of choice. If the answer to the question
of using the JVM is no then Python/C++ or possibly D or Go become the
tools of choice.
I suggest that Python (or C, C++, Fortran, Haskell, OCaml, Ruby, etc.,
etc.) bashing is just showing the insecurity of the non-Python
communities. The converse is equally true: non-JVM based communities
bashing JVM-based languages are displaying their own insecurities. None
of this indicates anything useful about whether a particular programming
language is appropriate for a given project in a given organization and
a given context.
Choice of programming language is not a context-free choice, so nothing
general can be said about which programming language is better than
another -- except where one of the languages is clearly not fit for its
purpose.
Russ has chosen to make a shift from Python to Scala. No problem if
that works for him. It does not though mean that Python is a bad or
poor language.
In any discussion it is always important to assess the faults as well as
good aspects of any language. No problem. It is good though to avoid
tribalism and "bashing".
Fri, 2010-10-01, 10:17
#53
Re: Scala Joe - a profile for regular Joe
Moving to scala-debate.
The scala-user list is for: "questions and discussions about the Scala
programming. In particular, the following should go to this list: a)
newbie questions, b) programming experiences and questions." [1]
Debate away :)
-jason
[1] http://www.scala-lang.org/node/199
On Fri, Oct 1, 2010 at 10:51 AM, Russel Winder wrote:
> There is though a factor that is missing in this debate I think and that
> is the JVM.
Fri, 2010-10-01, 10:17
#54
Re: Scala Joe - a profile for regular Joe
Moving to scala-debate.
The scala-user list is for: "questions and discussions about the Scala
programming. In particular, the following should go to this list: a)
newbie questions, b) programming experiences and questions." [1]
Debate away :)
-jason
[1] http://www.scala-lang.org/node/199
On Fri, Oct 1, 2010 at 10:51 AM, Russel Winder wrote:
> There is though a factor that is missing in this debate I think and that
> is the JVM.
Fri, 2010-10-01, 13:27
#55
Re: Scala Joe - a profile for regular Joe
I'm not arguing the static typing, It's a religious view.
Still, do not forget content assist and edit assists...yes, they could
be (hardly) added for javascript but if you do it why not check the
types while you're at it?
Actually I think that scala strikes the right balance with static
types and inferring them. Most of the time List[String] is
sufficient...and serves as documebtation as well... I really feel, for
the most part, that scala's types indeed don't get in the way.
Yes, when you combine stuff like I mentioned with upper lower bounds,
views and I don't remember what A:B stands for, you're loosing many
people.
Having said that, individual bounds are not complex, if you know that
variance is not by default.
-----
As to a combination of closure/scala/groovy/java, I beg to differ.
Scala can do it all and it only makes sense to invest in it. It's both
compiled and interpreted, functional and compatible with Java.
-----
Sorry, I see that we got sidetracked a bit here...the bits about
selecting scala and its future are interesting but I was using them as
leverage only - I think all the arguments are obvious and most people
made up their minds and it comes down to personal preference. :)
In effect I only got direct comments about the list at hand in the
beginning. Shall we start a separate thread to which only those that
agree with the idea should answer? Or is this the end of debating the
list and I'll just work on it myself?
Thanks for the lively debate, it's great and interesting, albeit
time-consuming.
Cheers,
Razvan
On 9/30/10, Kenneth McDonald wrote:
> I'm sorry, I somewhat omitted some of my case when I first wrote.
>
> I did not mean to imply that static type checking was _only_ good for
> performance reasons. It can also considerably enhance code correctness, as
> several others have pointed out.
>
> However, as with most things, there comes a point of diminishing returns.
> Trying to statically check __too__ much leads to a very complex and
> difficult to understand type systems.
>
> IMHO, Scala is at the verge, if not slightly over the line, for this limit.
>
> Again, I'll say; a language like Groovy which permits type declarations (I
> realize Groovy decls are not checked at compile time, but that's a detail),
> while allowing "duck-typing" when necessary, would be appropriate. My belief
> is that most programmers would declare 90%+ of their types, greatly reducing
> errors and potentially increasing runtime speed. Most of the rest of the
> type errors would be easily caught by unit tests. A trivial fraction would
> escape into a release product--small enough, IMHO, to make up for the
> increased productivity and ease of use of a "mostly static" type system.
>
> Until we have such a language (if ever) such discussions will,
> unfortunately, be rather academic. However, one thing I'm willing to say
> without qualification, and as someone who spent much of a Ph.D. doing
> functional languages, including O'Caml, Haskell, Concurrent Clean, etc: The
> current type system for Scala is too scary for most programmers, and to the
> extent that it is emphasized, will scare off support.
>
> Wish that weren't the case,
> Ken McDonald
>
>
> On Sep 30, 2010, at 5:47 PM, Russ Paielli wrote:
>
>>
>>
>> On Thu, Sep 30, 2010 at 2:13 PM, Kenneth McDonald
>> wrote:
>>
>> One final note. My experience with Python has convinced me that
>> compile-time type-checking is _vastly_ overrated. 90%+ of my type errors
>> in Python are revealed in simple testing, and the remainder aren't
>> typically difficult to track down. I have great respect for the work
>> Martin Odersky et al have done, but I question if it's really necessary. I
>> wish this topic didn't suck away so much really superior talent.
>>
>>
>> Python is great for getting something out the door fast (as you said about
>> Perl), but as others have said, it is not very good for maintainability
>> (for larger projects at least).
>>
>> I am converting some of my own Python code to Scala. Part of the process
>> is declaring method argument types, of course. I had always assumed that
>> would be simple, but sometimes it is not. In some cases, figuring out the
>> argument types in my own code is a non-trivial problem. But I now realize
>> that just having those types explicitly declared reduces confusion and
>> improves readability considerably. In fact, if the return type of a method
>> is not trivially clear, explicitly declaring it also improves readability.
>>
>> Russ P.
>>
>> --
>> http://RussP.us
>
Fri, 2010-10-01, 13:47
#56
Re: Re: Scala Joe - a profile for regular Joe
I share this view that static typing has its merits, but is really strongly overrated.
That's why I am creating Babel-17 (www.babel-17.com). There will be an interpreter for it available soon, together with a Netbeans module for syntax highlighting and displaying of errors.
Right now it is purely functional, and there are no static type annotations at all. But I expect these two properties to be weakened as Babel-17 evolves.
The basic idea for Babel-17 is that I want a SERIOUS programming language, but one which also appeals to Javascriptists and Pythonistas. A PL which might later on incorporate (a little bit of) static typing as a tool, but which is designed from the ground up with the idea in mind that dynamic typing makes writing useful and versatile libraries so much easier. One example is the built-in support for data structures that would be really hard (probably impossible) to realize with a static type system.
I also did my PhD in a world where static typing rules, and I did a lot of programming in languages like Standard ML. But note how typing is simple and nice in SML, and becomes a mess when you want to do something more complicated and real-world? For me this is a sign to drop this focus on typing. There are many other ways in which programming languages can be made better.
- Steven
On 01.10.2010, at 14:20, Razvan (Pub) Cojocaru wrote:
> I'm not arguing the static typing, It's a religious view.
>
> Still, do not forget content assist and edit assists...yes, they could
> be (hardly) added for javascript but if you do it why not check the
> types while you're at it?
>
> Actually I think that scala strikes the right balance with static
> types and inferring them. Most of the time List[String] is
> sufficient...and serves as documebtation as well... I really feel, for
> the most part, that scala's types indeed don't get in the way.
>
> Yes, when you combine stuff like I mentioned with upper lower bounds,
> views and I don't remember what A:B stands for, you're loosing many
> people.
>
> Having said that, individual bounds are not complex, if you know that
> variance is not by default.
>
> -----
>
> As to a combination of closure/scala/groovy/java, I beg to differ.
> Scala can do it all and it only makes sense to invest in it. It's both
> compiled and interpreted, functional and compatible with Java.
>
> -----
>
> Sorry, I see that we got sidetracked a bit here...the bits about
> selecting scala and its future are interesting but I was using them as
> leverage only - I think all the arguments are obvious and most people
> made up their minds and it comes down to personal preference. :)
>
> In effect I only got direct comments about the list at hand in the
> beginning. Shall we start a separate thread to which only those that
> agree with the idea should answer? Or is this the end of debating the
> list and I'll just work on it myself?
>
> Thanks for the lively debate, it's great and interesting, albeit
> time-consuming.
>
> Cheers,
> Razvan
>
>
> On 9/30/10, Kenneth McDonald wrote:
>> I'm sorry, I somewhat omitted some of my case when I first wrote.
>>
>> I did not mean to imply that static type checking was _only_ good for
>> performance reasons. It can also considerably enhance code correctness, as
>> several others have pointed out.
>>
>> However, as with most things, there comes a point of diminishing returns.
>> Trying to statically check __too__ much leads to a very complex and
>> difficult to understand type systems.
>>
>> IMHO, Scala is at the verge, if not slightly over the line, for this limit.
>>
>> Again, I'll say; a language like Groovy which permits type declarations (I
>> realize Groovy decls are not checked at compile time, but that's a detail),
>> while allowing "duck-typing" when necessary, would be appropriate. My belief
>> is that most programmers would declare 90%+ of their types, greatly reducing
>> errors and potentially increasing runtime speed. Most of the rest of the
>> type errors would be easily caught by unit tests. A trivial fraction would
>> escape into a release product--small enough, IMHO, to make up for the
>> increased productivity and ease of use of a "mostly static" type system.
>>
>> Until we have such a language (if ever) such discussions will,
>> unfortunately, be rather academic. However, one thing I'm willing to say
>> without qualification, and as someone who spent much of a Ph.D. doing
>> functional languages, including O'Caml, Haskell, Concurrent Clean, etc: The
>> current type system for Scala is too scary for most programmers, and to the
>> extent that it is emphasized, will scare off support.
>>
>> Wish that weren't the case,
>> Ken McDonald
>>
>>
>> On Sep 30, 2010, at 5:47 PM, Russ Paielli wrote:
>>
>>>
>>>
>>> On Thu, Sep 30, 2010 at 2:13 PM, Kenneth McDonald
>>> wrote:
>>>
>>> One final note. My experience with Python has convinced me that
>>> compile-time type-checking is _vastly_ overrated. 90%+ of my type errors
>>> in Python are revealed in simple testing, and the remainder aren't
>>> typically difficult to track down. I have great respect for the work
>>> Martin Odersky et al have done, but I question if it's really necessary. I
>>> wish this topic didn't suck away so much really superior talent.
>>>
>>>
>>> Python is great for getting something out the door fast (as you said about
>>> Perl), but as others have said, it is not very good for maintainability
>>> (for larger projects at least).
>>>
>>> I am converting some of my own Python code to Scala. Part of the process
>>> is declaring method argument types, of course. I had always assumed that
>>> would be simple, but sometimes it is not. In some cases, figuring out the
>>> argument types in my own code is a non-trivial problem. But I now realize
>>> that just having those types explicitly declared reduces confusion and
>>> improves readability considerably. In fact, if the return type of a method
>>> is not trivially clear, explicitly declaring it also improves readability.
>>>
>>> Russ P.
>>>
>>> --
>>> http://RussP.us
>>
>
Fri, 2010-10-01, 14:07
#57
Re: Re: Scala Joe - a profile for regular Joe
It's a good book :)
Lots of strong appeal for anyone with an interest in the Sapir-Whorf hypothesis...
On 1 October 2010 13:46, Steven Obua <steven.obua@googlemail.com> wrote:
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Lots of strong appeal for anyone with an interest in the Sapir-Whorf hypothesis...
On 1 October 2010 13:46, Steven Obua <steven.obua@googlemail.com> wrote:
I share this view that static typing has its merits, but is really strongly overrated.
That's why I am creating Babel-17 (www.babel-17.com). There will be an interpreter for it available soon, together with a Netbeans module for syntax highlighting and displaying of errors.
Right now it is purely functional, and there are no static type annotations at all. But I expect these two properties to be weakened as Babel-17 evolves.
The basic idea for Babel-17 is that I want a SERIOUS programming language, but one which also appeals to Javascriptists and Pythonistas. A PL which might later on incorporate (a little bit of) static typing as a tool, but which is designed from the ground up with the idea in mind that dynamic typing makes writing useful and versatile libraries so much easier. One example is the built-in support for data structures that would be really hard (probably impossible) to realize with a static type system.
I also did my PhD in a world where static typing rules, and I did a lot of programming in languages like Standard ML. But note how typing is simple and nice in SML, and becomes a mess when you want to do something more complicated and real-world? For me this is a sign to drop this focus on typing. There are many other ways in which programming languages can be made better.
- Steven
On 01.10.2010, at 14:20, Razvan (Pub) Cojocaru wrote:
> I'm not arguing the static typing, It's a religious view.
>
> Still, do not forget content assist and edit assists...yes, they could
> be (hardly) added for javascript but if you do it why not check the
> types while you're at it?
>
> Actually I think that scala strikes the right balance with static
> types and inferring them. Most of the time List[String] is
> sufficient...and serves as documebtation as well... I really feel, for
> the most part, that scala's types indeed don't get in the way.
>
> Yes, when you combine stuff like I mentioned with upper lower bounds,
> views and I don't remember what A:B stands for, you're loosing many
> people.
>
> Having said that, individual bounds are not complex, if you know that
> variance is not by default.
>
> -----
>
> As to a combination of closure/scala/groovy/java, I beg to differ.
> Scala can do it all and it only makes sense to invest in it. It's both
> compiled and interpreted, functional and compatible with Java.
>
> -----
>
> Sorry, I see that we got sidetracked a bit here...the bits about
> selecting scala and its future are interesting but I was using them as
> leverage only - I think all the arguments are obvious and most people
> made up their minds and it comes down to personal preference. :)
>
> In effect I only got direct comments about the list at hand in the
> beginning. Shall we start a separate thread to which only those that
> agree with the idea should answer? Or is this the end of debating the
> list and I'll just work on it myself?
>
> Thanks for the lively debate, it's great and interesting, albeit
> time-consuming.
>
> Cheers,
> Razvan
>
>
> On 9/30/10, Kenneth McDonald <kenneth.m.mcdonald@sbcglobal.net> wrote:
>> I'm sorry, I somewhat omitted some of my case when I first wrote.
>>
>> I did not mean to imply that static type checking was _only_ good for
>> performance reasons. It can also considerably enhance code correctness, as
>> several others have pointed out.
>>
>> However, as with most things, there comes a point of diminishing returns.
>> Trying to statically check __too__ much leads to a very complex and
>> difficult to understand type systems.
>>
>> IMHO, Scala is at the verge, if not slightly over the line, for this limit.
>>
>> Again, I'll say; a language like Groovy which permits type declarations (I
>> realize Groovy decls are not checked at compile time, but that's a detail),
>> while allowing "duck-typing" when necessary, would be appropriate. My belief
>> is that most programmers would declare 90%+ of their types, greatly reducing
>> errors and potentially increasing runtime speed. Most of the rest of the
>> type errors would be easily caught by unit tests. A trivial fraction would
>> escape into a release product--small enough, IMHO, to make up for the
>> increased productivity and ease of use of a "mostly static" type system.
>>
>> Until we have such a language (if ever) such discussions will,
>> unfortunately, be rather academic. However, one thing I'm willing to say
>> without qualification, and as someone who spent much of a Ph.D. doing
>> functional languages, including O'Caml, Haskell, Concurrent Clean, etc: The
>> current type system for Scala is too scary for most programmers, and to the
>> extent that it is emphasized, will scare off support.
>>
>> Wish that weren't the case,
>> Ken McDonald
>>
>>
>> On Sep 30, 2010, at 5:47 PM, Russ Paielli wrote:
>>
>>>
>>>
>>> On Thu, Sep 30, 2010 at 2:13 PM, Kenneth McDonald
>>> <kenneth.m.mcdonald@sbcglobal.net> wrote:
>>>
>>> One final note. My experience with Python has convinced me that
>>> compile-time type-checking is _vastly_ overrated. 90%+ of my type errors
>>> in Python are revealed in simple testing, and the remainder aren't
>>> typically difficult to track down. I have great respect for the work
>>> Martin Odersky et al have done, but I question if it's really necessary. I
>>> wish this topic didn't suck away so much really superior talent.
>>>
>>>
>>> Python is great for getting something out the door fast (as you said about
>>> Perl), but as others have said, it is not very good for maintainability
>>> (for larger projects at least).
>>>
>>> I am converting some of my own Python code to Scala. Part of the process
>>> is declaring method argument types, of course. I had always assumed that
>>> would be simple, but sometimes it is not. In some cases, figuring out the
>>> argument types in my own code is a non-trivial problem. But I now realize
>>> that just having those types explicitly declared reduces confusion and
>>> improves readability considerably. In fact, if the return type of a method
>>> is not trivially clear, explicitly declaring it also improves readability.
>>>
>>> Russ P.
>>>
>>> --
>>> http://RussP.us
>>
>
> --
> Sent from my mobile device
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Fri, 2010-10-01, 14:27
#58
Re: Re: Scala Joe - a profile for regular Joe
Leave the Klingons alone!
Viktor KlangCode Connoisseurwww.akkasource.com
On Oct 1, 2010, at 14:57, Kevin Wright <kev.lee.wright@gmail.com> wrote:
Viktor KlangCode Connoisseurwww.akkasource.com
On Oct 1, 2010, at 14:57, Kevin Wright <kev.lee.wright@gmail.com> wrote:
It's a good book :)
Lots of strong appeal for anyone with an interest in the Sapir-Whorf hypothesis...
On 1 October 2010 13:46, Steven Obua < (steven [dot] obua [at] googlemail [dot] com> wrote:
I share this view that static typing has its merits, but is really strongly overrated.
That's why I am creating Babel-17 (www.babel-17.com). There will be an interpreter for it available soon, together with a Netbeans module for syntax highlighting and displaying of errors.
Right now it is purely functional, and there are no static type annotations at all. But I expect these two properties to be weakened as Babel-17 evolves.
The basic idea for Babel-17 is that I want a SERIOUS programming language, but one which also appeals to Javascriptists and Pythonistas. A PL which might later on incorporate (a little bit of) static typing as a tool, but which is designed from the ground up with the idea in mind that dynamic typing makes writing useful and versatile libraries so much easier. One example is the built-in support for data structures that would be really hard (probably impossible) to realize with a static type system.
I also did my PhD in a world where static typing rules, and I did a lot of programming in languages like Standard ML. But note how typing is simple and nice in SML, and becomes a mess when you want to do something more complicated and real-world? For me this is a sign to drop this focus on typing. There are many other ways in which programming languages can be made better.
- Steven
On 01.10.2010, at 14:20, Razvan (Pub) Cojocaru wrote:
> I'm not arguing the static typing, It's a religious view.
>
> Still, do not forget content assist and edit assists...yes, they could
> be (hardly) added for javascript but if you do it why not check the
> types while you're at it?
>
> Actually I think that scala strikes the right balance with static
> types and inferring them. Most of the time List[String] is
> sufficient...and serves as documebtation as well... I really feel, for
> the most part, that scala's types indeed don't get in the way.
>
> Yes, when you combine stuff like I mentioned with upper lower bounds,
> views and I don't remember what A:B stands for, you're loosing many
> people.
>
> Having said that, individual bounds are not complex, if you know that
> variance is not by default.
>
> -----
>
> As to a combination of closure/scala/groovy/java, I beg to differ.
> Scala can do it all and it only makes sense to invest in it. It's both
> compiled and interpreted, functional and compatible with Java.
>
> -----
>
> Sorry, I see that we got sidetracked a bit here...the bits about
> selecting scala and its future are interesting but I was using them as
> leverage only - I think all the arguments are obvious and most people
> made up their minds and it comes down to personal preference. :)
>
> In effect I only got direct comments about the list at hand in the
> beginning. Shall we start a separate thread to which only those that
> agree with the idea should answer? Or is this the end of debating the
> list and I'll just work on it myself?
>
> Thanks for the lively debate, it's great and interesting, albeit
> time-consuming.
>
> Cheers,
> Razvan
>
>
> On 9/30/10, Kenneth McDonald < (kenneth [dot] m [dot] mcdonald [at] sbcglobal [dot] net> wrote:
>> I'm sorry, I somewhat omitted some of my case when I first wrote.
>>
>> I did not mean to imply that static type checking was _only_ good for
>> performance reasons. It can also considerably enhance code correctness, as
>> several others have pointed out.
>>
>> However, as with most things, there comes a point of diminishing returns.
>> Trying to statically check __too__ much leads to a very complex and
>> difficult to understand type systems.
>>
>> IMHO, Scala is at the verge, if not slightly over the line, for this limit.
>>
>> Again, I'll say; a language like Groovy which permits type declarations (I
>> realize Groovy decls are not checked at compile time, but that's a detail),
>> while allowing "duck-typing" when necessary, would be appropriate. My belief
>> is that most programmers would declare 90%+ of their types, greatly reducing
>> errors and potentially increasing runtime speed. Most of the rest of the
>> type errors would be easily caught by unit tests. A trivial fraction would
>> escape into a release product--small enough, IMHO, to make up for the
>> increased productivity and ease of use of a "mostly static" type system.
>>
>> Until we have such a language (if ever) such discussions will,
>> unfortunately, be rather academic. However, one thing I'm willing to say
>> without qualification, and as someone who spent much of a Ph.D. doing
>> functional languages, including O'Caml, Haskell, Concurrent Clean, etc: The
>> current type system for Scala is too scary for most programmers, and to the
>> extent that it is emphasized, will scare off support.
>>
>> Wish that weren't the case,
>> Ken McDonald
>>
>>
>> On Sep 30, 2010, at 5:47 PM, Russ Paielli wrote:
>>
>>>
>>>
>>> On Thu, Sep 30, 2010 at 2:13 PM, Kenneth McDonald
>>> < (kenneth [dot] m [dot] mcdonald [at] sbcglobal [dot] net> wrote:
>>>
>>> One final note. My experience with Python has convinced me that
>>> compile-time type-checking is _vastly_ overrated. 90%+ of my type errors
>>> in Python are revealed in simple testing, and the remainder aren't
>>> typically difficult to track down. I have great respect for the work
>>> Martin Odersky et al have done, but I question if it's really necessary. I
>>> wish this topic didn't suck away so much really superior talent.
>>>
>>>
>>> Python is great for getting something out the door fast (as you said about
>>> Perl), but as others have said, it is not very good for maintainability
>>> (for larger projects at least).
>>>
>>> I am converting some of my own Python code to Scala. Part of the process
>>> is declaring method argument types, of course. I had always assumed that
>>> would be simple, but sometimes it is not. In some cases, figuring out the
>>> argument types in my own code is a non-trivial problem. But I now realize
>>> that just having those types explicitly declared reduces confusion and
>>> improves readability considerably. In fact, if the return type of a method
>>> is not trivially clear, explicitly declaring it also improves readability.
>>>
>>> Russ P.
>>>
>>> --
>>> http://RussP.us
>>
>
> --
> Sent from my mobile device
--
Kevin Wright
mail / gtalk / msn : (kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda
Fri, 2010-10-01, 14:37
#59
Re: Scala Joe - a profile for regular Joe
Ok...since its all now going this way and you're in the know...
One of the big issues I have with adopting languages with no static
typing for -serious- development (like 100+ developers and 2+ million
lines of code) is not having a freaking clue that, when upgrading to
the latest -minor- version of an underlying library, say extjs,
someone did or did not break my code...
I will only know that in production, when someone triggers a branch
that wasn't covered by regression testing...
How is this usually handled in -serious- shops using no static type
checking? Lots of unit testing? Test coverage indicators? Doesn't that
take more time?
I'm sorry, maybe this has an obvious solution that I'm oblivious to...
On 10/1/10, Steven Obua wrote:
> I share this view that static typing has its merits, but is really strongly
> overrated.
> That's why I am creating Babel-17 (www.babel-17.com). There will be an
> interpreter for it available soon, together with a Netbeans module for
> syntax highlighting and displaying of errors.
>
> Right now it is purely functional, and there are no static type annotations
> at all. But I expect these two properties to be weakened as Babel-17
> evolves.
>
> The basic idea for Babel-17 is that I want a SERIOUS programming language,
> but one which also appeals to Javascriptists and Pythonistas. A PL which
> might later on incorporate (a little bit of) static typing as a tool, but
> which is designed from the ground up with the idea in mind that dynamic
> typing makes writing useful and versatile libraries so much easier. One
> example is the built-in support for data structures that would be really
> hard (probably impossible) to realize with a static type system.
>
> I also did my PhD in a world where static typing rules, and I did a lot of
> programming in languages like Standard ML. But note how typing is simple and
> nice in SML, and becomes a mess when you want to do something more
> complicated and real-world? For me this is a sign to drop this focus on
> typing. There are many other ways in which programming languages can be made
> better.
>
> - Steven
>
> On 01.10.2010, at 14:20, Razvan (Pub) Cojocaru wrote:
>
>> I'm not arguing the static typing, It's a religious view.
>>
>> Still, do not forget content assist and edit assists...yes, they could
>> be (hardly) added for javascript but if you do it why not check the
>> types while you're at it?
>>
>> Actually I think that scala strikes the right balance with static
>> types and inferring them. Most of the time List[String] is
>> sufficient...and serves as documebtation as well... I really feel, for
>> the most part, that scala's types indeed don't get in the way.
>>
>> Yes, when you combine stuff like I mentioned with upper lower bounds,
>> views and I don't remember what A:B stands for, you're loosing many
>> people.
>>
>> Having said that, individual bounds are not complex, if you know that
>> variance is not by default.
>>
>> -----
>>
>> As to a combination of closure/scala/groovy/java, I beg to differ.
>> Scala can do it all and it only makes sense to invest in it. It's both
>> compiled and interpreted, functional and compatible with Java.
>>
>> -----
>>
>> Sorry, I see that we got sidetracked a bit here...the bits about
>> selecting scala and its future are interesting but I was using them as
>> leverage only - I think all the arguments are obvious and most people
>> made up their minds and it comes down to personal preference. :)
>>
>> In effect I only got direct comments about the list at hand in the
>> beginning. Shall we start a separate thread to which only those that
>> agree with the idea should answer? Or is this the end of debating the
>> list and I'll just work on it myself?
>>
>> Thanks for the lively debate, it's great and interesting, albeit
>> time-consuming.
>>
>> Cheers,
>> Razvan
>>
>>
>> On 9/30/10, Kenneth McDonald wrote:
>>> I'm sorry, I somewhat omitted some of my case when I first wrote.
>>>
>>> I did not mean to imply that static type checking was _only_ good for
>>> performance reasons. It can also considerably enhance code correctness,
>>> as
>>> several others have pointed out.
>>>
>>> However, as with most things, there comes a point of diminishing returns.
>>> Trying to statically check __too__ much leads to a very complex and
>>> difficult to understand type systems.
>>>
>>> IMHO, Scala is at the verge, if not slightly over the line, for this
>>> limit.
>>>
>>> Again, I'll say; a language like Groovy which permits type declarations
>>> (I
>>> realize Groovy decls are not checked at compile time, but that's a
>>> detail),
>>> while allowing "duck-typing" when necessary, would be appropriate. My
>>> belief
>>> is that most programmers would declare 90%+ of their types, greatly
>>> reducing
>>> errors and potentially increasing runtime speed. Most of the rest of the
>>> type errors would be easily caught by unit tests. A trivial fraction
>>> would
>>> escape into a release product--small enough, IMHO, to make up for the
>>> increased productivity and ease of use of a "mostly static" type system.
>>>
>>> Until we have such a language (if ever) such discussions will,
>>> unfortunately, be rather academic. However, one thing I'm willing to say
>>> without qualification, and as someone who spent much of a Ph.D. doing
>>> functional languages, including O'Caml, Haskell, Concurrent Clean, etc:
>>> The
>>> current type system for Scala is too scary for most programmers, and to
>>> the
>>> extent that it is emphasized, will scare off support.
>>>
>>> Wish that weren't the case,
>>> Ken McDonald
>>>
>>>
>>> On Sep 30, 2010, at 5:47 PM, Russ Paielli wrote:
>>>
>>>>
>>>>
>>>> On Thu, Sep 30, 2010 at 2:13 PM, Kenneth McDonald
>>>> wrote:
>>>>
>>>> One final note. My experience with Python has convinced me that
>>>> compile-time type-checking is _vastly_ overrated. 90%+ of my type errors
>>>> in Python are revealed in simple testing, and the remainder aren't
>>>> typically difficult to track down. I have great respect for the work
>>>> Martin Odersky et al have done, but I question if it's really necessary.
>>>> I
>>>> wish this topic didn't suck away so much really superior talent.
>>>>
>>>>
>>>> Python is great for getting something out the door fast (as you said
>>>> about
>>>> Perl), but as others have said, it is not very good for maintainability
>>>> (for larger projects at least).
>>>>
>>>> I am converting some of my own Python code to Scala. Part of the process
>>>> is declaring method argument types, of course. I had always assumed that
>>>> would be simple, but sometimes it is not. In some cases, figuring out
>>>> the
>>>> argument types in my own code is a non-trivial problem. But I now
>>>> realize
>>>> that just having those types explicitly declared reduces confusion and
>>>> improves readability considerably. In fact, if the return type of a
>>>> method
>>>> is not trivially clear, explicitly declaring it also improves
>>>> readability.
>>>>
>>>> Russ P.
>>>>
>>>> --
>>>> http://RussP.us
>>>
>>
>> --
>> Sent from my mobile device
>
>
Fri, 2010-10-01, 15:27
#60
Re: Re: Scala Joe - a profile for regular Joe
On Friday October 1 2010, Razvan (Pub) Cojocaru wrote:
> I'm not arguing the static typing, It's a religious view.
Unless you and I define "religion" very differently, the merits and
drawbacks of static typing (or any other type system) are in no way
religious.
What language a given programmer chooses, when given that choice, may be
highly subjective and may well be based on non-technical factors and
that puts it at least partly in the realm of psychology. But the
languages themselves are what they are. They have known properties.
Their is nothing supernatural, untestable or mythological about them.
> ...
Randall Schulz
Fri, 2010-10-01, 15:37
#61
Re: Scala Joe - a profile for regular Joe
Of course you will need something to replace static typechecking in such large projects. I think you could well use techniques from static typechecking + stuff like abstract interpretation and theorem proving to help you build these big programs. What I am saying is that putting static typechecking into the language is premature. It closes your eyes to the whole range of possibilities for ensuring consistency between libraries and their clients.
But yes, I see your point. Simply leaving out static typechecking does not cut it.
- Steven
On 01.10.2010, at 15:25, Razvan (Pub) Cojocaru wrote:
> Ok...since its all now going this way and you're in the know...
>
> One of the big issues I have with adopting languages with no static
> typing for -serious- development (like 100+ developers and 2+ million
> lines of code) is not having a freaking clue that, when upgrading to
> the latest -minor- version of an underlying library, say extjs,
> someone did or did not break my code...
>
> I will only know that in production, when someone triggers a branch
> that wasn't covered by regression testing...
>
> How is this usually handled in -serious- shops using no static type
> checking? Lots of unit testing? Test coverage indicators? Doesn't that
> take more time?
>
> I'm sorry, maybe this has an obvious solution that I'm oblivious to...
>
>
>
> On 10/1/10, Steven Obua wrote:
>> I share this view that static typing has its merits, but is really strongly
>> overrated.
>> That's why I am creating Babel-17 (www.babel-17.com). There will be an
>> interpreter for it available soon, together with a Netbeans module for
>> syntax highlighting and displaying of errors.
>>
>> Right now it is purely functional, and there are no static type annotations
>> at all. But I expect these two properties to be weakened as Babel-17
>> evolves.
>>
>> The basic idea for Babel-17 is that I want a SERIOUS programming language,
>> but one which also appeals to Javascriptists and Pythonistas. A PL which
>> might later on incorporate (a little bit of) static typing as a tool, but
>> which is designed from the ground up with the idea in mind that dynamic
>> typing makes writing useful and versatile libraries so much easier. One
>> example is the built-in support for data structures that would be really
>> hard (probably impossible) to realize with a static type system.
>>
>> I also did my PhD in a world where static typing rules, and I did a lot of
>> programming in languages like Standard ML. But note how typing is simple and
>> nice in SML, and becomes a mess when you want to do something more
>> complicated and real-world? For me this is a sign to drop this focus on
>> typing. There are many other ways in which programming languages can be made
>> better.
>>
>> - Steven
>>
>> On 01.10.2010, at 14:20, Razvan (Pub) Cojocaru wrote:
>>
>>> I'm not arguing the static typing, It's a religious view.
>>>
>>> Still, do not forget content assist and edit assists...yes, they could
>>> be (hardly) added for javascript but if you do it why not check the
>>> types while you're at it?
>>>
>>> Actually I think that scala strikes the right balance with static
>>> types and inferring them. Most of the time List[String] is
>>> sufficient...and serves as documebtation as well... I really feel, for
>>> the most part, that scala's types indeed don't get in the way.
>>>
>>> Yes, when you combine stuff like I mentioned with upper lower bounds,
>>> views and I don't remember what A:B stands for, you're loosing many
>>> people.
>>>
>>> Having said that, individual bounds are not complex, if you know that
>>> variance is not by default.
>>>
>>> -----
>>>
>>> As to a combination of closure/scala/groovy/java, I beg to differ.
>>> Scala can do it all and it only makes sense to invest in it. It's both
>>> compiled and interpreted, functional and compatible with Java.
>>>
>>> -----
>>>
>>> Sorry, I see that we got sidetracked a bit here...the bits about
>>> selecting scala and its future are interesting but I was using them as
>>> leverage only - I think all the arguments are obvious and most people
>>> made up their minds and it comes down to personal preference. :)
>>>
>>> In effect I only got direct comments about the list at hand in the
>>> beginning. Shall we start a separate thread to which only those that
>>> agree with the idea should answer? Or is this the end of debating the
>>> list and I'll just work on it myself?
>>>
>>> Thanks for the lively debate, it's great and interesting, albeit
>>> time-consuming.
>>>
>>> Cheers,
>>> Razvan
>>>
>>>
>>> On 9/30/10, Kenneth McDonald wrote:
>>>> I'm sorry, I somewhat omitted some of my case when I first wrote.
>>>>
>>>> I did not mean to imply that static type checking was _only_ good for
>>>> performance reasons. It can also considerably enhance code correctness,
>>>> as
>>>> several others have pointed out.
>>>>
>>>> However, as with most things, there comes a point of diminishing returns.
>>>> Trying to statically check __too__ much leads to a very complex and
>>>> difficult to understand type systems.
>>>>
>>>> IMHO, Scala is at the verge, if not slightly over the line, for this
>>>> limit.
>>>>
>>>> Again, I'll say; a language like Groovy which permits type declarations
>>>> (I
>>>> realize Groovy decls are not checked at compile time, but that's a
>>>> detail),
>>>> while allowing "duck-typing" when necessary, would be appropriate. My
>>>> belief
>>>> is that most programmers would declare 90%+ of their types, greatly
>>>> reducing
>>>> errors and potentially increasing runtime speed. Most of the rest of the
>>>> type errors would be easily caught by unit tests. A trivial fraction
>>>> would
>>>> escape into a release product--small enough, IMHO, to make up for the
>>>> increased productivity and ease of use of a "mostly static" type system.
>>>>
>>>> Until we have such a language (if ever) such discussions will,
>>>> unfortunately, be rather academic. However, one thing I'm willing to say
>>>> without qualification, and as someone who spent much of a Ph.D. doing
>>>> functional languages, including O'Caml, Haskell, Concurrent Clean, etc:
>>>> The
>>>> current type system for Scala is too scary for most programmers, and to
>>>> the
>>>> extent that it is emphasized, will scare off support.
>>>>
>>>> Wish that weren't the case,
>>>> Ken McDonald
>>>>
>>>>
>>>> On Sep 30, 2010, at 5:47 PM, Russ Paielli wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 30, 2010 at 2:13 PM, Kenneth McDonald
>>>>> wrote:
>>>>>
>>>>> One final note. My experience with Python has convinced me that
>>>>> compile-time type-checking is _vastly_ overrated. 90%+ of my type errors
>>>>> in Python are revealed in simple testing, and the remainder aren't
>>>>> typically difficult to track down. I have great respect for the work
>>>>> Martin Odersky et al have done, but I question if it's really necessary.
>>>>> I
>>>>> wish this topic didn't suck away so much really superior talent.
>>>>>
>>>>>
>>>>> Python is great for getting something out the door fast (as you said
>>>>> about
>>>>> Perl), but as others have said, it is not very good for maintainability
>>>>> (for larger projects at least).
>>>>>
>>>>> I am converting some of my own Python code to Scala. Part of the process
>>>>> is declaring method argument types, of course. I had always assumed that
>>>>> would be simple, but sometimes it is not. In some cases, figuring out
>>>>> the
>>>>> argument types in my own code is a non-trivial problem. But I now
>>>>> realize
>>>>> that just having those types explicitly declared reduces confusion and
>>>>> improves readability considerably. In fact, if the return type of a
>>>>> method
>>>>> is not trivially clear, explicitly declaring it also improves
>>>>> readability.
>>>>>
>>>>> Russ P.
>>>>>
>>>>> --
>>>>> http://RussP.us
>>>>
>>>
>>> --
>>> Sent from my mobile device
>>
>>
>
Fri, 2010-10-01, 18:57
#62
Re: Re: Scala Joe - a profile for regular Joe
And how does static typing let you know that someone hasn't made a (minor) semantic change to the code that still breaks your program?
As with anything else (and I know I've said this before, please bear the repetition), static typing is subject to diminishing returns. I'm a Pythonista, but do I wish Python had some sort of static typing? You bet. I really like Scala, but do I wish its type system was simpler? You bet.
Are these two goals irreconcilable? I don't think so. Give me a language that lets me declare simple static types (including things like List[Int]) in the 90%+ of the cases I need them, that lets me perform ugly but necessary type casts when necessary, and that allows duck-typing in the very small number of cases its really useful--but there, it is _really_ useful. That would give most of the benefits of static typing without making the language look like a theoretical math construct. It would allow dynamic typing, and I don't believe this would be abused. (As a Pythonista, I've often wished for the ability to declare the types of arguments to functions.) And most of all, it wouldn't violate Ken's Rule of Programming :-) , which is, "there is no one solution".
I've seen too many instances where there was going to be one particular solution to the software crisis. The Japanese "fifth generation" and Prolog. AI. ClearCase and Rational Rose. All these lie on the dustheap of failed solutions. Static typing, if carried too far, will suffer the same fate. (I mean, it's not going to disappear, but it could hurt the adoption of Scala).
This is a little more rambling than I'd intended, but I guess what I want to say is that Scala is, right now, in fairly serious danger of alienating a big part of its potential constituency because of the complexity of its type system. I hope it doesn't make things more complex in the future.
Ken
On Oct 1, 2010, at 8:25 AM, Razvan (Pub) Cojocaru wrote:
> Ok...since its all now going this way and you're in the know...
>
> One of the big issues I have with adopting languages with no static
> typing for -serious- development (like 100+ developers and 2+ million
> lines of code) is not having a freaking clue that, when upgrading to
> the latest -minor- version of an underlying library, say extjs,
> someone did or did not break my code...
>
> I will only know that in production, when someone triggers a branch
> that wasn't covered by regression testing...
>
> How is this usually handled in -serious- shops using no static type
> checking? Lots of unit testing? Test coverage indicators? Doesn't that
> take more time?
>
> I'm sorry, maybe this has an obvious solution that I'm oblivious to...
>
>
>
> On 10/1/10, Steven Obua wrote:
>> I share this view that static typing has its merits, but is really strongly
>> overrated.
>> That's why I am creating Babel-17 (www.babel-17.com). There will be an
>> interpreter for it available soon, together with a Netbeans module for
>> syntax highlighting and displaying of errors.
>>
>> Right now it is purely functional, and there are no static type annotations
>> at all. But I expect these two properties to be weakened as Babel-17
>> evolves.
>>
>> The basic idea for Babel-17 is that I want a SERIOUS programming language,
>> but one which also appeals to Javascriptists and Pythonistas. A PL which
>> might later on incorporate (a little bit of) static typing as a tool, but
>> which is designed from the ground up with the idea in mind that dynamic
>> typing makes writing useful and versatile libraries so much easier. One
>> example is the built-in support for data structures that would be really
>> hard (probably impossible) to realize with a static type system.
>>
>> I also did my PhD in a world where static typing rules, and I did a lot of
>> programming in languages like Standard ML. But note how typing is simple and
>> nice in SML, and becomes a mess when you want to do something more
>> complicated and real-world? For me this is a sign to drop this focus on
>> typing. There are many other ways in which programming languages can be made
>> better.
>>
>> - Steven
>>
>> On 01.10.2010, at 14:20, Razvan (Pub) Cojocaru wrote:
>>
>>> I'm not arguing the static typing, It's a religious view.
>>>
>>> Still, do not forget content assist and edit assists...yes, they could
>>> be (hardly) added for javascript but if you do it why not check the
>>> types while you're at it?
>>>
>>> Actually I think that scala strikes the right balance with static
>>> types and inferring them. Most of the time List[String] is
>>> sufficient...and serves as documebtation as well... I really feel, for
>>> the most part, that scala's types indeed don't get in the way.
>>>
>>> Yes, when you combine stuff like I mentioned with upper lower bounds,
>>> views and I don't remember what A:B stands for, you're loosing many
>>> people.
>>>
>>> Having said that, individual bounds are not complex, if you know that
>>> variance is not by default.
>>>
>>> -----
>>>
>>> As to a combination of closure/scala/groovy/java, I beg to differ.
>>> Scala can do it all and it only makes sense to invest in it. It's both
>>> compiled and interpreted, functional and compatible with Java.
>>>
>>> -----
>>>
>>> Sorry, I see that we got sidetracked a bit here...the bits about
>>> selecting scala and its future are interesting but I was using them as
>>> leverage only - I think all the arguments are obvious and most people
>>> made up their minds and it comes down to personal preference. :)
>>>
>>> In effect I only got direct comments about the list at hand in the
>>> beginning. Shall we start a separate thread to which only those that
>>> agree with the idea should answer? Or is this the end of debating the
>>> list and I'll just work on it myself?
>>>
>>> Thanks for the lively debate, it's great and interesting, albeit
>>> time-consuming.
>>>
>>> Cheers,
>>> Razvan
>>>
>>>
>>> On 9/30/10, Kenneth McDonald wrote:
>>>> I'm sorry, I somewhat omitted some of my case when I first wrote.
>>>>
>>>> I did not mean to imply that static type checking was _only_ good for
>>>> performance reasons. It can also considerably enhance code correctness,
>>>> as
>>>> several others have pointed out.
>>>>
>>>> However, as with most things, there comes a point of diminishing returns.
>>>> Trying to statically check __too__ much leads to a very complex and
>>>> difficult to understand type systems.
>>>>
>>>> IMHO, Scala is at the verge, if not slightly over the line, for this
>>>> limit.
>>>>
>>>> Again, I'll say; a language like Groovy which permits type declarations
>>>> (I
>>>> realize Groovy decls are not checked at compile time, but that's a
>>>> detail),
>>>> while allowing "duck-typing" when necessary, would be appropriate. My
>>>> belief
>>>> is that most programmers would declare 90%+ of their types, greatly
>>>> reducing
>>>> errors and potentially increasing runtime speed. Most of the rest of the
>>>> type errors would be easily caught by unit tests. A trivial fraction
>>>> would
>>>> escape into a release product--small enough, IMHO, to make up for the
>>>> increased productivity and ease of use of a "mostly static" type system.
>>>>
>>>> Until we have such a language (if ever) such discussions will,
>>>> unfortunately, be rather academic. However, one thing I'm willing to say
>>>> without qualification, and as someone who spent much of a Ph.D. doing
>>>> functional languages, including O'Caml, Haskell, Concurrent Clean, etc:
>>>> The
>>>> current type system for Scala is too scary for most programmers, and to
>>>> the
>>>> extent that it is emphasized, will scare off support.
>>>>
>>>> Wish that weren't the case,
>>>> Ken McDonald
>>>>
>>>>
>>>> On Sep 30, 2010, at 5:47 PM, Russ Paielli wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 30, 2010 at 2:13 PM, Kenneth McDonald
>>>>> wrote:
>>>>>
>>>>> One final note. My experience with Python has convinced me that
>>>>> compile-time type-checking is _vastly_ overrated. 90%+ of my type errors
>>>>> in Python are revealed in simple testing, and the remainder aren't
>>>>> typically difficult to track down. I have great respect for the work
>>>>> Martin Odersky et al have done, but I question if it's really necessary.
>>>>> I
>>>>> wish this topic didn't suck away so much really superior talent.
>>>>>
>>>>>
>>>>> Python is great for getting something out the door fast (as you said
>>>>> about
>>>>> Perl), but as others have said, it is not very good for maintainability
>>>>> (for larger projects at least).
>>>>>
>>>>> I am converting some of my own Python code to Scala. Part of the process
>>>>> is declaring method argument types, of course. I had always assumed that
>>>>> would be simple, but sometimes it is not. In some cases, figuring out
>>>>> the
>>>>> argument types in my own code is a non-trivial problem. But I now
>>>>> realize
>>>>> that just having those types explicitly declared reduces confusion and
>>>>> improves readability considerably. In fact, if the return type of a
>>>>> method
>>>>> is not trivially clear, explicitly declaring it also improves
>>>>> readability.
>>>>>
>>>>> Russ P.
>>>>>
>>>>> --
>>>>> http://RussP.us
>>>>
>>>
>>> --
>>> Sent from my mobile device
>>
>>
>
Fri, 2010-10-01, 19:07
#63
Re: Re: Scala Joe - a profile for regular Joe
On Friday October 1 2010, Kenneth McDonald wrote:
> ... I really like Scala, but do I wish its
> type system was simpler? You bet.
Why would you want type system simpler?
So you can do fewer things with it?
> ...
>
> Ken
Randall Schulz
Fri, 2010-10-01, 19:17
#64
Re: Re: Scala Joe - a profile for regular Joe
> On Friday October 1 2010, Kenneth McDonald wrote:
>> ... I really like Scala, but do I wish its
>> type system was simpler? You bet.
>
> Why would you want type system simpler?
> So you can do fewer things with it?
I agree with Kenneth here. First, you cannot do anything with a type system. A type system just restricts you. A more advanced type system restricts you less, and the most advanced one simply vanishes into thin air.
:-)
- Steven
Fri, 2010-10-01, 19:37
#65
Re: Re: Scala Joe - a profile for regular Joe
Types are evil...
For example, if I'm travelling at a speed of 19, and my destination is 47 away, how long would it take me to get there?I can just see how giving types to all those numbers would complicate things!
On 1 October 2010 19:13, Steven Obua <steven.obua@googlemail.com> wrote:
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
For example, if I'm travelling at a speed of 19, and my destination is 47 away, how long would it take me to get there?I can just see how giving types to all those numbers would complicate things!
On 1 October 2010 19:13, Steven Obua <steven.obua@googlemail.com> wrote:
> On Friday October 1 2010, Kenneth McDonald wrote:
>> ... I really like Scala, but do I wish its
>> type system was simpler? You bet.
>
> Why would you want type system simpler?
> So you can do fewer things with it?
I agree with Kenneth here. First, you cannot do anything with a type system. A type system just restricts you. A more advanced type system restricts you less, and the most advanced one simply vanishes into thin air.
:-)
- Steven
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Fri, 2010-10-01, 19:47
#66
RE: Re: Scala Joe - a profile for regular Joe
@Kevin
The answer to everything is 42, it's Long and it takes about 3 inches, in a
jar... you should know that!
@Keneth:
I didn't think this needed explanation: there are two ways a program can
break due to a change in a library:
a) behavior change. Not often in a mature product, usually accompanied by
NAME CHANGES.
b) NAME CHANGE, by mistake or voluntary.
Code breaks *at runtime*, since nobody checks that my calling
"subscriber.getFriends" has been renamed to "getFriend"...by mistake or on
purpose. Or that it's return type changed from a Seq to a Map or a number of
similar changes... YES, it can be handled by a tool that
checks...types...before the program is run, i.e. statically!
@Randall
Google defines religion as "a set of beliefs concerning the cause, nature,
and purpose of the universe"
It's not about the facts...but the beliefs at which one arrives, based on
the same set of facts.
-----Original Message-----
From: Kenneth McDonald [mailto:kenneth.m.mcdonald@sbcglobal.net]
Sent: Friday, October 01, 2010 1:54 PM
To: Razvan (Pub) Cojocaru
Cc: Steven Obua; scala-debate
Subject: Re: [scala-debate] Re: [scala-user] Scala Joe - a profile for
regular Joe
And how does static typing let you know that someone hasn't made a (minor)
semantic change to the code that still breaks your program?
As with anything else (and I know I've said this before, please bear the
repetition), static typing is subject to diminishing returns. I'm a
Pythonista, but do I wish Python had some sort of static typing? You bet. I
really like Scala, but do I wish its type system was simpler? You bet.
Are these two goals irreconcilable? I don't think so. Give me a language
that lets me declare simple static types (including things like List[Int])
in the 90%+ of the cases I need them, that lets me perform ugly but
necessary type casts when necessary, and that allows duck-typing in the very
small number of cases its really useful--but there, it is _really_ useful.
That would give most of the benefits of static typing without making the
language look like a theoretical math construct. It would allow dynamic
typing, and I don't believe this would be abused. (As a Pythonista, I've
often wished for the ability to declare the types of arguments to
functions.) And most of all, it wouldn't violate Ken's Rule of Programming
:-) , which is, "there is no one solution".
I've seen too many instances where there was going to be one particular
solution to the software crisis. The Japanese "fifth generation" and Prolog.
AI. ClearCase and Rational Rose. All these lie on the dustheap of failed
solutions. Static typing, if carried too far, will suffer the same fate. (I
mean, it's not going to disappear, but it could hurt the adoption of Scala).
This is a little more rambling than I'd intended, but I guess what I want to
say is that Scala is, right now, in fairly serious danger of alienating a
big part of its potential constituency because of the complexity of its type
system. I hope it doesn't make things more complex in the future.
Ken
On Oct 1, 2010, at 8:25 AM, Razvan (Pub) Cojocaru wrote:
> Ok...since its all now going this way and you're in the know...
>
> One of the big issues I have with adopting languages with no static
> typing for -serious- development (like 100+ developers and 2+ million
> lines of code) is not having a freaking clue that, when upgrading to
> the latest -minor- version of an underlying library, say extjs,
> someone did or did not break my code...
>
> I will only know that in production, when someone triggers a branch
> that wasn't covered by regression testing...
>
> How is this usually handled in -serious- shops using no static type
> checking? Lots of unit testing? Test coverage indicators? Doesn't that
> take more time?
>
> I'm sorry, maybe this has an obvious solution that I'm oblivious to...
>
>
>
> On 10/1/10, Steven Obua wrote:
>> I share this view that static typing has its merits, but is really
>> strongly overrated.
>> That's why I am creating Babel-17 (www.babel-17.com). There will be
>> an interpreter for it available soon, together with a Netbeans module
>> for syntax highlighting and displaying of errors.
>>
>> Right now it is purely functional, and there are no static type
>> annotations at all. But I expect these two properties to be weakened
>> as Babel-17 evolves.
>>
>> The basic idea for Babel-17 is that I want a SERIOUS programming
>> language, but one which also appeals to Javascriptists and
>> Pythonistas. A PL which might later on incorporate (a little bit of)
>> static typing as a tool, but which is designed from the ground up
>> with the idea in mind that dynamic typing makes writing useful and
>> versatile libraries so much easier. One example is the built-in
>> support for data structures that would be really hard (probably
impossible) to realize with a static type system.
>>
>> I also did my PhD in a world where static typing rules, and I did a
>> lot of programming in languages like Standard ML. But note how typing
>> is simple and nice in SML, and becomes a mess when you want to do
>> something more complicated and real-world? For me this is a sign to
>> drop this focus on typing. There are many other ways in which
>> programming languages can be made better.
>>
>> - Steven
>>
>> On 01.10.2010, at 14:20, Razvan (Pub) Cojocaru wrote:
>>
>>> I'm not arguing the static typing, It's a religious view.
>>>
>>> Still, do not forget content assist and edit assists...yes, they
>>> could be (hardly) added for javascript but if you do it why not
>>> check the types while you're at it?
>>>
>>> Actually I think that scala strikes the right balance with static
>>> types and inferring them. Most of the time List[String] is
>>> sufficient...and serves as documebtation as well... I really feel,
>>> for the most part, that scala's types indeed don't get in the way.
>>>
>>> Yes, when you combine stuff like I mentioned with upper lower
>>> bounds, views and I don't remember what A:B stands for, you're
>>> loosing many people.
>>>
>>> Having said that, individual bounds are not complex, if you know
>>> that variance is not by default.
>>>
>>> -----
>>>
>>> As to a combination of closure/scala/groovy/java, I beg to differ.
>>> Scala can do it all and it only makes sense to invest in it. It's
>>> both compiled and interpreted, functional and compatible with Java.
>>>
>>> -----
>>>
>>> Sorry, I see that we got sidetracked a bit here...the bits about
>>> selecting scala and its future are interesting but I was using them
>>> as leverage only - I think all the arguments are obvious and most
>>> people made up their minds and it comes down to personal preference.
>>> :)
>>>
>>> In effect I only got direct comments about the list at hand in the
>>> beginning. Shall we start a separate thread to which only those that
>>> agree with the idea should answer? Or is this the end of debating
>>> the list and I'll just work on it myself?
>>>
>>> Thanks for the lively debate, it's great and interesting, albeit
>>> time-consuming.
>>>
>>> Cheers,
>>> Razvan
>>>
>>>
>>> On 9/30/10, Kenneth McDonald wrote:
>>>> I'm sorry, I somewhat omitted some of my case when I first wrote.
>>>>
>>>> I did not mean to imply that static type checking was _only_ good
>>>> for performance reasons. It can also considerably enhance code
>>>> correctness, as several others have pointed out.
>>>>
>>>> However, as with most things, there comes a point of diminishing
returns.
>>>> Trying to statically check __too__ much leads to a very complex and
>>>> difficult to understand type systems.
>>>>
>>>> IMHO, Scala is at the verge, if not slightly over the line, for
>>>> this limit.
>>>>
>>>> Again, I'll say; a language like Groovy which permits type
>>>> declarations (I realize Groovy decls are not checked at compile
>>>> time, but that's a detail), while allowing "duck-typing" when
>>>> necessary, would be appropriate. My belief is that most programmers
>>>> would declare 90%+ of their types, greatly reducing errors and
>>>> potentially increasing runtime speed. Most of the rest of the type
>>>> errors would be easily caught by unit tests. A trivial fraction
>>>> would escape into a release product--small enough, IMHO, to make up
>>>> for the increased productivity and ease of use of a "mostly static"
>>>> type system.
>>>>
>>>> Until we have such a language (if ever) such discussions will,
>>>> unfortunately, be rather academic. However, one thing I'm willing
>>>> to say without qualification, and as someone who spent much of a
>>>> Ph.D. doing functional languages, including O'Caml, Haskell, Concurrent
Clean, etc:
>>>> The
>>>> current type system for Scala is too scary for most programmers,
>>>> and to the extent that it is emphasized, will scare off support.
>>>>
>>>> Wish that weren't the case,
>>>> Ken McDonald
>>>>
>>>>
>>>> On Sep 30, 2010, at 5:47 PM, Russ Paielli wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 30, 2010 at 2:13 PM, Kenneth McDonald
>>>>> wrote:
>>>>>
>>>>> One final note. My experience with Python has convinced me that
>>>>> compile-time type-checking is _vastly_ overrated. 90%+ of my type
>>>>> errors in Python are revealed in simple testing, and the remainder
>>>>> aren't typically difficult to track down. I have great respect for
>>>>> the work Martin Odersky et al have done, but I question if it's really
necessary.
>>>>> I
>>>>> wish this topic didn't suck away so much really superior talent.
>>>>>
>>>>>
>>>>> Python is great for getting something out the door fast (as you
>>>>> said about Perl), but as others have said, it is not very good for
>>>>> maintainability (for larger projects at least).
>>>>>
>>>>> I am converting some of my own Python code to Scala. Part of the
>>>>> process is declaring method argument types, of course. I had
>>>>> always assumed that would be simple, but sometimes it is not. In
>>>>> some cases, figuring out the argument types in my own code is a
>>>>> non-trivial problem. But I now realize that just having those
>>>>> types explicitly declared reduces confusion and improves
>>>>> readability considerably. In fact, if the return type of a method
>>>>> is not trivially clear, explicitly declaring it also improves
>>>>> readability.
>>>>>
>>>>> Russ P.
>>>>>
>>>>> --
>>>>> http://RussP.us
>>>>
>>>
>>> --
>>> Sent from my mobile device
>>
>>
>
> --
> Sent from my mobile device
Fri, 2010-10-01, 20:17
#67
Re: Scala Joe - a profile for regular Joe
On Fri, Oct 1, 2010 at 1:51 AM, Russel Winder <russel@russel.org.uk> wrote:
On Thu, 2010-09-30 at 15:47 -0700, Russ Paielli wrote:
[ . . . ]
Not a direct response to Russ' comments, more a general response to the
thread overall . . .
> Python is great for getting something out the door fast (as you said
> about Perl), but as others have said, it is not very good for
> maintainability (for larger projects at least).
I suspect it is becoming a "known truth" that dynamic languages are
great for swift creation of small highly functional applications, but
for larger code bases static typing comes into its own even if the total
code is more verbose. Whether or not this is actually true seemingly
doesn't matter compared to the "truth" of this fact so often espoused.
I was just giving my general impression, but I certainly don't claim to be an expert. Having said that, I think it is clear that dynamic languages have their limits compared to statically typed languages. The legitimate debate is not whether that is true, but what those limits are. Anyone who proposed to use Python for flight-critical software or for an ICBM control system would have to be nuts.
Advanced static analysis is an active research area for safety-critical software. Such analysis is much more difficult if not impossible on dynamic languages. That is an important issue for me, not because I do static analysis, but because I'd like to eventually subject my code to such analysis.
There is though a factor that is missing in this debate I think and that
is the JVM.
Although Jython brings Python to the JVM, Python doesn't really fit that
well on the JVM compared to the Java/Scala/Groovy/Clojure collective.
Comparing Python to Scala is therefore comparing apples and sugar cubes.
> I am converting some of my own Python code to Scala. Part of the
> process is declaring method argument types, of course. I had always
> assumed that would be simple, but sometimes it is not. In some cases,
> figuring out the argument types in my own code is a non-trivial
> problem. But I now realize that just having those types explicitly
> declared reduces confusion and improves readability considerably. In
> fact, if the return type of a method is not trivially clear,
> explicitly declaring it also improves readability.
Another part of this is that you are shifting from non-JVM to JVM, this
is not just a Python -> not-Python debate.
For me the first question is not which language but whether the JVM
should be used. This is a simple yes/no question. If the answer is yes
then some combination of Scala, Groovy, Clojure and Java is the
implementation language team of choice. If the answer to the question
of using the JVM is no then Python/C++ or possibly D or Go become the
tools of choice.
I don't understand why the JVM is such an important issue. So long as the software does what it should, why should I care whether it runs on the JVM or not? That's not just a rhetorical question. I'd like to know if I am missing something important.
Russ P.
I suggest that Python (or C, C++, Fortran, Haskell, OCaml, Ruby, etc.,
etc.) bashing is just showing the insecurity of the non-Python
communities. The converse is equally true: non-JVM based communities
bashing JVM-based languages are displaying their own insecurities. None
of this indicates anything useful about whether a particular programming
language is appropriate for a given project in a given organization and
a given context.
Choice of programming language is not a context-free choice, so nothing
general can be said about which programming language is better than
another -- except where one of the languages is clearly not fit for its
purpose.
Russ has chosen to make a shift from Python to Scala. No problem if
that works for him. It does not though mean that Python is a bad or
poor language.
In any discussion it is always important to assess the faults as well as
good aspects of any language. No problem. It is good though to avoid
tribalism and "bashing".
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: 3Arussel [dot] winder [at] ekiga [dot] net" rel="nofollow">sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
--
http://RussP.us
Fri, 2010-10-01, 20:27
#68
Re: Re: Scala Joe - a profile for regular Joe
On Oct 1, 2010, at 1:03 PM, Randall R Schulz wrote:
> On Friday October 1 2010, Kenneth McDonald wrote:
>> ... I really like Scala, but do I wish its
>> type system was simpler? You bet.
>
> Why would you want type system simpler?
> So you can do fewer things with it?
So it wouldn't be so hard to learn. So I could use it more intuitively. And yes, I did spend a fair bit of time in a Ph.D. concerned with functional programming. There is simply such a thing as being overly academic.
Ken
>
>
>> ...
>>
>> Ken
>
>
> Randall Schulz
Fri, 2010-10-01, 20:27
#69
Re: Scala Joe - a profile for regular Joe
The usual reasons given for targeting the JVM are:
It's been massively optimised over many yearsIt's widely available on a lot of platformsThere's a large ecosystem of libraries already available You're extending a pre-existing codebase
On 1 October 2010 20:13, Russ Paielli <russ.paielli@gmail.com> wrote:
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
It's been massively optimised over many yearsIt's widely available on a lot of platformsThere's a large ecosystem of libraries already available You're extending a pre-existing codebase
On 1 October 2010 20:13, Russ Paielli <russ.paielli@gmail.com> wrote:
On Fri, Oct 1, 2010 at 1:51 AM, Russel Winder <russel@russel.org.uk> wrote:
On Thu, 2010-09-30 at 15:47 -0700, Russ Paielli wrote:
[ . . . ]
Not a direct response to Russ' comments, more a general response to the
thread overall . . .
> Python is great for getting something out the door fast (as you said
> about Perl), but as others have said, it is not very good for
> maintainability (for larger projects at least).
I suspect it is becoming a "known truth" that dynamic languages are
great for swift creation of small highly functional applications, but
for larger code bases static typing comes into its own even if the total
code is more verbose. Whether or not this is actually true seemingly
doesn't matter compared to the "truth" of this fact so often espoused.
I was just giving my general impression, but I certainly don't claim to be an expert. Having said that, I think it is clear that dynamic languages have their limits compared to statically typed languages. The legitimate debate is not whether that is true, but what those limits are. Anyone who proposed to use Python for flight-critical software or for an ICBM control system would have to be nuts.
Advanced static analysis is an active research area for safety-critical software. Such analysis is much more difficult if not impossible on dynamic languages. That is an important issue for me, not because I do static analysis, but because I'd like to eventually subject my code to such analysis.
There is though a factor that is missing in this debate I think and that
is the JVM.
Although Jython brings Python to the JVM, Python doesn't really fit that
well on the JVM compared to the Java/Scala/Groovy/Clojure collective.
Comparing Python to Scala is therefore comparing apples and sugar cubes.
> I am converting some of my own Python code to Scala. Part of the
> process is declaring method argument types, of course. I had always
> assumed that would be simple, but sometimes it is not. In some cases,
> figuring out the argument types in my own code is a non-trivial
> problem. But I now realize that just having those types explicitly
> declared reduces confusion and improves readability considerably. In
> fact, if the return type of a method is not trivially clear,
> explicitly declaring it also improves readability.
Another part of this is that you are shifting from non-JVM to JVM, this
is not just a Python -> not-Python debate.
For me the first question is not which language but whether the JVM
should be used. This is a simple yes/no question. If the answer is yes
then some combination of Scala, Groovy, Clojure and Java is the
implementation language team of choice. If the answer to the question
of using the JVM is no then Python/C++ or possibly D or Go become the
tools of choice.
I don't understand why the JVM is such an important issue. So long as the software does what it should, why should I care whether it runs on the JVM or not? That's not just a rhetorical question. I'd like to know if I am missing something important.
Russ P.
I suggest that Python (or C, C++, Fortran, Haskell, OCaml, Ruby, etc.,
etc.) bashing is just showing the insecurity of the non-Python
communities. The converse is equally true: non-JVM based communities
bashing JVM-based languages are displaying their own insecurities. None
of this indicates anything useful about whether a particular programming
language is appropriate for a given project in a given organization and
a given context.
Choice of programming language is not a context-free choice, so nothing
general can be said about which programming language is better than
another -- except where one of the languages is clearly not fit for its
purpose.
Russ has chosen to make a shift from Python to Scala. No problem if
that works for him. It does not though mean that Python is a bad or
poor language.
In any discussion it is always important to assess the faults as well as
good aspects of any language. No problem. It is good though to avoid
tribalism and "bashing".
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: 3Arussel [dot] winder [at] ekiga [dot] net" target="_blank" rel="nofollow">sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
--
http://RussP.us
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Fri, 2010-10-01, 20:37
#70
Re: Re: Scala Joe - a profile for regular Joe
No, this is wrong too. Types can be very valuable. One of the big problems is that we come from a heritage where types were there to make things easier for the compiler, rather than easier for the programmer. I like the thought of IntelliSense, popup documentation, and general type checking. I just don't want to see it taken too far.
Ken
On Oct 1, 2010, at 1:31 PM, Kevin Wright wrote:
Ken
On Oct 1, 2010, at 1:31 PM, Kevin Wright wrote:
Types are evil...
For example, if I'm travelling at a speed of 19, and my destination is 47 away, how long would it take me to get there?I can just see how giving types to all those numbers would complicate things!
On 1 October 2010 19:13, Steven Obua <steven.obua@googlemail.com> wrote:
> On Friday October 1 2010, Kenneth McDonald wrote:
>> ... I really like Scala, but do I wish its
>> type system was simpler? You bet.
>
> Why would you want type system simpler?
> So you can do fewer things with it?
I agree with Kenneth here. First, you cannot do anything with a type system. A type system just restricts you. A more advanced type system restricts you less, and the most advanced one simply vanishes into thin air.
:-)
- Steven
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Fri, 2010-10-01, 20:57
#71
Re: Re: Scala Joe - a profile for regular Joe
On Friday October 1 2010, Kenneth McDonald wrote:
> On Oct 1, 2010, at 1:03 PM, Randall R Schulz wrote:
> > On Friday October 1 2010, Kenneth McDonald wrote:
> >> ... I really like Scala, but do I wish its
> >> type system was simpler? You bet.
> >
> > Why would you want type system simpler?
> > So you can do fewer things with it?
>
> So it wouldn't be so hard to learn. So I could use it more
> intuitively. And yes, I did spend a fair bit of time in a Ph.D.
> concerned with functional programming. There is simply such a thing
> as being overly academic.
Sorry, but "overly academic" is not even meaningful, let alone a valid
criticism of (any part of) a programming language. It strikes me as
nothing more than another manifestation of anti-intellectualism.
> Ken
Randall Schulz
Fri, 2010-10-01, 21:27
#72
Re: Re: Scala Joe - a profile for regular Joe
Sorry, but this is just wrong. To semi-quote Paul Krugman from economics, there are those books who like their phis and chis and sigmas, and there are those who actually like to talk about things. Of course there is such a thing as being overly academic, I should know, I was part of the world for a significant number of years. To phrase it in a very simple (and hence attackable) manner, being overly academic means an insistence on correctness, as opposed to doing what can be done right now.
I have an example to back this up. One of my good friends was a pioneer of L-systems, the grammars that are used to "grow" plants as seen in Toy Story. (She was the major architect of plants in Toy Story). Quite a bit later, someone else came out with a paper on how L-systems could be easily done in Functional Programming. But the point is, they weren't. They were originally done in messy, ugly, C/C++. The "academic" way of doing thing severely trailed the practical way of doing them.
So yes, "overly academic" is meaningful. Roughly speaking, it means that academics come up with an "elegant" solution long after the problem has been solved.
Ken
On Oct 1, 2010, at 2:51 PM, Randall R Schulz wrote:
> On Friday October 1 2010, Kenneth McDonald wrote:
>> On Oct 1, 2010, at 1:03 PM, Randall R Schulz wrote:
>>> On Friday October 1 2010, Kenneth McDonald wrote:
>>>> ... I really like Scala, but do I wish its
>>>> type system was simpler? You bet.
>>>
>>> Why would you want type system simpler?
>>> So you can do fewer things with it?
>>
>> So it wouldn't be so hard to learn. So I could use it more
>> intuitively. And yes, I did spend a fair bit of time in a Ph.D.
>> concerned with functional programming. There is simply such a thing
>> as being overly academic.
>
> Sorry, but "overly academic" is not even meaningful, let alone a valid
> criticism of (any part of) a programming language. It strikes me as
> nothing more than another manifestation of anti-intellectualism.
>
>
>> Ken
>
>
> Randall Schulz
Fri, 2010-10-01, 21:47
#73
Re: Re: Scala Joe - a profile for regular Joe
On Friday October 1 2010, Kenneth McDonald wrote:
> ...
>
> So yes, "overly academic" is meaningful. Roughly speaking, it means
> that academics come up with an "elegant" solution long after the
> problem has been solved.
I'm just not buying it. What parts of Scala are "overly academic?"
And why are you here if it's so?
> Ken
Randall Schulz
Fri, 2010-10-01, 21:57
#74
Re: Re: Scala Joe - a profile for regular Joe
The type system is overly academic. (And I've seen lots of type systems). And I'm here because I think _in spite of that_, it's still the best solution going.
Ken
On Oct 1, 2010, at 3:39 PM, Randall R Schulz wrote:
> On Friday October 1 2010, Kenneth McDonald wrote:
>> ...
>>
>> So yes, "overly academic" is meaningful. Roughly speaking, it means
>> that academics come up with an "elegant" solution long after the
>> problem has been solved.
>
> I'm just not buying it. What parts of Scala are "overly academic?"
> And why are you here if it's so?
>
>
>> Ken
>
>
> Randall Schulz
Fri, 2010-10-01, 21:57
#75
Re: Re: Scala Joe - a profile for regular Joe
Hi Kenneth,
you got me interested: what you're saying is that the "type system
problem" has been solved long ago by practical means, and that the Scala
solution is neither good nor elegant. Please elaborate, since those two
statements are in violent disagreement with my personal experience. To
give you some reference frame (keeping in mind "scala-debate"): dynamic
typing or non-typing (counting Perl here, which I _love_ for the small
quick and dirty) does not cut it for me for serious development, C++ is
way over the top and Java is just some notches too limited.
Regards,
Roland
Am 01.10.2010 22:42, schrieb Kenneth McDonald:
> The type system is overly academic. (And I've seen lots of type systems). And I'm here because I think _in spite of that_, it's still the best solution going.
>
> Ken
>
>
> On Oct 1, 2010, at 3:39 PM, Randall R Schulz wrote:
>
>> On Friday October 1 2010, Kenneth McDonald wrote:
>>> ...
>>>
>>> So yes, "overly academic" is meaningful. Roughly speaking, it means
>>> that academics come up with an "elegant" solution long after the
>>> problem has been solved.
>> I'm just not buying it. What parts of Scala are "overly academic?"
>> And why are you here if it's so?
>>
>>
>>> Ken
>>
>> Randall Schulz
Fri, 2010-10-01, 22:17
#76
Re: Re: Scala Joe - a profile for regular Joe
On Fri, Oct 1, 2010 at 4:42 PM, Kenneth McDonald <kenneth.m.mcdonald@sbcglobal.net> wrote:
Huh, my problem with the type system is that it _isn't academic enough_.
I refuse to believe that there are not elegant theoretically sound mappings from a robust theory of types to those capabilities that people most frequently want (e.g. such as are found in the collections library), but instead we have a "pragmatic" application of mostly-well-established type theory to the problem only to the point where a solution exists, not to the point of elegance.
(The reason I think elegance is attainable is that there already exist constructs such as "MyType" that would help a good deal with a subset of the problems; that I can describe what needs to happen fairly succinctly and clearly with many of the rest even if it takes a cartload of mixins and higher-order types to express that intent to the type system; and that in a number of cases, Scala has already moved from an inelegant to a more elegant form of expressing certain things, such as A : Manifest.)
If the type system were constructed in such a way that when you wrote programs you would generate proofs of type-theorems about your problem instead of solving your problem, then I would consider it too academic.
--Rex
The type system is overly academic. (And I've seen lots of type systems). And I'm here because I think _in spite of that_, it's still the best solution going.
Huh, my problem with the type system is that it _isn't academic enough_.
I refuse to believe that there are not elegant theoretically sound mappings from a robust theory of types to those capabilities that people most frequently want (e.g. such as are found in the collections library), but instead we have a "pragmatic" application of mostly-well-established type theory to the problem only to the point where a solution exists, not to the point of elegance.
(The reason I think elegance is attainable is that there already exist constructs such as "MyType" that would help a good deal with a subset of the problems; that I can describe what needs to happen fairly succinctly and clearly with many of the rest even if it takes a cartload of mixins and higher-order types to express that intent to the type system; and that in a number of cases, Scala has already moved from an inelegant to a more elegant form of expressing certain things, such as A : Manifest.)
If the type system were constructed in such a way that when you wrote programs you would generate proofs of type-theorems about your problem instead of solving your problem, then I would consider it too academic.
--Rex
Fri, 2010-10-01, 22:27
#77
Re: Scala Joe - a profile for regular Joe
Kenneth McDonald skrev 2010-10-01 22:42:
> The type system is overly academic. (And I've seen lots of type systems). And I'm here because I think _in spite of that_, it's still the best solution going.
I feel the exact opposite way. Every feature in the Scala type system
has a very practical use case, for example Java compatibility or "type
class like" extensibility.
/Jesper Nordenberg
Fri, 2010-10-01, 22:47
#78
Re: Re: Scala Joe - a profile for regular Joe
Well, one can discuss endlessly about these things.
IMHO, Scala is the best programming language in existence. I learnt a lot from it, and I think Scala has taken types pretty far. On the other hand I have the feeling that scaling back on types will give an even better solution than Scala. This feeling is nurtured by about 18 years of programming experience (which is more than half of my life :-)) in about all languages imaginable. The only way to prove this is to build this better solution. Only then one can know if the tradeoffs of Scala cannot be replaced by a better (simpler and smaller) set of tradeoffs.
@kenneth: I do agree with most of your recent posts except with the post what "overly academic" is. I think too, that such a thing as "overly academic" exists. But it is not explaining something very elegantly 10 years after the fact. This I find really useful, as I might stumble upon the topic only 10 years after it has been solved first, and then I like an elegant solution that I can understand easily. No, for me "overly academic" means to solve with utmost rigor and precision the wrong problems.
- Steven
On 01.10.2010, at 23:16, Jesper Nordenberg wrote:
> Kenneth McDonald skrev 2010-10-01 22:42:
>> The type system is overly academic. (And I've seen lots of type systems). And I'm here because I think _in spite of that_, it's still the best solution going.
>
> I feel the exact opposite way. Every feature in the Scala type system has a very practical use case, for example Java compatibility or "type class like" extensibility.
>
> /Jesper Nordenberg
>
Fri, 2010-10-01, 22:57
#79
Re: Re: Scala Joe - a profile for regular Joe
On 1 October 2010 21:19, Kenneth McDonald <kenneth.m.mcdonald@sbcglobal.net> wrote:
So yes, "overly academic" is meaningful. Roughly speaking, it means that academics come up with an "elegant" solution long after the problem has been solved.
Like the untyped lambda calculus, for example?
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
If you were to agree with this perspective, then I don't see why you would pick Scala as a language, since the idea that a sound and rigorous static type system is beneficial and essential for a stable, scalable system is a fundamental underlying tenet in Scala's design.
Anecdotally, most Java programmers that I know (of various experience levels) do not consider learning Java's modest type-variance functionality at all important, and tend to sidestep variance problems with raw types and unsafe casts. So it would be reasonable to suggest that Gosling's point of view is widely shared among Java programmers, who are the presumably the biggest pool of coders coming new to Scala.
Since one of the biggest wins of Scala as a language is combining the strength of its type system with a simple and concise syntax, effectively demonstrating that a good type-system doesn't have to be ponderous and ineffective is the single biggest point of argument that needs to be won.
Ken
On 1 October 2010 01:22, Erik Engbrecht <erik.engbrecht@gmail.com> wrote: