- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?
Tue, 2011-11-15, 20:37
#3a3a3a
Re: Re: What is highest priority for Scala to succeed in corpor
2011/11/15 Razvan Cojocaru <pub@razie.com>
Maybe, but that's not what we are measuring. People switched en masse from C++ to Java because they felt that they were being more productive with Java, that they spent less time fighting against the compiler and the language and more time actually writing code.
Dumbing down productivity to writing less lines of code is a very short-sighted perspective which has been proven wrong countless times. It's much, much more complex to assess than that, and perception of productivity is a very important factor in this overall equation. Developers need to trust and feel comfortable with the technology you put in their hands.
You're revising history, here. Java "the language" was a huge factor in the massive migration away from C++ in the early years, and the JVM was seen as a liability at the time ("Java is slow", etc...) but developers still adopted it because the jump in productivity was so huge compared to C++.
It's only recently that the focus has slowly been moving away from Java to the JVM, but even today, Java "the language" continues to be the #1 language on the JVM by a crushing margin, even compared to the #2 JVM language (Groovy).
-- Cédric
NOPE. Quite the contrary. I think I can prove that the LOC and headcount has gone up for the same Feature Count, whatever your favorite way to measure functional points is.
Maybe, but that's not what we are measuring. People switched en masse from C++ to Java because they felt that they were being more productive with Java, that they spent less time fighting against the compiler and the language and more time actually writing code.
Dumbing down productivity to writing less lines of code is a very short-sighted perspective which has been proven wrong countless times. It's much, much more complex to assess than that, and perception of productivity is a very important factor in this overall equation. Developers need to trust and feel comfortable with the technology you put in their hands.
Again, do not confuse the two: the best thing about Java was, is and will always be the JVM, not the language itself
You're revising history, here. Java "the language" was a huge factor in the massive migration away from C++ in the early years, and the JVM was seen as a liability at the time ("Java is slow", etc...) but developers still adopted it because the jump in productivity was so huge compared to C++.
It's only recently that the focus has slowly been moving away from Java to the JVM, but even today, Java "the language" continues to be the #1 language on the JVM by a crushing margin, even compared to the #2 JVM language (Groovy).
-- Cédric
Tue, 2011-11-15, 20:57
#3c3c3c
Re: Re: What is highest priority for Scala to succeed in corpor
I agree entirely. Of course the originators did not use the word in the offensive context and I apologize if I implied otherwise. As it has been said, this context exists I independently of the origin of pimp my library/car etc.
Best of luck all. Back to hacking some akka for me :-)
Tue, 2011-11-15, 22:27
#3e3e3e
Re: Re: Re: What is highest priority for Scala to succeed in c
On 16/11/11 03:10, Jesper Nordenberg wrote:
>
> This is definitely true. People look at Scalaz code and say it's
> complex, but that's simply because the abstraction level is so much
> higher than anything they've seen in Java and C++. It takes time and
> effort to grasp all the concepts used at these higher abstraction levels.
Ding ding! Please listen to this man.
The problem is the "I" part in "I find it complex." The moment this is
recognised by any Complexity Complainant, give me a buzz and I'll help
you address the issue -- the "I" issue that is, I will help you
understand the subject matter. I can do this. So can you.
Tue, 2011-11-15, 22:47
#404040
Re: Re: Re: What is highest priority for Scala to succeed in c
Couldn't agree with Cedric more here. JVM was a massive roadblock in Java adoption early on as it was so slow and unreliable up until very late 90s. The language was a force de jour. It's changed now as pointed out...
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com
2011/11/15 Cédric Beust ♔ <cedric@beust.com>
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com
2011/11/15 Cédric Beust ♔ <cedric@beust.com>
2011/11/15 Razvan Cojocaru <pub@razie.com>NOPE. Quite the contrary. I think I can prove that the LOC and headcount has gone up for the same Feature Count, whatever your favorite way to measure functional points is.
Maybe, but that's not what we are measuring. People switched en masse from C++ to Java because they felt that they were being more productive with Java, that they spent less time fighting against the compiler and the language and more time actually writing code.
Dumbing down productivity to writing less lines of code is a very short-sighted perspective which has been proven wrong countless times. It's much, much more complex to assess than that, and perception of productivity is a very important factor in this overall equation. Developers need to trust and feel comfortable with the technology you put in their hands.
Again, do not confuse the two: the best thing about Java was, is and will always be the JVM, not the language itself
You're revising history, here. Java "the language" was a huge factor in the massive migration away from C++ in the early years, and the JVM was seen as a liability at the time ("Java is slow", etc...) but developers still adopted it because the jump in productivity was so huge compared to C++.
It's only recently that the focus has slowly been moving away from Java to the JVM, but even today, Java "the language" continues to be the #1 language on the JVM by a crushing margin, even compared to the #2 JVM language (Groovy).
-- Cédric
Tue, 2011-11-15, 22:57
#424242
RE: Re: What is highest priority for Scala to succeed in corpor
Also, you can read the history section at the link below: how many times are JVM features mentioned and how many times the “power of the language” ? http://en.wikipedia.org/wiki/Java_(programming_language)#History
If Sun was not the “sun” at that time, I don’t think Java would have gone anywhere…
It is interesting though - does anyone have numbers from before 2002?
From: cbeust@gmail.com [mailto:cbeust@gmail.com] On Behalf Of Cédric Beust ?
Sent: November-15-11 2:33 PM
To: Razvan Cojocaru
Cc: tmorris@tmorris.net; scala-debate@googlegroups.com
Subject: Re: [scala-user] Re: What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?
2011/11/15 Razvan Cojocaru <pub@razie.com>
NOPE. Quite the contrary. I think I can prove that the LOC and headcount has gone up for the same Feature Count, whatever your favorite way to measure functional points is.
Maybe, but that's not what we are measuring. People switched en masse from C++ to Java because they felt that they were being more productive with Java, that they spent less time fighting against the compiler and the language and more time actually writing code.
Dumbing down productivity to writing less lines of code is a very short-sighted perspective which has been proven wrong countless times. It's much, much more complex to assess than that, and perception of productivity is a very important factor in this overall equation. Developers need to trust and feel comfortable with the technology you put in their hands.
Again, do not confuse the two: the best thing about Java was, is and will always be the JVM, not the language itself
You're revising history, here. Java "the language" was a huge factor in the massive migration away from C++ in the early years, and the JVM was seen as a liability at the time ("Java is slow", etc...) but developers still adopted it because the jump in productivity was so huge compared to C++.
It's only recently that the focus has slowly been moving away from Java to the JVM, but even today, Java "the language" continues to be the #1 language on the JVM by a crushing margin, even compared to the #2 JVM language (Groovy).
--
Cédric
Tue, 2011-11-15, 23:07
#444444
Re: Re: What is highest priority for Scala to succeed in corpor
2011/11/15 Razvan Cojocaru <pub@razie.com>
Which facts exactly? TIOBE lists Java as #1, Groovy as #70 and Scala as... well, further down the list.
-- Cédric
Tue, 2011-11-15, 23:27
#464646
Re: Re: What is highest priority for Scala to succeed in corpor
Looks like some people have to claw at any arguable straw.
Wed, 2011-11-16, 01:47
#484848
Re: Re: Re: What is highest priority for Scala to succeed in c
Yes, excellent observation.
In 2011 I still get comments from some (usually non-developers) that "everyone knows Java is slow." You only get once chance to make a first impression, and some people cannot move beyond that first impression.
Cheers, Eric
On 2011-11-15 1:20 PM, Nikita Ivanov wrote:
In 2011 I still get comments from some (usually non-developers) that "everyone knows Java is slow." You only get once chance to make a first impression, and some people cannot move beyond that first impression.
Cheers, Eric
On 2011-11-15 1:20 PM, Nikita Ivanov wrote:
4Hw [at] mail [dot] gmail [dot] com" type="cite">Couldn't agree with Cedric more here. JVM was a massive roadblock in Java adoption early on as it was so slow and unreliable up until very late 90s. The language was a force de jour. It's changed now as pointed out...
-- Nikita Ivanov, CEO GridGain Systems www.gridgain.com
2011/11/15 Cédric Beust ♔ <cedric [at] beust [dot] com" rel="nofollow">cedric@beust.com>
2011/11/15 Razvan Cojocaru <pub [at] razie [dot] com" target="_blank" rel="nofollow">pub@razie.com>
NOPE. Quite the contrary. I think I can prove that the LOC and headcount has gone up for the same Feature Count, whatever your favorite way to measure functional points is.
Maybe, but that's not what we are measuring. People switched en masse from C++ to Java because they felt that they were being more productive with Java, that they spent less time fighting against the compiler and the language and more time actually writing code.
Dumbing down productivity to writing less lines of code is a very short-sighted perspective which has been proven wrong countless times. It's much, much more complex to assess than that, and perception of productivity is a very important factor in this overall equation. Developers need to trust and feel comfortable with the technology you put in their hands.
Again, do not confuse the two: the best thing about Java was, is and will always be the JVM, not the language itself
You're revising history, here. Java "the language" was a huge factor in the massive migration away from C++ in the early years, and the JVM was seen as a liability at the time ("Java is slow", etc...) but developers still adopted it because the jump in productivity was so huge compared to C++.
It's only recently that the focus has slowly been moving away from Java to the JVM, but even today, Java "the language" continues to be the #1 language on the JVM by a crushing margin, even compared to the #2 JVM language (Groovy).
-- Cédric
Wed, 2011-11-16, 01:47
#414141
Re: Re: Re: What is highest priority for Scala to succeed in c
The JVM is not slow, unless you try to do something useful with it.
The absence of TCO is enough to turn people off, but there is always a workaround to this. No, the workaround is *not* to go writing messy code that doesn't work *ever*. How about the cost of a stack frame? Have you ever tried to traverse a lazy cons list? How far did you get? Into the thousands but no further right?
Oh, you might say, but why would I ever want to traverse a lazy cons list when I have an InputStream!? Well, now we have a discussion about what "useful" is. Until we work out that there is a *contention* here between performance and usefulness, we will be stuck in these dark ages of pretending that the JVM is more than a pile of dogs' balls that we are all stuck with. Indeed, it might be said that the Scalaz thesis is: so just how far can we take usefulness without sacrificing performance?
Anyone who has done any kind of high-level programming on the JVM, and there are few of those, will know exactly what I mean when I say "gotchya!"
On 11/16/2011 10:38 AM, Eric Kolotyluk wrote:
The absence of TCO is enough to turn people off, but there is always a workaround to this. No, the workaround is *not* to go writing messy code that doesn't work *ever*. How about the cost of a stack frame? Have you ever tried to traverse a lazy cons list? How far did you get? Into the thousands but no further right?
Oh, you might say, but why would I ever want to traverse a lazy cons list when I have an InputStream!? Well, now we have a discussion about what "useful" is. Until we work out that there is a *contention* here between performance and usefulness, we will be stuck in these dark ages of pretending that the JVM is more than a pile of dogs' balls that we are all stuck with. Indeed, it might be said that the Scalaz thesis is: so just how far can we take usefulness without sacrificing performance?
Anyone who has done any kind of high-level programming on the JVM, and there are few of those, will know exactly what I mean when I say "gotchya!"
On 11/16/2011 10:38 AM, Eric Kolotyluk wrote:
4EC305EC [dot] 8090702 [at] gmail [dot] com" type="cite"> Yes, excellent observation.
In 2011 I still get comments from some (usually non-developers) that "everyone knows Java is slow." You only get once chance to make a first impression, and some people cannot move beyond that first impression.
Cheers, Eric
On 2011-11-15 1:20 PM, Nikita Ivanov wrote:4Hw [at] mail [dot] gmail [dot] com" type="cite">Couldn't agree with Cedric more here. JVM was a massive roadblock in Java adoption early on as it was so slow and unreliable up until very late 90s. The language was a force de jour. It's changed now as pointed out...
-- Nikita Ivanov, CEO GridGain Systems www.gridgain.com
2011/11/15 Cédric Beust ♔ <cedric [at] beust [dot] com" rel="nofollow">cedric@beust.com>
2011/11/15 Razvan Cojocaru <pub [at] razie [dot] com" target="_blank" rel="nofollow">pub@razie.com>
NOPE. Quite the contrary. I think I can prove that the LOC and headcount has gone up for the same Feature Count, whatever your favorite way to measure functional points is.
Maybe, but that's not what we are measuring. People switched en masse from C++ to Java because they felt that they were being more productive with Java, that they spent less time fighting against the compiler and the language and more time actually writing code.
Dumbing down productivity to writing less lines of code is a very short-sighted perspective which has been proven wrong countless times. It's much, much more complex to assess than that, and perception of productivity is a very important factor in this overall equation. Developers need to trust and feel comfortable with the technology you put in their hands.
Again, do not confuse the two: the best thing about Java was, is and will always be the JVM, not the language itself
You're revising history, here. Java "the language" was a huge factor in the massive migration away from C++ in the early years, and the JVM was seen as a liability at the time ("Java is slow", etc...) but developers still adopted it because the jump in productivity was so huge compared to C++.
It's only recently that the focus has slowly been moving away from Java to the JVM, but even today, Java "the language" continues to be the #1 language on the JVM by a crushing margin, even compared to the #2 JVM language (Groovy).
-- Cédric
-- Tony Morris http://tmorris.net/
Wed, 2011-11-16, 01:57
#434343
Re: Re: Re: What is highest priority for Scala to succeed in c
The counter-argument, of course, is how many "I"s does it take to reach some form of consensus?
Scalaz is a highly abstract solution for domains that have enough duplication within the sort of problem where scalaz excels. Many don't, and this is just fine for both the domain and for scalaz.
*Any* form of abstraction or indiscriminate use of a design pattern will seem overblown and excessively complex when used in a place where it isn't appropriate.
If you need scalaz, then that's cool. If you don't, then that's also cool. The only uncool things are pushing a framework on folks who don't need it, or criticising the same framework for people who do.
On 15 November 2011 22:12, Tony Morris <tonymorris@gmail.com> wrote:
--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra
Scalaz is a highly abstract solution for domains that have enough duplication within the sort of problem where scalaz excels. Many don't, and this is just fine for both the domain and for scalaz.
*Any* form of abstraction or indiscriminate use of a design pattern will seem overblown and excessively complex when used in a place where it isn't appropriate.
If you need scalaz, then that's cool. If you don't, then that's also cool. The only uncool things are pushing a framework on folks who don't need it, or criticising the same framework for people who do.
On 15 November 2011 22:12, Tony Morris <tonymorris@gmail.com> wrote:
On 16/11/11 03:10, Jesper Nordenberg wrote:
>
> This is definitely true. People look at Scalaz code and say it's
> complex, but that's simply because the abstraction level is so much
> higher than anything they've seen in Java and C++. It takes time and
> effort to grasp all the concepts used at these higher abstraction levels.
Ding ding! Please listen to this man.
The problem is the "I" part in "I find it complex." The moment this is
recognised by any Complexity Complainant, give me a buzz and I'll help
you address the issue -- the "I" issue that is, I will help you
understand the subject matter. I can do this. So can you.
--
Tony Morris
http://tmorris.net/
--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra
Wed, 2011-11-16, 02:07
#454545
Re: Re: Re: What is highest priority for Scala to succeed in c
On 11/16/2011 10:45 AM, Kevin Wright wrote:
There is a crucial, absolutely critical, distinction between "many don't" and "many believe that they don't." If you believe you haven't repeated an abstraction in Scalaz within the last hour of your using Scala, then you're just wrong. Many people can be wrong. Sometimes, many people can be wrong about *the same thing* -- I bet you could list 10 examples of this outside of computer science.
If you want to teach you (I mean any person here) where all your duplication is, then that's fine. If you don't, then that's fine too. But if you want me to accept that you're not repeating yourself over and over, then you're just not going to get that.
Nobody "needs" Scalaz. It's just a library with a subset that is required to get anything useful done in Scala. I honestly do not care if you right ahead and reinvent it and many do, knowingly or not.
Please listen to Jesper. He has hit it right on the money. Don't take it personally -- there is an awesome learning opportunity lurking in that very short paragraph of his and he is only using Scalaz as the example; forget Scalaz and focus on the message.
4HC14a9dgk9bgQYtGyZg [at] mail [dot] gmail [dot] com" type="cite">The counter-argument, of course, is how many "I"s does it take to reach some form of consensus?
Scalaz is a highly abstract solution for domains that have enough duplication within the sort of problem where scalaz excels. Many don't, and this is just fine for both the domain and for scalaz.
There is a crucial, absolutely critical, distinction between "many don't" and "many believe that they don't." If you believe you haven't repeated an abstraction in Scalaz within the last hour of your using Scala, then you're just wrong. Many people can be wrong. Sometimes, many people can be wrong about *the same thing* -- I bet you could list 10 examples of this outside of computer science.
If you want to teach you (I mean any person here) where all your duplication is, then that's fine. If you don't, then that's fine too. But if you want me to accept that you're not repeating yourself over and over, then you're just not going to get that.
4HC14a9dgk9bgQYtGyZg [at] mail [dot] gmail [dot] com" type="cite">
*Any* form of abstraction or indiscriminate use of a design pattern will seem overblown and excessively complex when used in a place where it isn't appropriate.
If you need scalaz, then that's cool. If you don't, then that's also cool. The only uncool things are pushing a framework on folks who don't need it, or criticising the same framework for people who do.
Nobody "needs" Scalaz. It's just a library with a subset that is required to get anything useful done in Scala. I honestly do not care if you right ahead and reinvent it and many do, knowingly or not.
Please listen to Jesper. He has hit it right on the money. Don't take it personally -- there is an awesome learning opportunity lurking in that very short paragraph of his and he is only using Scalaz as the example; forget Scalaz and focus on the message.
4HC14a9dgk9bgQYtGyZg [at] mail [dot] gmail [dot] com" type="cite">
On 15 November 2011 22:12, Tony Morris <tonymorris [at] gmail [dot] com" rel="nofollow">tonymorris@gmail.com> wrote:
On 16/11/11 03:10, Jesper Nordenberg wrote:
>
> This is definitely true. People look at Scalaz code and say it's
> complex, but that's simply because the abstraction level is so much
> higher than anything they've seen in Java and C++. It takes time and
> effort to grasp all the concepts used at these higher abstraction levels.
Ding ding! Please listen to this man.
The problem is the "I" part in "I find it complex." The moment this is
recognised by any Complexity Complainant, give me a buzz and I'll help
you address the issue -- the "I" issue that is, I will help you
understand the subject matter. I can do this. So can you.
--
Tony Morris
http://tmorris.net/
--
Kevin Wright
mail: kevin [dot] wright [at] scalatechnology [dot] com" target="_blank" rel="nofollow">kevin.wright@scalatechnology.com
gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com" target="_blank" rel="nofollow">kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda
twitter: @thecoda
vibe / skype: kev.lee.wright steam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra
-- Tony Morris http://tmorris.net/
Wed, 2011-11-16, 02:27
#464646
Re: Re: Re: What is highest priority for Scala to succeed in c
Oh, don't get me wrong, I believe that scalaz is often exactly the right solution to some specific problem or other. The problem is that the *entirety* of scalaz often isn't the solution.
I personally feel no great guilt in re-implementing just |> if that's the only thing I need. Even spring, which I generally hate, has a semi-sane SMTP templating library that I'll occasionally use.
Very rarely is a framework or library objectively evil, context is everything; and the cost/benefit analysis is always king
On 16 November 2011 01:51, Tony Morris <tonymorris@gmail.com> wrote:
I personally feel no great guilt in re-implementing just |> if that's the only thing I need. Even spring, which I generally hate, has a semi-sane SMTP templating library that I'll occasionally use.
Very rarely is a framework or library objectively evil, context is everything; and the cost/benefit analysis is always king
On 16 November 2011 01:51, Tony Morris <tonymorris@gmail.com> wrote:
On 11/16/2011 10:45 AM, Kevin Wright wrote:The counter-argument, of course, is how many "I"s does it take to reach some form of consensus?
Scalaz is a highly abstract solution for domains that have enough duplication within the sort of problem where scalaz excels. Many don't, and this is just fine for both the domain and for scalaz.
There is a crucial, absolutely critical, distinction between "many don't" and "many believe that they don't." If you believe you haven't repeated an abstraction in Scalaz within the last hour of your using Scala, then you're just wrong. Many people can be wrong. Sometimes, many people can be wrong about *the same thing* -- I bet you could list 10 examples of this outside of computer science.
If you want to teach you (I mean any person here) where all your duplication is, then that's fine. If you don't, then that's fine too. But if you want me to accept that you're not repeating yourself over and over, then you're just not going to get that.
*Any* form of abstraction or indiscriminate use of a design pattern will seem overblown and excessively complex when used in a place where it isn't appropriate.
If you need scalaz, then that's cool. If you don't, then that's also cool. The only uncool things are pushing a framework on folks who don't need it, or criticising the same framework for people who do.
Nobody "needs" Scalaz. It's just a library with a subset that is required to get anything useful done in Scala. I honestly do not care if you right ahead and reinvent it and many do, knowingly or not.
Please listen to Jesper. He has hit it right on the money. Don't take it personally -- there is an awesome learning opportunity lurking in that very short paragraph of his and he is only using Scalaz as the example; forget Scalaz and focus on the message.
On 15 November 2011 22:12, Tony Morris <tonymorris@gmail.com> wrote:
On 16/11/11 03:10, Jesper Nordenberg wrote:
>
> This is definitely true. People look at Scalaz code and say it's
> complex, but that's simply because the abstraction level is so much
> higher than anything they've seen in Java and C++. It takes time and
> effort to grasp all the concepts used at these higher abstraction levels.
Ding ding! Please listen to this man.
The problem is the "I" part in "I find it complex." The moment this is
recognised by any Complexity Complainant, give me a buzz and I'll help
you address the issue -- the "I" issue that is, I will help you
understand the subject matter. I can do this. So can you.
--
Tony Morris
http://tmorris.net/
--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda
twitter: @thecoda
vibe / skype: kev.lee.wright steam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra
-- Tony Morris http://tmorris.net/
Wed, 2011-11-16, 06:27
#484848
Re: Re: What is highest priority for Scala to succeed in corpor
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Welcome to the Knights who say pimpenrich.
http://en.wikipedia.org/wiki/Knights_who_say_Ni
> Right. I'm not willing to spend more time on that and replaced all mentions
> of “pimp my ...” with “enrich ...” in the upcoming Scala tutorial for C#
> developers.
Yes, right. Let's pimp our language, and start saying "enrich".
> Can't we fix this once and for all? If you see “Pimp”,
"enrich",
"enrich",
"enrich",
"enrich"!
> change it and send a
> pimp request to the owner.
"enrich request"!
Wed, 2011-11-16, 10:07
#4a4a4a
RE: Re: What is highest priority for Scala to succeed in corpor
> And I agree, we should probably take this to -debate.
"This" meaning the pimp-debate, I hope (which is hopefully ended anyway now),
but not the discussion about the original question (see subject),
which is of high interest to all users trying to promote Scala or otherwise
liking to see it used in their professional environment.
(At least for me, due to restricted time, moving a debate to scala-debate
means that I am out, as I am not will to sign and follow an additional
list whose name implies time consuming conversations about possibly low
practical interest).
KR
Det
Thu, 2011-11-17, 02:57
#4c4c4c
Re: Re: What is highest priority for Scala to succeed in corpor
+1
I like this idea that the compiler could give a level warning.
在 2011年11月15日星期二UTC+8下午9时21分35秒,Razvan (Pub) Cojocaru写道:
I like this idea that the compiler could give a level warning.
在 2011年11月15日星期二UTC+8下午9时21分35秒,Razvan (Pub) Cojocaru写道:
While that may hold true sometimes, in the general case - if you refer to programming languages, it is completely false.
Lacking certain tools to SIMPLY express certain constructs (like multiple inheritance or lambdas) leads to mountains of incomprehensible code to
a) achieve the same solution to the problem which stays the same
b) implement an alternative, less efficient solution to the same problem
Most of the time, in programming, the simpler language complicates things.
Having said that, I don’t think a Scala Lite is the answer. I do however think that having configurable compiler warnings based on Martin’s language levels is a better approach.
If my two positions here seem to contradict each-other is because they do, to some extent. The world ain’t black and white.
From: scala...@googlegroups.com [mailto:scala...@googlegroups.com] On Behalf Of Cédric Beust ?
Sent: November-15-11 3:28 AM
To: tmo...@tmorris.net
Cc: scala...@googlegroups.com
Subject: Re: [scala-user] Re: What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?
On Mon, Nov 14, 2011 at 12:48 PM, Tony Morris <tonym...@gmail.com> wrote:
Scala Lite. Are we doomed to the cesspits of neurotic aversion to thinking?
It's about using the right tool for the job. And sometimes, a simpler tool is the right choice.
--
Cédric
Thu, 2011-11-17, 04:27
#4e4e4e
Re: Re: What is highest priority for Scala to succeed in corpor
If you're maintaining a really large codebase, you don't even have this knowledge. Some brilliant undergrad hire 2 levels below you may have constructed code using 'breakOut' or 'CanBuildFrom'. Again, the whole point is _developer_ interchangeability. (To me, the real difference is between a developer and an architect--or whatever terminology you care to use.)@Ken
Well – somewhat agree and disagree with 1)
a) From my (extensive but in one place) EP experience, I/we have NEVER asked a lesser skilled developer to fix/maintain code written by highly skilled developers. It simply never happens. The reverse is the norm. And when you’re running out of highly skilled developers, you’re royally screwed anyways…
I agree partly, but only partly. While working on the Human Genome Project, I had the misfortune to work on a piece of code that was developed by a biologist at Cambridge. Over the course of two weeks, I reduced the code size by >4x, added significant functionality, AND increased code efficiency. The original coder was just an incompetent programmer, she didn't have a clue how to construct software.b) Do not put smart language constructs on the same footing with poor use of stupid languages. I have seen (and see on a daily basis) such convoluted, maintenance-proof designs and code by both above and under-average developers as to turn many a hair white. There is no freaking way that any other average developers will be able to efficiently maintain said code, in either case! Languages don't screw you - people do!
Regardless of that, I encountered some serious problems in understanding her code, because she had been exposed to operator overloading in C++ and seriously abused it.
Now look at Scala and the opportunity for abuse to a bright but undisciplined individual. That's the problem I'm talking about.
Yes, a PROPER dev env should prevent these problems. But if everywhere was a proper dev env, we wouldn't even be talking about them...c) What can I say? Automated peer reviews should work miracles…
Thanks for the feedback,Ken
Thu, 2011-11-17, 09:57
#505050
Re: Re: What is highest priority for Scala to succeed in corpor
On Wed, Nov 16, 2011 at 4:02 AM, Detering Dirk <Dirk.Detering@bitmarck.de> wrote:
> And I agree, we should probably take this to -debate.
[...] (At least for me, due to restricted time, moving a debate to scala-debate
means that I am out, as I am not will to sign and follow an additional
list whose name implies time consuming conversations about possibly low
practical interest).
You can join the group, opt to not receive emails in general, and then go to a specific conversation and choose to get emails for it.
Thu, 2011-11-17, 13:37
#525252
Re: Re: What is highest priority for Scala to succeed in corpor
First - please move this thread to scala-debate. I have asked once already.
Second - I refuse to believe in developer replacability. Teams are more like organisms. Each developer is unique. You can still maintain a codebase without someone, but your team is no longer the same, in terms of what it can accomplish or how it innovates.
I refuse to work for companies that treat developers as legos. This is insulting to developers, and bad for development.
On Nov 16, 2011 10:19 PM, "Ken McDonald" <ykkenmcd@gmail.com> wrote:If you're maintaining a really large codebase, you don't even have this knowledge. Some brilliant undergrad hire 2 levels below you may have constructed code using 'breakOut' or 'CanBuildFrom'. Again, the whole point is _developer_ interchangeability. (To me, the real difference is between a developer and an architect--or whatever terminology you care to use.)@Ken
Well – somewhat agree and disagree with 1)
a) From my (extensive but in one place) EP experience, I/we have NEVER asked a lesser skilled developer to fix/maintain code written by highly skilled developers. It simply never happens. The reverse is the norm. And when you’re running out of highly skilled developers, you’re royally screwed anyways…
I agree partly, but only partly. While working on the Human Genome Project, I had the misfortune to work on a piece of code that was developed by a biologist at Cambridge. Over the course of two weeks, I reduced the code size by >4x, added significant functionality, AND increased code efficiency. The original coder was just an incompetent programmer, she didn't have a clue how to construct software.b) Do not put smart language constructs on the same footing with poor use of stupid languages. I have seen (and see on a daily basis) such convoluted, maintenance-proof designs and code by both above and under-average developers as to turn many a hair white. There is no freaking way that any other average developers will be able to efficiently maintain said code, in either case! Languages don't screw you - people do!
Regardless of that, I encountered some serious problems in understanding her code, because she had been exposed to operator overloading in C++ and seriously abused it.
Now look at Scala and the opportunity for abuse to a bright but undisciplined individual. That's the problem I'm talking about.Yes, a PROPER dev env should prevent these problems. But if everywhere was a proper dev env, we wouldn't even be talking about them...c) What can I say? Automated peer reviews should work miracles…
Thanks for the feedback,Ken
Thu, 2011-11-17, 13:47
#4b4b4b
Re: Re: What is highest priority for Scala to succeed in corpor
First - please move this thread to scala-debate. I have asked once already.
Second - I refuse to believe in developer replacability. Teams are more like organisms. Each developer is unique. You can still maintain a codebase without someone, but your team is no longer the same, in terms of what it can accomplish or how it innovates.
I refuse to work for companies that treat developers as legos. This is insulting to developers, and bad for development.
On Nov 16, 2011 10:19 PM, "Ken McDonald" <ykkenmcd@gmail.com> wrote:If you're maintaining a really large codebase, you don't even have this knowledge. Some brilliant undergrad hire 2 levels below you may have constructed code using 'breakOut' or 'CanBuildFrom'. Again, the whole point is _developer_ interchangeability. (To me, the real difference is between a developer and an architect--or whatever terminology you care to use.)@Ken
Well – somewhat agree and disagree with 1)
a) From my (extensive but in one place) EP experience, I/we have NEVER asked a lesser skilled developer to fix/maintain code written by highly skilled developers. It simply never happens. The reverse is the norm. And when you’re running out of highly skilled developers, you’re royally screwed anyways…
I agree partly, but only partly. While working on the Human Genome Project, I had the misfortune to work on a piece of code that was developed by a biologist at Cambridge. Over the course of two weeks, I reduced the code size by >4x, added significant functionality, AND increased code efficiency. The original coder was just an incompetent programmer, she didn't have a clue how to construct software.b) Do not put smart language constructs on the same footing with poor use of stupid languages. I have seen (and see on a daily basis) such convoluted, maintenance-proof designs and code by both above and under-average developers as to turn many a hair white. There is no freaking way that any other average developers will be able to efficiently maintain said code, in either case! Languages don't screw you - people do!
Regardless of that, I encountered some serious problems in understanding her code, because she had been exposed to operator overloading in C++ and seriously abused it.
Now look at Scala and the opportunity for abuse to a bright but undisciplined individual. That's the problem I'm talking about.Yes, a PROPER dev env should prevent these problems. But if everywhere was a proper dev env, we wouldn't even be talking about them...c) What can I say? Automated peer reviews should work miracles…
Thanks for the feedback,Ken
Fri, 2011-11-18, 01:47
#4d4d4d
Re: Re: What is highest priority for Scala to succeed in corpor
You can join the group, opt to not receive emails in general, and then go to a specific conversation and choose to get emails for it.Not a solution. If the conversation originates in scala-debate and is of general importance, the person who does not have the time to follow scala-debate will not see it. I could go on in a similar vein.
I see this as a real problem. Anything "contentious", regardless of importance and generality, is supposed to go to scala-debate (which is IMHO a group that is followed only by the most enthusiastic--I only follow it intermittently myself.) "scala-user" reaches a much broader base, but is supposed to restrict itself to (simplfying) questions of fact, even if a "contentious" question is significant and important to the entire Scala community.
Perhaps the modifier of "scala-debate" should be allowed to selectively cross-seed "scala-user" with questions they feel are important enough to justify the extra bandwidth? Nothing will ever be perfect, but I'd be happy with this. I certainly don't want to go through all of scala-debate (especially since &^&*^ Google won't even keep it in my sidebar), but I do want to keep up with the main "controversial" issues in Scala.
Cheers,Ken
Fri, 2011-11-18, 01:57
#4f4f4f
Re: Re: What is highest priority for Scala to succeed in corpor
On Monday, November 14, 2011 3:42:06 PM UTC-6, Geir Hedemark wrote:
Heh heh. Very true.
Ken
On 2011, Nov 14, at 7:48 PM, Ken McDonald wrote:
> Tattoos I'm OK with now that they've become part of the cultural mainstream and are sometimes even artistic (But boy, are they going to look awful on a saggy 70-year old).As a tattooed friend of mine said: "If all I have to worry about when it comes to how I look when I am 70 is a wrinkly tattoo, I figure I am ahead of the game."
Geir
Heh heh. Very true.
Ken
Fri, 2011-11-18, 04:57
#505050
Re: Re: What is highest priority for Scala to succeed in corpor
On Thursday, November 17, 2011 at 4:35 PM, Ken McDonald wrote:
> > You can join the group, opt to not receive emails in general, and then go to a specific conversation and choose to get emails for it.
>
> Not a solution. If the conversation originates in scala-debate and is of general importance, the person who does not have the time to follow scala-debate will not see it. I could go on in a similar vein.
>
Ken, please … enough. Would you please move this to scala-debate? Thanks
Fri, 2011-11-18, 07:57
#525252
Re: Re: What is highest priority for Scala to succeed in corpor
On Thu, Nov 17, 2011 at 04:35:28PM -0800, Ken McDonald wrote:
> Not a solution. If the conversation originates in
> scala-debate and is of general importance, the person who
> does not have the time to follow scala-debate will not see
Your entitlement to be read even by people annoyed by your
deliberate and systematic trolling is imginary.
> Nothing will ever be perfect, but I'd be happy with this. I
> certainly don't want to go through all of scala-debate
Your entitlement to set the topic and result of the discussions
of the community without engaging with the community is
imaginary.
> (especially since &^&*^ Google won't even keep it in my
> sidebar)
Your entitlement that everybody adjust their communication
behaviour to compensate for the deficiencies of the
inadequate tool you choose to use is imaginary.
- Florian
Fri, 2011-11-18, 07:57
#545454
Re: Re: What is highest priority for Scala to succeed in corpor
On Thu, Nov 17, 2011 at 04:35:28PM -0800, Ken McDonald wrote:
> Not a solution. If the conversation originates in
> scala-debate and is of general importance, the person who
> does not have the time to follow scala-debate will not see
Your entitlement to be read even by people annoyed by your
deliberate and systematic trolling is imginary.
> Nothing will ever be perfect, but I'd be happy with this. I
> certainly don't want to go through all of scala-debate
Your entitlement to set the topic and result of the discussions
of the community without engaging with the community is
imaginary.
> (especially since &^&*^ Google won't even keep it in my
> sidebar)
Your entitlement that everybody adjust their communication
behaviour to compensate for the deficiencies of the
inadequate tool you choose to use is imaginary.
- Florian
Fri, 2011-11-18, 13:07
#565656
Re: Re: What is highest priority for Scala to succeed in corpor
Already tried that. Still barfs.
Wed, 2011-11-23, 12:37
#585858
Re: Re: What is highest priority for Scala to succeed in corpor
On 2011-11-10 13:08, bryan hunt wrote:
> Ok, an example, one of many, Scala-Query (the project) is not parsed
> correctly by Intellij.
What problems are you having with it? I have done most of the work on
ScalaQuery with IDEA 10 and didn't experience any major issues. I am
building with sbt though, never with the IDE.
-sz
Wed, 2011-11-23, 14:17
#5a5a5a
Re: Re: What is highest priority for Scala to succeed in corpor
On Wed, Nov 23, 2011 at 11:32 AM, Stefan Zeiger <szeiger@novocode.com> wrote:
If I had to guess, I'd say that type-aware highlighting was enabled. I don't think it's good enough yet.
Best,Ismael
What problems are you having with it? I have done most of the work on ScalaQuery with IDEA 10 and didn't experience any major issues. I am building with sbt though, never with the IDE.
If I had to guess, I'd say that type-aware highlighting was enabled. I don't think it's good enough yet.
Best,Ismael
Mon, 2011-11-28, 14:47
#5c5c5c
Re: What is highest priority for Scala to succeed in corporate w
Hi
I really like Hibernate (using (commercially) for over 4 years).
(For me) Scala is looking sexy too.
Is there a plan to port Hibernate to Scala? Similar porting like
NHibernate.
From my point of view: it (Hibernate port) would be a killer app for
Scala language. Lack of Scala version of Hibernate is a blocker for me
to think about Scala really seriously.
Take care,
Adaslaw
PS.
I wrote a post on Hibernate forum too:
https://forum.hibernate.org/viewtopic.php?f=1&t=1013408&p=2450419
Mon, 2011-11-28, 14:57
#555555
Sv: Re: What is highest priority for Scala to succeed in corpor
På mandag 28. november 2011 kl 14:36:06 skrev "Adaslaw" :
> Hi
>
> I really like Hibernate (using (commercially) for over 4 years).
> (For me) Scala is looking sexy too.
>
> Is there a plan to port Hibernate to Scala? Similar porting like
> NHibernate.
> From my point of view: it (Hibernate port) would be a killer app for
> Scala language. Lack of Scala version of Hibernate is a blocker for me
> to think about Scala really seriously.
Hibernate is perfectly usable from Scala. Example-project here: https://github.com/andreak/on-example-rpm
--
Andreas Joseph Krogh - mob: +47 909 56 963
Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc
Mon, 2011-11-28, 15:27
#575757
Re: Re: What is highest priority for Scala to succeed in corpor
Yes, I've used Hibernate + Scala before, *way back* with scala 2.7.1
On Mon, Nov 28, 2011 at 8:47 AM, Andreas Joseph Krogh <andreak@officenet.no> wrote:
On Mon, Nov 28, 2011 at 8:47 AM, Andreas Joseph Krogh <andreak@officenet.no> wrote:
På mandag 28. november 2011 kl 14:36:06 skrev "Adaslaw" <adaslaw@gmail.com>:
> Hi
>
> I really like Hibernate (using (commercially) for over 4 years).
> (For me) Scala is looking sexy too.
>
> Is there a plan to port Hibernate to Scala? Similar porting like
> NHibernate.
> From my point of view: it (Hibernate port) would be a killer app for
> Scala language. Lack of Scala version of Hibernate is a blocker for me
> to think about Scala really seriously.
Hibernate is perfectly usable from Scala. Example-project here: https://github.com/andreak/on-example-rpm
--
Andreas Joseph Krogh <andreak@officenet.no> - mob: +47 909 56 963
Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc
Mon, 2011-11-28, 15:37
#595959
Re: Re: What is highest priority for Scala to succeed in corpor
Generally speaking, Hibernate is not usually the best choice in Scala. It relies on Java's collection framework and passing around mutable objects, so it really doesn't play at all nicely if you're trying to write "idiomatic" code.
There are several other native ORM frameworks available for Scala that are a far better fit:
https://wiki.scala-lang.org/display/SW/Tools+and+Libraries#ToolsandLibraries-DataStorage
and the whole community is watching to see what happens with scala-integrated-query, I expect great things from this project:
https://wiki.scala-lang.org/display/SW/ScalaDays+2011+Resources#ScalaDays2011Resources-ScalaIntegratedQuery-moreexpressivedatabasequeries
On Monday, 28 November 2011, Adaslaw wrote:
--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra
There are several other native ORM frameworks available for Scala that are a far better fit:
https://wiki.scala-lang.org/display/SW/Tools+and+Libraries#ToolsandLibraries-DataStorage
and the whole community is watching to see what happens with scala-integrated-query, I expect great things from this project:
https://wiki.scala-lang.org/display/SW/ScalaDays+2011+Resources#ScalaDays2011Resources-ScalaIntegratedQuery-moreexpressivedatabasequeries
On Monday, 28 November 2011, Adaslaw wrote:
Hi
I really like Hibernate (using (commercially) for over 4 years).
(For me) Scala is looking sexy too.
Is there a plan to port Hibernate to Scala? Similar porting like
NHibernate.
From my point of view: it (Hibernate port) would be a killer app for
Scala language. Lack of Scala version of Hibernate is a blocker for me
to think about Scala really seriously.
Take care,
Adaslaw
PS.
I wrote a post on Hibernate forum too:
https://forum.hibernate.org/viewtopic.php?f=1&t=1013408&p=2450419
--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra
Mon, 2011-11-28, 15:47
#5a5a5a
Re: Re: What is highest priority for Scala to succeed in corpor
On 2011, Nov 28, at 2:36 PM, Adaslaw wrote:
> From my point of view: it (Hibernate port) would be a killer app for
> Scala language. Lack of Scala version of Hibernate is a blocker for me
> to think about Scala really seriously.
We are using hibernate and scala together in production here.
Why do you need a scala version of hibernate?
Geir
Mon, 2011-11-28, 16:57
#5c5c5c
Re: Re: What is highest priority for Scala to succeed in corpor
You are not talking about the famous Rich Hickey's speech?
Thanks,
-Vlad
On Wed, Nov 16, 2011 at 5:45 PM, Xuefeng Wu <benewu@gmail.com> wrote:
Thanks,
-Vlad
On Wed, Nov 16, 2011 at 5:45 PM, Xuefeng Wu <benewu@gmail.com> wrote:
+1
I like this idea that the compiler could give a level warning.
在 2011年11月15日星期二UTC+8下午9时21分35秒,Razvan (Pub) Cojocaru写道:While that may hold true sometimes, in the general case - if you refer to programming languages, it is completely false.
Lacking certain tools to SIMPLY express certain constructs (like multiple inheritance or lambdas) leads to mountains of incomprehensible code to
a) achieve the same solution to the problem which stays the same
b) implement an alternative, less efficient solution to the same problem
Most of the time, in programming, the simpler language complicates things.
Having said that, I don’t think a Scala Lite is the answer. I do however think that having configurable compiler warnings based on Martin’s language levels is a better approach.
If my two positions here seem to contradict each-other is because they do, to some extent. The world ain’t black and white.
From: scala...@googlegroups.com [mailto:scala...@googlegroups.com] On Behalf Of Cédric Beust ?
Sent: November-15-11 3:28 AM
To: tmo...@tmorris.net
Cc: scala...@googlegroups.com
Subject: Re: [scala-user] Re: What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?
On Mon, Nov 14, 2011 at 12:48 PM, Tony Morris <tonym...@gmail.com> wrote:
Scala Lite. Are we doomed to the cesspits of neurotic aversion to thinking?
It's about using the right tool for the job. And sometimes, a simpler tool is the right choice.
--
Cédric
Mon, 2011-11-28, 17:17
#5e5e5e
Re: Re: What is highest priority for Scala to succeed in corpor
i saw that yesterday, and found it quite disappointing. it's like 55 minutes spreading opinion and commonplace, and 5 minutes substantial things, all glued together by metaphors and analogies that can be questioned (starting with the idea of 'easy' as 'near' and at the same time opposite of 'simple' and 'hard'). as an experience report, ok, but in the form of enlightened sermon i found it a rather unconvincing argumentation. (that is not to say, there are many agreeable and reasonable things; but for example saying that switch/match and actors are 'complecting' doesn't help. they can decrease simplicity in one _perspective_, and increase it in another, so it just boils down to a justification of design choices made in clojure).
best, -sciss-
On 28 Nov 2011, at 15:55, Vlad Patryshev wrote:
> You are not talking about the famous Rich Hickey's speech?
>
> Thanks,
> -Vlad
>
>
> On Wed, Nov 16, 2011 at 5:45 PM, Xuefeng Wu wrote:
> +1
> I like this idea that the compiler could give a level warning.
>
> 在 2011年11月15日星期二UTC+8下午9时21分35秒,Razvan (Pub) Cojocaru写道:
> While that may hold true sometimes, in the general case - if you refer to programming languages, it is completely false.
>
>
> Lacking certain tools to SIMPLY express certain constructs (like multiple inheritance or lambdas) leads to mountains of incomprehensible code to
>
> a) achieve the same solution to the problem which stays the same
>
> b) implement an alternative, less efficient solution to the same problem
>
>
>
> Most of the time, in programming, the simpler language complicates things.
>
>
> Having said that, I don’t think a Scala Lite is the answer. I do however think that having configurable compiler warnings based on Martin’s language levels is a better approach.
>
>
> If my two positions here seem to contradict each-other is because they do, to some extent. The world ain’t black and white.
>
>
> From: scala...@googlegroups.com [mailto:scala...@googlegroups.com] On Behalf Of Cédric Beust ?
>
>
> Sent: November-15-11 3:28 AM
> To: tmo...@tmorris.net
> Cc: scala...@googlegroups.com
>
> Subject: Re: [scala-user] Re: What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?
>
>
>
> On Mon, Nov 14, 2011 at 12:48 PM, Tony Morris wrote:
>
> Scala Lite. Are we doomed to the cesspits of neurotic aversion to thinking?
>
>
> It's about using the right tool for the job. And sometimes, a simpler tool is the right choice.
>
>
- « first
- ‹ previous
- 1
- 2
- 3
- 4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/15/2011 10:52 AM, Daniel Sobral wrote:
> But google searches are beside the point. Marc claimed the pattern was
> named after people who explore prostitution, which is flat out wrong.
> The pattern was named after customization of stuff, mainly cars.
I'll pile on, and this will be my last as well. I'm sure that the
people who first used "pimp" in the Scala context had very good
intentions, and didn't mean anything about abuse of women, trafficking,
etc. But that doesn't change the fact that "pimp" has negative
connotations that are embarrassing for the Scala community and probably
hurt adoption.
As others have said, it's much easier to change our nomenclature than to
remove established connotations of the word "pimp". As a community, we
should do the former.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7Csn8ACgkQ5IyIbnMUeTseOQCfdVWBELAsozifkRfhaxMHGAfE
AOoAoJptmjhrr10yFpQyJ3yXt2qkL8gG
=Cxv3
-----END PGP SIGNATURE-----