- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: Scala Joe - a profile for regular Joe
Hello everyone,
I see that some discussions recently on scala-user are about aspects that
are the subject of debate and personal preference.
I should remind you that the proper list for that is scala-debate; please
avoid polluting scala-user with this kind of discussions.
Thank you all!
Toni
Re: Scala Joe - a profile for regular Joe
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:
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
>
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
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
>>
>
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
>
>
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
>>
>>
>
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 [dot] m [dot] mcdonald [at] sbcglobal [dot] 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
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
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
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
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
Re: Re: Scala Joe - a profile for regular Joe
On 1 October 2010 21:19, Kenneth McDonald <kenneth [dot] m [dot] mcdonald [at] sbcglobal [dot] net> wrote:
Like the untyped lambda calculus, for example?
--
Kevin Wright
mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda
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
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
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
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
>
Re: Re: Scala Joe - a profile for regular Joe
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
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
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
Re: Re: Scala Joe - a profile for regular Joe
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 [dot] obua [at] googlemail [dot] com> wrote:
--
Kevin Wright
mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda
Re: Re: Scala Joe - a profile for regular Joe
Ken
On Oct 1, 2010, at 1:31 PM, Kevin Wright wrote:
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
>>
>>
>
Re: Re: Scala Joe - a profile for regular Joe
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:
--
Kevin Wright
mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda
Re: Re: Scala Joe - a profile for regular Joe
Viktor KlangCode Connoisseurwww.akkasource.com
On Oct 1, 2010, at 14:57, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:
Re: Scala Joe - a profile for regular Joe
On Thu, Sep 30, 2010 at 8:03 PM, Kenneth McDonald
wrote:
>
> 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.
If I understand what you're writing there, I think Perl6 fits the
requirement. As you may know, it carries the Perl name but is not
backwards compatible with other versions of Perl. One of the new
features is optional type declarations and I believe it's supposed to
do type checking if you explicitly declare a type. But right now
Perl6 is only a language specification with a few separate
implementations in various stages of completion.
I'm not that bright, and I've seen plenty of code on these mailing
lists that baffles me. On the other hand, I have the books
"Programming Scala" by Venkat Subramaniam and "Programming in Scala"
by Martin Odersky, Lex Spoon, and Bill Venners and they give me a lot
of hope for the future wide use of the language because they're
phenomenally well done. I was especially nervous about the book
co-written by Odersky, I worried that people brilliant enough to
design a language would have a hard time explaining the concepts to
average developers. But it's the best book on software that I own,
and everything is explained clearly with great examples. None of it
is that difficult to understand.
Between the books and the helpful communities on the forums and
mailing lists I'm hopeful for Scala.
-Mike
Re: Scala Joe - a profile for regular Joe
I remember working on a C++ library where the designer had decided to simplify code by introducing a lot of obvious operators, as opposed to methods. They were obvious--to him (or perhaps her, in all fairness). For people working on the library, it was a nightmare. It was very difficult to decide what was part of C++, the STL, or the custom library.
Scala (for all that I like it) has this problem in spades. Between a very complex type system, implicits, and various other features I can't even remember, it is very easy to write highly obfuscated code. The conciseness of higher-order programming can contribute to this problem or not. Ever seen a really concise line of APL? To those in the know it may be crystal clear, but to the majority of programmers, it's line noise. I'd also refer people to Backus' 'fp' language, which was interesting from a theoretical point of view, but could produce some truly impenetrable code.
IMHO, there are really two camps. The first is Perl's, "There's more than one way to do it", which leads to disastrous maintainability results. (Yes, I've maintained big Perl codebases. I'm not speaking out of my hat.) The second is Python's (as of a couple of generations ago) "There's only one right way to do it." Indentation is mandatory whether you like it or not, there are a limited number of idioms and new idioms are added only after cautious consideration, and one programmer's solution looks surprisingly like another programmer's solution. (And I've also maintained large Python codebases, so yes, I know what I'm talking about.) From the point of view of getting something out the door, the first is probably superior. From the point of view of having something that _lasts_, the second is the winner, not even a contest.
What I would've liked in a language. (And I'm not dissing Scala, it's still my favorite contender.) Something like Groovy, where declared types are optional but (unlike Groovy) if you declare them, they really speed code up. I think this could be a huge win. It gets rid of extremely complex type systems (admittedly requiring some type casts--but that's not a huge thing in modern IDEs), it still provides a lot of type safety, it gains speed, and it's accessible to everyone.
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.
Cheers,
Ken
Re: Scala Joe - a profile for regular Joe
On Thu, Sep 30, 2010 at 2:13 PM, Kenneth McDonald <kenneth [dot] m [dot] mcdonald [at] sbcglobal [dot] net> wrote:
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
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".
Re: Scala Joe - a profile for regular Joe
On Fri, Oct 1, 2010 at 1:51 AM, Russel Winder <russel [at] russel [dot] org [dot] uk> wrote:
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.
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.
--
http://RussP.us
Re: Scala Joe - a profile for regular Joe
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 [dot] paielli [at] gmail [dot] com> wrote:
--
Kevin Wright
mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda
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.
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.
Re: Scala Joe - a profile for regular Joe
On Thu, Sep 30, 2010 at 5:13 PM, Kenneth McDonald <kenneth [dot] m [dot] mcdonald [at] sbcglobal [dot] net> wrote:
My experience with Python has convinced me that compile-time type-checking is vastly _under_rated for me. It was not that the type errors were difficult to reveal with simple testing; it was that every absurdly tiny little thing had to be tested or it might randomly break, and this meant that I had to spend far more time writing test code than writing actual code to use if I wanted to avoid random type errors at runtime. With Scala, I have a much higher probability of getting things right if it compiles, and thus to have acceptable error rates I can write tests at a higher level and less often.
Given the combination of our two experiences, perhaps the conclusion is that compile-time type-checking is vastly more important to some people than to others. I am glad that the Oderskys of the world exist to make things easier for those of us on the "more important" end of the spectrum.
--Rex
Re: Scala Joe - a profile for regular Joe
Have you tried refactoring a large code base. Really refactoring it, not just moving a few things. I will claim that to be almost impossible without rigorous type checking.
Nils
Re: Scala Joe - a profile for regular Joe
Kenneth McDonald wrote 2010-09-30 23:13:
> What I would've liked in a language. (And I'm not dissing Scala, it's still my favorite contender.) Something like Groovy, where declared types are optional but (unlike Groovy) if you declare them, they really speed code up. I think this could be a huge win. It gets rid of extremely complex type systems (admittedly requiring some type casts--but that's not a huge thing in modern IDEs), it still provides a lot of type safety, it gains speed, and it's accessible to everyone.
>
> 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.
If you think the main benefit of static type checking is improved
runtime performance, you should seriously consider switching to another
language. Personally, I would be scared shitless if I had to maintain a
large Python application and someone actually relied on that application
producing correct results. I'm not saying Scala is perfect, far from it,
but currently it's the best we have in the Java ecosystem. If anything I
would like to see more static checking being done by the compiler (like
side effect tracking and null checking).
/Jesper Nordenberg
Re: Scala Joe - a profile for regular Joe
Am 30.09.2010 23:13, schrieb Kenneth McDonald:
> 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.
my experience is that compile time type checking greatly helps if it's
not your code you are trying to modify/debug/understand. in your own,
you usually know what you are doing.
Re: Scala Joe - a profile for regular Joe
- Write whatever you want, however you want- Do pair programming and perform code reviews- If your code is unacceptable to the remainder of the team, even after explaining how it works - then rewrite it in a different style.
The real beauty of this approach is that it scales up as your team comes to better understand the language with repeated exposure.
On 24 September 2010 18:12, Antonio Cunei <antonio [dot] cunei [at] epfl [dot] ch> wrote:
--
Kevin Wright
mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda
Re: Scala Joe - a profile for regular Joe
Yes, I know... As it hapens though, many teams here are poor at doing
their reviews and others are left to pickup the pieces at 1 am in a
production environment...
How do you deal with temps? Mandate reviews before they leave, and
leave it to that?
On 9/24/10, Kevin Wright wrote:
> I have a variation on these rules that I've found to be very effective:
>
> - Write whatever you want, however you want
> - Do pair programming and perform code reviews
> - If your code is unacceptable to the remainder of the team, even after
> explaining how it works - then rewrite it in a different style.
>
> The real beauty of this approach is that it scales up as your team comes to
> better understand the language with repeated exposure.
>
>
>
> On 24 September 2010 18:12, Antonio Cunei wrote:
>
>> Hello everyone,
>>
>> I see that some discussions recently on scala-user are about aspects that
>> are the subject of debate and personal preference.
>>
>> I should remind you that the proper list for that is scala-debate; please
>> avoid polluting scala-user with this kind of discussions.
>>
>> Thank you all!
>> Toni
>>
>>
>
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
> pulse / skype: kev.lee.wright
> twitter: @thecoda
>
Re: Re: Scala Joe - a profile for regular Joe
On Friday September 24 2010, Razvan (Pub) Cojocaru wrote:
> Yes, I know... As it hapens though, many teams here are poor at doing
> their reviews and others are left to pickup the pieces at 1 am in a
> production environment...
>
> How do you deal with temps? Mandate reviews before they leave, and
> leave it to that?
You're addressing the real problem (developers who don't do their job
well) with a bunch of rules that will in no way make them better
developers.
Who on Earth uses temporary people as software developers? It sounds
like your organization has problems that cannot possibly be solved by
circumscribing parts of the Scala language as off-limits.
Randall Schulz
Re: Scala Joe - a profile for regular Joe
How many of you guys are full-time employees with more than 5 years at the
same company? Most of the great developers I know are contractors, i.e.
"temps".
Temporary contractors are great for developing components, as self-contained
as possible...but even those need maintaining at some point.
I toned down the thing and now, reading it again, it's more of a style
guide...the degree of adherence should obviously vary from dev shop to dev
shop...
-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys: http://scripster.razie.com Scripster and
http://github.com/razie/gremlins Gremlins
Follow me: http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter , http://github.com/razie GitHub .
Re: Re: Scala Joe - a profile for regular Joe
I work professionally as a Java Software developer and I'm lurking the Scala lists for a couple of years. I own the Programing in Scala book and I've made some personal pet projects to get a grasp on this language.
I am a Java/Scala regular Joe.
I think that lots of features of the language are wonderful and I truly believe that when used correctly, it can give amazing results. But I agree with the OP mindset. IMHO some feature are best not to be used/abused, at least outside the EPFL.
Someone smarter that me said the code is written once but read many times. In that sense some advanced Scala features are very intimidating to read (in the perlish sense) unless you have very advanced FP/Scala skills. It was mentioned in that list earlier that some kind of developer profile could be introduced to ease the transition from Javaland to the reams od FP/Scala, It would be help me personally, and it would give me a tool to try to introduce Scala where I work.
I think the biggest challenge Scala faces preventing it can go mainstream is not the performance of the language features but this syntax that make it look more complicated that it really is and the learning curve it implies. The suggestion of the OP with "do not abuse" list or the developer profiles mention earlier are attempt to deal with this challenge.
Reading the response, I feel that the more senior Scalaist on this list are having a hard time accepting/understanding this fact. It is very understandable. It happen to me when I try to teach something I master perfectly (I cannot understand they do not get it).
My 2 cents,
-Martin
PS. Here is an example of intimidating code (IMHO), taken in one of today's posts in the scala list:
// Generic join -- no way around cartersian product
def on[Z](f: (X, Y) => Z) = new JoinedOnExpr(first, second, f)
class JoinedOnExpr[X, Y, Z](first: CC[X], second: Traversable[Y], f: (X, Y) => Z) {
def equalTo(g: (X, Y) => Z)(implicit cbf: CanBuildFrom[CC[X], (X, Y), CC[(X, Y)]]): CC[(X, Y)] = for {
x <- first
y <- second
if f(x, y) == g(x, y)
} yield x -> y
}
From: Razvan Cojocaru-2 <pub [at] razie [dot] com>
To: scala-debate [at] listes [dot] epfl [dot] ch
Sent: Fri, September 24, 2010 2:03:21 PM
Subject: [scala-debate] Re: [scala-user] Scala Joe - a profile for regular Joe
How many of you guys are full-time employees with more than 5 years at the
same company? Most of the great developers I know are contractors, i.e.
"temps".
Temporary contractors are great for developing components, as self-contained
as possible...but even those need maintaining at some point.
I toned down the thing and now, reading it again, it's more of a style
guide...the degree of adherence should obviously vary from dev shop to dev
shop...
-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys: http://scripster.razie.com Scripster and
http://github.com/razie/gremlins Gremlins
Follow me: http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter , http://github.com/razie GitHub .
--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Re-scala-user-Scala-Joe-a-profile-for-regular-Joe-tp2555818p2562410.html
Sent from the Scala - Debate mailing list archive at Nabble.com.
Re: Re: Scala Joe - a profile for regular Joe
On Fri, Sep 24, 2010 at 11:46 AM, Martin Renaud
wrote:
> I think the biggest challenge Scala faces preventing it can go mainstream is
> not the performance of the language features but this syntax that make it
> look more complicated that it really is and the learning curve it implies.
This topic came up a couple of times today at the Scala Lift Off in
San Francisco. Martin Odersky mentioned it in his closing summary for
the day and said part of it is because people who tend to solve very
hard problems with Scala like to share their solutions... and that's
usually extremely high-level (complex) code - much like the example
you quoted - and this can "scare off" new folks coming to Scala. He'd
raised a similar issue earlier in his talk about higher-kind types
used in the 2.8 collection class hierarchy and how they show up in the
API documentation - they can make the library look much harder to use
than it actually is.
It also came up in a session on introducing new technology to
organizations. I observed that Scala's comprehensive type system,
whilst very powerful (and desirable) is quite simply beyond a lot of
the web developers I deal with on a day to day basis. Those folks are
mostly self-taught, with no comp sci background at all, and they're
used to web scripting languages that have a very loose notion of type
at runtime (if any at all). My approach to introduce those folks to FP
will be to use Clojure since it's 'closer' to what they're used to -
and I'll be perfectly happy with the likely outcome a mix of Clojure
for core application logic, Scala for back end heavy lifting (mostly
in black box libraries) and some web templating language on the front
end.
Someone else in that session commented on the dense and often
incomprehensible error messages from the compiler when you get the
types wrong in your program (they quoted the example of people
learning Lift and seeing compiler errors that were so far removed from
the code they actually wrote that they had no idea how to resolve
issues).
I sympathize... back in the day, when templates were relatively new to
C++, compiler errors from template misuse could be equally
impenetrable.
I haven't read the OP's document yet but since this thread has opened
up such a big debate in a single day, I'll be heading there next to
see what the fuss is about :)
Re: Re: Scala Joe - a profile for regular Joe
Sean Corfield said:
> [... condensed]
> wrote:
> > I think the biggest challenge Scala faces preventing it can go mainstream
> > is not the performance of the language features but this syntax that
> > make it look more complicated that it really is and the learning curve
> > it implies.
>
> It also came up in a session on introducing new technology to
> organizations. I observed that Scala's comprehensive type system,
> whilst very powerful (and desirable) is quite simply beyond a lot of
> the web developers I deal with on a day to day basis. Those folks are
> mostly self-taught, with no comp sci background at all, and they're
> used to web scripting languages that have a very loose notion of type
> at runtime (if any at all). My approach to introduce those folks to FP
I can only agree.
From my experience there you have to deal with these kind of developers:
a) the good but uncaring (who's gonna maintain this is not my problem)
b) the good and caring (the ones you want)
c) the average or even not-so-average (the ones you have to accept for
various reasons)
d) the malicious (the worst kind... often they are very good but black
hearted)
Face it: A head of department has to make sure that he doesn't allow a
toolchain which allows a) or d) to make a mess which defuncts c) and drives b)
insane.
And I know that scala has already been ruled out by some some of our big
clients for being to powerfull (read: gives a) and d) too much power to bring
a project or even business down).
I think, it is the ultimate challenge to the scala enthusiasts to come up with
a solution for this or face general non-adoption.
Don't get me wrong - I like scala very much (and I am no decider myself - I'm
subjected to the tool decisions of others). But I can feel a strong breeze
against scala right now...
Worried greetings
Bernd
Re: Scala Joe - a profile for regular Joe
Sean, I understand that simple rule...basically says "play nice"...that's
what this is as well, except with clear examples: this is complex, this is
ugly, this is mean, this is not.
Anyways - not a lot of comments on specifics, so I'll leave it at this for
now.
It's not like this will be useful to me anytime soon... the CTO of our
little enterprise has expressly overruled my decision to allow scala
development in parallel with Java, in any "customer facing
components"...basically excluding a few hundred developers from "organized
first contact". Talk about spooky...and don't pick on my CTO, he's smarter
than most of us...
Non-existence of these profiles/rules/simplicity guides may in fact be a
much bigger disservice to scala adoption than their existence would be to
some experts (which are exempt anyways) or tinkerers (which can keep it to
after hours) ... and, delay adoption long enough in this day of accelerating
change and I'm sure competing platforms are smiling...with...like...larger
smiles or something :)
Anyways, food for thought.
-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys: http://scripster.razie.com Scripster and
http://github.com/razie/gremlins Gremlins
Follow me: http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter , http://github.com/razie GitHub .
Re: Re: Scala Joe - a profile for regular Joe
On Sat, Sep 25, 2010 at 1:45 PM, Razvan Cojocaru-2 wrote:
> It's not like this will be useful to me anytime soon... the CTO of our
> little enterprise has expressly overruled my decision to allow scala
> development in parallel with Java, in any "customer facing
> components"...basically excluding a few hundred developers from "organized
> first contact". Talk about spooky...and don't pick on my CTO, he's smarter
> than most of us...
I'm sure he has his reasons. Did he explain what those reasons are and
why he doesn't want Scala alongside Java?
Re: Re: Scala Joe - a profile for regular Joe
Personally, that discussion was the first time in more than a decade that I felt like a geek talking nonsense :) - no reflection on scala itself.
Afterwards I created this - please don't repeat the arguments - that'd be boring :) http://www.slideshare.net/razvanc/why-scalaexecutive-overview
Cheers,Razvan
On Sat, Sep 25, 2010 at 6:04 PM, Sean Corfield <seancorfield [at] gmail [dot] com> wrote:
Re: Re: Scala Joe - a profile for regular Joe
On Sat, Sep 25, 2010 at 10:45 PM, Razvan Cojocaru-2 <pub [at] razie [dot] com> wrote:
I'm sorry to hear that, hope he'll change his mind in the future.
Is there anything any of the senior members of the community can do to increase the level of trust that is given to the language and its eco-system?
--
Viktor Klang,
Code Connoisseur
Work: www.akkasource.com
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Re: Re: Scala Joe - a profile for regular Joe
On Saturday September 25 2010, Viktor Klang wrote:
> ...
>
> Is there anything any of the senior members of the community can do
> to increase the level of trust that is given to the language and its
> eco-system?
Will the senior members of the community please stand up?
RRS
Re: Re: Scala Joe - a profile for regular Joe
On Fri, Sep 24, 2010 at 11:46 AM, Martin Renaud <mr_martin_renaud [at] yahoo [dot] ca> wrote:
I agree. I would like to see Scala eventually get accepted as a suitable language for safety-critical systems. I mean systems where a bug can cause someone to die -- or a few hundred people to die instantly. The safety requirements for those kinds of systems are obviously more stringent than for, say, a video game. (That's not to disparage video games, which have their own stringent performance requirements.)
Obviously, good coding standards are needed for safety-critical systems, but maybe more is needed than that. A while back, I suggested that perhaps a safety-critical subset of Scala could be developed, similar to the Ravanscar profile for Ada, or even Spark Ada. Ideally, that subset would substantially reduce the potential for errors without substantially reducing the expressivity of Scala.
Think about flying in an airspace with automation developed by fallible human programmers. Are there some features of Scala that you would rather not see used in the automation? I'd be interested in what Scala experts have to say about it, if anything.
Russ P.
--
http://RussP.us
Re: Re: Scala Joe - a profile for regular Joe
On Friday September 24 2010, Russ Paielli wrote:
> ...
>
> Think about flying in an airspace with automation developed by
> fallible human programmers. Are there some features of Scala that you
> would rather not see used in the automation? I'd be interested in
> what Scala experts have to say about it, if anything.
Please explain the connection between the reliability of the software
and the "features" of the language used. Please also explain why you
think proscribing certain of these language features could increase
reliability or other desirable (or necessary) property of the resulting
software?
> Russ P.
Randall Schulz