Re: Why Scala is not (only) side effect free?

On Fri, Sep 9, 2011 at 11:20 AM, Giovanni Giorgi <jj@gioorgi.com> wrote:

But Scala is far too complex. It is a mix of Erlang and Java.

Your language history is a bit off.  Scala and Erlang are cousins, but fairly distant ones.  AFAIK, the only thing Scala actually took from Erlang is the Actors architecture, and that's more part of the Scala libraries than the language itself. 

 I did not understand why Scala has so much mutable data construct.
 Why did not Scala stick with the Side effect free Erlang pattern?

The short answer, I believe, is that that isn't what they were trying to accomplish.  Scala's a pretty broad tent.  If you want a purer functional language, there are plenty of good options out there.  (Haskell seems to be the general favorite.) 

On Fri, Sep 9, 2011 at 11:37 AM, Justin du coeur <jducoeur@gmail.com> wrote:

On Fri, Sep 9, 2011 at 11:20 AM, Giovanni Giorgi <jj@gioorgi.com> wrote:

But Scala is far too complex. It is a mix of Erlang and Java.

Your language history is a bit off.  Scala and Erlang are cousins, but fairly distant ones.  AFAIK, the only thing Scala actually took from Erlang is the Actors architecture,

And pattern matching, I believe.

I don't get the connection with the "Default arguments and reflection"
thread...

On 09/09/2011 17:20, Giovanni Giorgi wrote:
> But Scala is far too complex. It is a mix of Erlang and Java.

Ouch. See scala-debate for heated discussions on complexity of Scala...
Beside, this question should have been asked there...

> I did not understand why Scala has so much mutable data construct.
> Why did not Scala stick with the Side effect free Erlang pattern?
> It is for a better Java integration?

Yes.
And just because Martin Ordersky didn't wanted to make a pure functional
language, but an hybrid with OOP.
There are more functional JVM languages, like Clojure.
Beside, having mutable state, in the JVM at least, allows sometime to
gain extra speed needed in some cases.

> In my humble experience, if you give a programmer **more then one way**
> of doing things, they will mess it up their own code (Perl is an
> example of this).

Having too much ways to do a thing can be confusing (Perl is indeed a
good example!) but having more than one way is called "flexibility"... :-)

On Fri, Sep 9, 2011 at 9:37 AM, Justin du coeur wrote:
> The short answer, I believe, is that that isn't what they were trying to
> accomplish.  Scala's a pretty broad tent.  If you want a purer functional
> language, there are plenty of good options out there.  (Haskell seems to be
> the general favorite.)

if you are stuck on the jvm, there's cal which tries to nail down
side-effects more than scala but less than haskell.

On Fri, Sep 9, 2011 at 2:34 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Fri, Sep 9, 2011 at 11:37 AM, Justin du coeur <jducoeur@gmail.com> wrote:

On Fri, Sep 9, 2011 at 11:20 AM, Giovanni Giorgi <jj@gioorgi.com> wrote:

But Scala is far too complex. It is a mix of Erlang and Java.

Your language history is a bit off.  Scala and Erlang are cousins, but fairly distant ones.  AFAIK, the only thing Scala actually took from Erlang is the Actors architecture,

And pattern matching, I believe.

Really?  I thought that was standard for ML derivatives, but I don't know the ML family well... 

On Fri, Sep 9, 2011 at 11:37 AM, Justin du coeur wrote:

>
> The short answer, I believe, is that that isn't what they were trying to
> accomplish.  Scala's a pretty broad tent.  If you want a purer functional
> language, there are plenty of good options out there.  (Haskell seems to be
> the general favorite.)

Can you do pure functional programming in Scala? I would like to learn
functional programming, and Scala looks like a good first functional
language since you do not have to go completely functional like you
would with, say, Clojure.

On Fri, Sep 9, 2011 at 5:06 PM, Eric MacAdie <emacadie@gmail.com> wrote:

Can you do pure functional programming in Scala? I would like to learn functional programming, and Scala looks like a good first functional
language since you do not have to go completely functional like you
would with, say, Clojure.

Others here are much more expert than I on this topic, but I believe that the answer is yes, with some care.  It's easy to introduce side-effects by using Java libraries, though, so you need to watch what you're doing.  And for sophisticated work, you'll probably want to pull in the Scalaz library, which adds a lot of more-powerful FP mechanisms...

Hi,
first of all, thank you all for the prompt replay.
I have said I know Erlang, but I omitted for brevity the other languages I studied.

I learned Turbo Pascal when I was a kid. Then I learned C/C++ in the 1992, when I was eighteen years old.

Indeed I was a Smalltalk fan from 1995, I learned well PHP, Python, Java and unix scripting.
I also read some chapter of Eric Raymond 's Book on Unix design, which I liked a lot.
It is true you must know unix, to avoid reimplementing it poorly :)

I have take a peek look at Haskell after Scala.

On 09/set/2011, at 20.47, Philippe Lhoste wrote:
>
> On 09/09/2011 17:20, Giovanni Giorgi wrote:
>> But Scala is far too complex. It is a mix of Erlang and Java.
>
> Ouch. See scala-debate for heated discussions on complexity of Scala...
> Beside, this question should have been asked there...

I said Scala is complex for a very simple reason: I tried to learn it, and I get confused very soon :-(
(I read the Bruce Eckel article too)

I was unable to learn very well some programming languages (like Perl for instance) and Scala is giving me a lot of trouble.
I like a lot some Scala idea, like the type inference system, which is one of the most advanced I see.
So I am asking beacause I am trying to understand the design philosophy behind Scala.
>
>> I did not understand why Scala has so much mutable data construct.
>> Why did not Scala stick with the Side effect free Erlang pattern?
>> It is for a better Java integration?
>
> Yes.
> And just because Martin Ordersky didn't wanted to make a pure functional language, but an hybrid with OOP.

There is nothing wrong with it.
Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.

The lack of side effect gives a very high degree of optimization, at least in Erlang.
I know it is impossible to gain so high speed in a Java (mutable) Virtual Machine.
>
> Having too much ways to do a thing can be confusing (Perl is indeed a good example!) but having more than one way is called "flexibility"... :-)
Flexibility is a not the key point here.
Assembler is so flexible :) You can ever overwrite your stack with brand new code (Buffer Overflow)!

If you want to do functional programming in Java you have plenty of ways.
Java is 16 years old now, a lot of framework will help you.

You can use LambdaJ, or write a lot of "{}" pairs in your code:
http://gioorgi.com/2010/closure-in-java-fast-and-nice/
So functional mutable mix is already possible in Java.

But Scala has a very good opportunity to me: it is a entire new language!

You could get a brand new side-effect free language which can generate JVM bytecodes!
And Scala is indeed powerful then Erlang, because of its strong inference typing.

If you go for a lunch, and you could choose from a very vast menu, it will be good.
But if you are going to build a software-skyscraper, you need to stress a clear path to all the software architects will work with you.

On 09/09/2011 17:20, Giovanni Giorgi wrote:
> I am new to scala but I have a strong Java background (I also learned
> Erlang, but used it not so much)
>
> I like Scala because it generate Java code. And Java code is fast and
> reliable.

To be precise, it generates JVM (byte)code, not Java code.

In one of his tweets, Debasish Ghosh pointed to Frege, a language I
didn't know before: http://code.google.com/p/frege/
That's a "non-strict, pure functional programming language in the spirit
of Haskell." running on the JVM.
So if you search a kind of Haskell for the JVM, it can be a language to
play with.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.

Sorry, gotta correct you here. Web programming in pure functional
environments is light years ahead of the rest in terms of ease. Second
place is not even close.

Be cool to see an IoC container like Spring do function injection based on pattern matching.

Billy

On Sep 10, 2011, at 15:33, Tony Morris wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.
>
> Sorry, gotta correct you here. Web programming in pure functional
> environments is light years ahead of the rest in terms of ease. Second
> place is not even close.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOa8miAAoJEPxHMY3rBz0PYvUH/30bB2vC3SQiqW0ctozA7aJZ
> tXi3pBPjv0QkSq6Lcg9p4UAytfBBP2wpkWz1csDD7Ej+9PqcUvvhBvpx6XHa3Gei
> 688QbOpJlASk7SAzvSLgUUU9zyu9IsR5TjjrNEUfeePspvVxlJxBvkwXIydwgBV3
> qrLA/QhpVvd1rYz/Sy19Kv68nxFc5d3wcKUbywu/BpbuocTg3XeidPJWHGAjwcTO
> 1ffjZ7o8vDR+PYInlyCQxFUADuJxyFqDkeFKU1eNpHxnX8y8nLSbEy7v0+Ee8s6j
> jNVTbSDyLf5rdWr6dGDby7nvfcmyLk0uhWdQOcfpSBcHFq3kfMHR9IRzreGaX7k=
> =ea0W
> -----END PGP SIGNATURE-----

No... No it wouldn't.
Adding Spring to our nice pristine scala projects is distinctly *not* cool!

On 10 September 2011 22:35, Ross Rose <rossrose69@gmail.com> wrote:

Be cool to see an IoC container like Spring do function injection based on pattern matching.

Billy

On Sep 10, 2011, at 15:33, Tony Morris <tonymorris@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.
>
> Sorry, gotta correct you here. Web programming in pure functional
> environments is light years ahead of the rest in terms of ease. Second
> place is not even close.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOa8miAAoJEPxHMY3rBz0PYvUH/30bB2vC3SQiqW0ctozA7aJZ
> tXi3pBPjv0QkSq6Lcg9p4UAytfBBP2wpkWz1csDD7Ej+9PqcUvvhBvpx6XHa3Gei
> 688QbOpJlASk7SAzvSLgUUU9zyu9IsR5TjjrNEUfeePspvVxlJxBvkwXIydwgBV3
> qrLA/QhpVvd1rYz/Sy19Kv68nxFc5d3wcKUbywu/BpbuocTg3XeidPJWHGAjwcTO
> 1ffjZ7o8vDR+PYInlyCQxFUADuJxyFqDkeFKU1eNpHxnX8y8nLSbEy7v0+Ee8s6j
> jNVTbSDyLf5rdWr6dGDby7nvfcmyLk0uhWdQOcfpSBcHFq3kfMHR9IRzreGaX7k=
> =ea0W
> -----END PGP SIGNATURE-----

--
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

I +1 that!!

On 10 Sep 2011, at 23:07, Kevin Wright <kev.lee.wright@gmail.com> wrote:

No... No it wouldn't.
Adding Spring to our nice pristine scala projects is distinctly *not* cool!

On 10 September 2011 22:35, Ross Rose < (rossrose69 [at] gmail [dot] com> wrote:

Be cool to see an IoC container like Spring do function injection based on pattern matching.

Billy

On Sep 10, 2011, at 15:33, Tony Morris < (tonymorris [at] gmail [dot] com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.
>
> Sorry, gotta correct you here. Web programming in pure functional
> environments is light years ahead of the rest in terms of ease. Second
> place is not even close.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOa8miAAoJEPxHMY3rBz0PYvUH/30bB2vC3SQiqW0ctozA7aJZ
> tXi3pBPjv0QkSq6Lcg9p4UAytfBBP2wpkWz1csDD7Ej+9PqcUvvhBvpx6XHa3Gei
> 688QbOpJlASk7SAzvSLgUUU9zyu9IsR5TjjrNEUfeePspvVxlJxBvkwXIydwgBV3
> qrLA/QhpVvd1rYz/Sy19Kv68nxFc5d3wcKUbywu/BpbuocTg3XeidPJWHGAjwcTO
> 1ffjZ7o8vDR+PYInlyCQxFUADuJxyFqDkeFKU1eNpHxnX8y8nLSbEy7v0+Ee8s6j
> jNVTbSDyLf5rdWr6dGDby7nvfcmyLk0uhWdQOcfpSBcHFq3kfMHR9IRzreGaX7k=
> =ea0W
> -----END PGP SIGNATURE-----

--
Kevin Wright
mail:  (kevin [dot] wright [at] scalatechnology [dot] com
gtalk / msn : (kev [dot] lee [dot] wright [at] gmail [dot] 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

I +10 that. The first project I ever worked on professionally was an extant java web app wired up witha whole lot of Spring and I've since developed a hatred of Spring-style "Magic" and other non-obvious tricks.
Which is not to say I like writing boilerplate, just that I don't like my code to behave strangely due tosome tiny bit of config somewhere.
Too bad the python app I work on right now uses some "Magic" :-/
On 11 September 2011 01:04, Raymond Barlow <rbarlow@raymanoz.com> wrote:

I +1 that!!

On 10 Sep 2011, at 23:07, Kevin Wright <kev.lee.wright@gmail.com> wrote:

No... No it wouldn't.
Adding Spring to our nice pristine scala projects is distinctly *not* cool!

On 10 September 2011 22:35, Ross Rose <rossrose69@gmail.comrossrose69@gmail.com> wrote:

Be cool to see an IoC container like Spring do function injection based on pattern matching.

Billy

On Sep 10, 2011, at 15:33, Tony Morris <tonymorris@gmail.comtonymorris@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.
>
> Sorry, gotta correct you here. Web programming in pure functional
> environments is light years ahead of the rest in terms of ease. Second
> place is not even close.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOa8miAAoJEPxHMY3rBz0PYvUH/30bB2vC3SQiqW0ctozA7aJZ
> tXi3pBPjv0QkSq6Lcg9p4UAytfBBP2wpkWz1csDD7Ej+9PqcUvvhBvpx6XHa3Gei
> 688QbOpJlASk7SAzvSLgUUU9zyu9IsR5TjjrNEUfeePspvVxlJxBvkwXIydwgBV3
> qrLA/QhpVvd1rYz/Sy19Kv68nxFc5d3wcKUbywu/BpbuocTg3XeidPJWHGAjwcTO
> 1ffjZ7o8vDR+PYInlyCQxFUADuJxyFqDkeFKU1eNpHxnX8y8nLSbEy7v0+Ee8s6j
> jNVTbSDyLf5rdWr6dGDby7nvfcmyLk0uhWdQOcfpSBcHFq3kfMHR9IRzreGaX7k=
> =ea0W
> -----END PGP SIGNATURE-----

--
Kevin Wright
mail: kevin.wright@scalatechnology.comkevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.comkev.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

body p { margin-bottom: 0cm; margin-top: 0pt; }

About Spring: I actually like it:

* Being in XML means it is rigid, and thus your top-level services (API) must have a consistent form. I did a project using Spring Java Config and it turned out to be a mess. Spring-dm is a blessing compared to raw OSGI.

* You can define services an any order you like. E.g., each new service declaration can appear at the end and yet injected in other beans. With any other language, you must push it at the right place. You can think of it as lazy symbol evaluation.

* Bean post processing is very nice. E.g., configuration injection is with very little ceremony (${myproperty:defaultvalue})

* Some other things not possible in other languages (template beans, the XxxAware interfaces, AOP, lookup methods)

I kind of wish it would be typesafe and static (i.e., some sort of compilation phase)

Ittay

Adam Jorgensen wrote:

Ls37wXbo0gm+X0Xjd4qnpAg [at] mail [dot] gmail [dot] com" type="cite">I +10 that. The first project I ever worked on professionally was an extant java web app wired up with a whole lot of Spring and I've since developed a hatred of Spring-style "Magic" and other non-obvious tricks.
Which is not to say I like writing boilerplate, just that I don't like my code to behave strangely due to some tiny bit of config somewhere.
Too bad the python app I work on right now uses some "Magic" :-/
On 11 September 2011 01:04, Raymond Barlow <rbarlow [at] raymanoz [dot] com" rel="nofollow">rbarlow@raymanoz.com> wrote:

I +1 that!!

On 10 Sep 2011, at 23:07, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com" target="_blank" rel="nofollow">kev.lee.wright@gmail.com> wrote:

No... No it wouldn't.
Adding Spring to our nice pristine scala projects is distinctly *not* cool!

On 10 September 2011 22:35, Ross Rose <rossrose69 [at] gmail [dot] com" target="_blank" rel="nofollow">rossrose69@gmail.com> wrote:

Be cool to see an IoC container like Spring do function injection based on pattern matching.

Billy

On Sep 10, 2011, at 15:33, Tony Morris <tonymorris [at] gmail [dot] com" target="_blank" rel="nofollow">tonymorris@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.
>
> Sorry, gotta correct you here. Web programming in pure functional
> environments is light years ahead of the rest in terms of ease. Second
> place is not even close.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOa8miAAoJEPxHMY3rBz0PYvUH/30bB2vC3SQiqW0ctozA7aJZ
> tXi3pBPjv0QkSq6Lcg9p4UAytfBBP2wpkWz1csDD7Ej+9PqcUvvhBvpx6XHa3Gei
> 688QbOpJlASk7SAzvSLgUUU9zyu9IsR5TjjrNEUfeePspvVxlJxBvkwXIydwgBV3
> qrLA/QhpVvd1rYz/Sy19Kv68nxFc5d3wcKUbywu/BpbuocTg3XeidPJWHGAjwcTO
> 1ffjZ7o8vDR+PYInlyCQxFUADuJxyFqDkeFKU1eNpHxnX8y8nLSbEy7v0+Ee8s6j
> jNVTbSDyLf5rdWr6dGDby7nvfcmyLk0uhWdQOcfpSBcHFq3kfMHR9IRzreGaX7k=
> =ea0W
> -----END PGP SIGNATURE-----

--
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

What I meant was an IoC container written in scala that does functional injection, my appologies for the implied statement not being more concrete. It may not even look anything like the Spring of today. The essence of my statement was soley towards the IoC aspect of the funtionality. To take it to a next level, the XML facilities (in scala) could be leveraged in some fashion to produce a dynamic IoC paradigm wherein the "context" can be meta-injected.

Billy
On Sep 10, 2011, at 17:07, Kevin Wright <kev.lee.wright@gmail.com> wrote:

No... No it wouldn't.
Adding Spring to our nice pristine scala projects is distinctly *not* cool!

On 10 September 2011 22:35, Ross Rose < (rossrose69 [at] gmail [dot] com> wrote:

Be cool to see an IoC container like Spring do function injection based on pattern matching.

Billy

On Sep 10, 2011, at 15:33, Tony Morris < (tonymorris [at] gmail [dot] com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.
>
> Sorry, gotta correct you here. Web programming in pure functional
> environments is light years ahead of the rest in terms of ease. Second
> place is not even close.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOa8miAAoJEPxHMY3rBz0PYvUH/30bB2vC3SQiqW0ctozA7aJZ
> tXi3pBPjv0QkSq6Lcg9p4UAytfBBP2wpkWz1csDD7Ej+9PqcUvvhBvpx6XHa3Gei
> 688QbOpJlASk7SAzvSLgUUU9zyu9IsR5TjjrNEUfeePspvVxlJxBvkwXIydwgBV3
> qrLA/QhpVvd1rYz/Sy19Kv68nxFc5d3wcKUbywu/BpbuocTg3XeidPJWHGAjwcTO
> 1ffjZ7o8vDR+PYInlyCQxFUADuJxyFqDkeFKU1eNpHxnX8y8nLSbEy7v0+Ee8s6j
> jNVTbSDyLf5rdWr6dGDby7nvfcmyLk0uhWdQOcfpSBcHFq3kfMHR9IRzreGaX7k=
> =ea0W
> -----END PGP SIGNATURE-----

--
Kevin Wright
mail:  (kevin [dot] wright [at] scalatechnology [dot] com
gtalk / msn : (kev [dot] lee [dot] wright [at] gmail [dot] 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

+1

In an FP context things like Spring look pretty stupid. I really dislike Spring in Java context ... imagine how I'd feel about it in Scala context.

Marius

On Sun, Sep 11, 2011 at 1:07 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

No... No it wouldn't.
Adding Spring to our nice pristine scala projects is distinctly *not* cool!

On 10 September 2011 22:35, Ross Rose <rossrose69@gmail.com> wrote:

Be cool to see an IoC container like Spring do function injection based on pattern matching.

Billy

On Sep 10, 2011, at 15:33, Tony Morris <tonymorris@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.
>
> Sorry, gotta correct you here. Web programming in pure functional
> environments is light years ahead of the rest in terms of ease. Second
> place is not even close.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOa8miAAoJEPxHMY3rBz0PYvUH/30bB2vC3SQiqW0ctozA7aJZ
> tXi3pBPjv0QkSq6Lcg9p4UAytfBBP2wpkWz1csDD7Ej+9PqcUvvhBvpx6XHa3Gei
> 688QbOpJlASk7SAzvSLgUUU9zyu9IsR5TjjrNEUfeePspvVxlJxBvkwXIydwgBV3
> qrLA/QhpVvd1rYz/Sy19Kv68nxFc5d3wcKUbywu/BpbuocTg3XeidPJWHGAjwcTO
> 1ffjZ7o8vDR+PYInlyCQxFUADuJxyFqDkeFKU1eNpHxnX8y8nLSbEy7v0+Ee8s6j
> jNVTbSDyLf5rdWr6dGDby7nvfcmyLk0uhWdQOcfpSBcHFq3kfMHR9IRzreGaX7k=
> =ea0W
> -----END PGP SIGNATURE-----

--
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

On Sunday, September 11, 2011 10:38:57 AM UTC-4, Billy wrote:

What I meant was an IoC container written in scala that does functional injection,

IoC is a tepid idea that I have yet to see executed anything but _horribly_. It bloats code into a bunch of tiny pieces that are _never_ properly coordinated, and an error in one component _always_ bubbles outward to trip up all other bits (in spite of the supposed isolation of code that inversion-of-control is supposed to provide).
It's such a bad idea that I have routinely *thrown out* résumés early in the hiring process that have emphasized "enterprise-y" software components including Spring, EJB, yadda yadda (I call it the "J2EE alphabet soup"). That filtering has resulted in *much* better code.
Sorry... Spring is just Bad on so many counts that it has soured me to the IoC concept permanently.

body p { margin-bottom: 0cm; margin-top: 0pt; }

Todd Vierling wrote:

On Sunday, September 11, 2011 10:38:57 AM UTC-4, Billy wrote:

What I meant was an IoC container written in scala that does functional injection,

IoC is a tepid idea that I have yet to see executed anything but _horribly_. It bloats code into a bunch of tiny pieces that are _never_ properly coordinated, and an error in one component _always_ bubbles outward to trip up all other bits (in spite of the supposed isolation of code that inversion-of-control is supposed to provide).

As someone who appriciates DI (IoC is a different concept), I'd love if you could backup your claims with an example. What do you do when service A needs to call service B? Do you use singletons, or do you inject it manually. If manually, then how's using Spring make things so horrible?

It's such a bad idea that I have routinely *thrown out* résumés early in the hiring process that have emphasized "enterprise-y" software components including Spring, EJB, yadda yadda (I call it the "J2EE alphabet soup"). That filtering has resulted in *much* better code.
Sorry... Spring is just Bad on so many counts that it has soured me to the IoC concept permanently.

On Sunday, September 11, 2011 12:52:31 PM UTC-4, Ittay Dror wrote:

As someone who appriciates DI (IoC is a different concept), I'd love if you could backup your claims with an example. What do you do when service A needs to call service B? Do you use singletons, or do you inject it manually. If manually, then how's using Spring make things so horrible?

This question is loaded with architecture assumptions. I have worked on pretty large apps (50k+ lines of code, running across 4-10 physical systems) but I have yet to see any application that requires so much granularity of code that you even need to ask the question "What do you do when service A needs to call service B?"
If you're thinking like this, then you've already assumed the addition of extra abstraction code just for the purpose of having an abstraction. Generally most of these concerns are addressable through multiple inheritance (mixins) or function/trait signatures that can be resolved completely at compile time, without proliferation of obese and error-prone configuration files, and unnecessary layers of abstraction.
(It's this same reasoning that led me to ask the champions of AOP, at JBoss World some 7 or 8 years ago, whether it was really intended to address so-called "cross-cutting concerns". After 10 minutes of my questioning, Marc Fleury nearly broke down, and finally admitted that his need for AOP was almost entirely to address the lack of multiple inheritance in Java... making the cutpoint concept yet another layer of abstraction that simply Tries Too Hard in order to further abstraction for abstraction's sake.)

On Sunday, September 11, 2011 1:19:01 PM UTC-4, Todd Vierling wrote:

If you're thinking like this, then you've already assumed the addition of extra abstraction code just for the purpose of having an abstraction. Generally most of these concerns are addressable through multiple inheritance (mixins) or function/trait signatures that can be resolved completely at compile time, without proliferation of obese and error-prone configuration files, and unnecessary layers of abstraction.

To correct a thinko in the above sentence: "function/type signatures" (not trait) -- by "type signature", I'm referring to what Scala calls structural types.

body p { margin-bottom: 0cm; margin-top: 0pt; }

Todd Vierling wrote:

On Sunday, September 11, 2011 12:52:31 PM UTC-4, Ittay Dror wrote:

As someone who appriciates DI (IoC is a different concept), I'd love if you could backup your claims with an example. What do you do when service A needs to call service B? Do you use singletons, or do you inject it manually. If manually, then how's using Spring make things so horrible?

This question is loaded with architecture assumptions. I have worked on pretty large apps (50k+ lines of code, running across 4-10 physical systems) but I have yet to see any application that requires so much granularity of code that you even need to ask the question "What do you do when service A needs to call service B?"
If you're thinking like this, then you've already assumed the addition of extra abstraction code just for the purpose of having an abstraction. Generally most of these concerns are addressable through multiple inheritance (mixins) or function/trait signatures that can be resolved completely at compile time, without proliferation of obese and error-prone configuration files, and unnecessary layers of abstraction.

sure. then this is the manual injection i was referring to. in which case, Spring's contribution is that it allows you to declare your services in any order you want, manipulate them (with post processing) and have a more concise way of injecting configuration properties.

(It's this same reasoning that led me to ask the champions of AOP, at JBoss World some 7 or 8 years ago, whether it was really intended to address so-called "cross-cutting concerns". After 10 minutes of my questioning, Marc Fleury nearly broke down, and finally admitted that his need for AOP was almost entirely to address the lack of multiple inheritance in Java... making the cutpoint concept yet another layer of abstraction that simply Tries Too Hard in order to further abstraction for abstraction's sake.)

On Sep 11, 2011, at 19:52 , Ittay Dror wrote:

Todd Vierling wrote:

On Sunday, September 11, 2011 12:52:31 PM UTC-4, Ittay Dror wrote:

As someone who appriciates DI (IoC is a different concept), I'd love if you could backup your claims with an example. What do you do when service A needs to call service B? Do you use singletons, or do you inject it manually. If manually, then how's using Spring make things so horrible?

This question is loaded with architecture assumptions. I have worked on pretty large apps (50k+ lines of code, running across 4-10 physical systems) but I have yet to seeany application that requires so much granularity of code that you even need to ask the question "What do you do when service A needs to call service B?"
If you're thinking like this, then you've already assumed the addition of extra abstraction code just for the purpose of having an abstraction. Generally most of these concerns are addressable through multiple inheritance (mixins) or function/trait signatures that can be resolved completely at compile time, without proliferation of obese and error-prone configuration files, and unnecessary layers of abstraction.

sure. then this is the manual injection i was referring to. in which case, Spring's contribution is that it allows you to declare your services in any order you want, manipulate them (with post processing) and have a more concise way of injecting configuration properties. 

Having recently written a ca. 100kSLOC application consisting of several dozen different components, I very much enjoyed not having to worry about spring etc. It is just so much more direct and less error-prone to just use "new ..." instead of having to create several objects just for being able to parse the wiring instructions. One other aspect is that someone not familiar with the code base can simply code-navigate from the main method to see the wiring at a few glances instead of having to switch between code and markup every time, possibly mixing up different resource locations in the process. YMMV …
Roland KuhnTypesafe – Enterprise-Grade Scala from the Expertstwitter: @rolandkuhn

Perhaps a use case for DI might be in order. Scenario: developing a (very) large solution in field F for a specific domain D that provides service type T. A new domain D2 is later acquired that falls in F and must provide T. Every aspect about T is the same except for the underlying business rules that apply to the data for D2. Without DI, one would be left maintaining an entirely new branch of T as a separate solution rather than simply injecting those classes which apply the rules for the domain. Now, compound this with new domains being added every year or two (sometimes multiple at one time).

Billy
On Sep 11, 2011, at 12:19, Todd Vierling <tv@duh.org> wrote:

On Sunday, September 11, 2011 12:52:31 PM UTC-4, Ittay Dror wrote:

As someone who appriciates DI (IoC is a different concept), I'd love if you could backup your claims with an example. What do you do when service A needs to call service B? Do you use singletons, or do you inject it manually. If manually, then how's using Spring make things so horrible?

This question is loaded with architecture assumptions. I have worked on pretty large apps (50k+ lines of code, running across 4-10 physical systems) but I have yet to see any application that requires so much granularity of code that you even need to ask the question "What do you do when service A needs to call service B?"
If you're thinking like this, then you've already assumed the addition of extra abstraction code just for the purpose of having an abstraction. Generally most of these concerns are addressable through multiple inheritance (mixins) or function/trait signatures that can be resolved completely at compile time, without proliferation of obese and error-prone configuration files, and unnecessary layers of abstraction.
(It's this same reasoning that led me to ask the champions of AOP, at JBoss World some 7 or 8 years ago, whether it was really intended to address so-called "cross-cutting concerns". After 10 minutes of my questioning, Marc Fleury nearly broke down, and finally admitted that his need for AOP was almost entirely to address the lack of multiple inheritance in Java... making the cutpoint concept yet another layer of abstraction that simply Tries Too Hard in order to further abstraction for abstraction's sake.)

Hi Ross,
I fully agree with this. All I’m saying is that DI may well be done without involving XML files. The approach I prefer (BTW: the example was from before I joined Typesafe) is to structure the code base into sub-projects which are then mixed and matched as needed. The joining and wiring happens in a very shallow top-level project, but using a programmatic approach which does not involve any big frameworks. Think of it as “compiling the Spring bean instantiation away” and making it static. One delivered product will always be static in that sense anyway.
Regards,
Roland
On Sep 11, 2011, at 21:21 , Ross Rose wrote:

Perhaps a use case for DI might be in order. Scenario: developing a (very) large solution in field F for a specific domain D that provides service type T. A new domain D2 is later acquired that falls in F and must provide T. Every aspect about T is the same except for the underlying business rules that apply to the data for D2. Without DI, one would be left maintaining an entirely new branch of T as a separate solution rather than simply injecting those classes which apply the rules for the domain. Now, compound this with new domains being added every year or two (sometimes multiple at one time).

Billy
On Sep 11, 2011, at 12:19, Todd Vierling <tv@duh.org> wrote:

On Sunday, September 11, 2011 12:52:31 PM UTC-4, Ittay Dror wrote:

As someone who appriciates DI (IoC is a different concept), I'd love if you could backup your claims with an example. What do you do when service A needs to call service B? Do you use singletons, or do you inject it manually. If manually, then how's using Spring make things so horrible?

This question is loaded with architecture assumptions. I have worked on pretty large apps (50k+ lines of code, running across 4-10 physical systems) but I have yet to see any application that requires so much granularity of code that you even need to ask the question "What do you do when service A needs to call service B?"
If you're thinking like this, then you've already assumed the addition of extra abstraction code just for the purpose of having an abstraction. Generally most of these concerns are addressable through multiple inheritance (mixins) or function/trait signatures that can be resolved completely at compile time, without proliferation of obese and error-prone configuration files, and unnecessary layers of abstraction.
(It's this same reasoning that led me to ask the champions of AOP, at JBoss World some 7 or 8 years ago, whether it was really intended to address so-called "cross-cutting concerns". After 10 minutes of my questioning, Marc Fleury nearly broke down, and finally admitted that his need for AOP was almost entirely to address the lack of multiple inheritance in Java... making the cutpoint concept yet another layer of abstraction that simply Tries Too Hard in order to further abstraction for abstraction's sake.)

Roland KuhnTypesafe – Enterprise-Grade Scala from the Expertstwitter: @rolandkuhn

On Sun, Sep 11, 2011 at 3:32 PM, Roland Kuhn wrote:
> I fully agree with this. All I’m saying is that DI may well be done without
> involving XML files. The approach I prefer (BTW: the example was from before
> I joined Typesafe) is to structure the code base into sub-projects which are
> then mixed and matched as needed.

Combined with traits -- or if "true" decoupling is needed, structural
types -- you can get the best of both worlds by making the
"configuration" consist of a couple lines of code calling 'new ...
with ...' rather than obtuse XML.

If you're writing code by not writing code (using XML-based DI,
cutpoints, etc.), IMO you're highly likely to be doing something
wrong, and probably only doing it to work around deficiencies in the
source code language. I have yet to see any Spring-based project that
wasn't prone to error in the configuration because it was hard to
track what parts of config correlated to what parts of code (among
other complications).

Going back to the root of this subthread: Scala contains many
facilities useful for static dependency injection without requiring
these excessive layers of abstraction, so adding Spring-like
functionality to a Scala project is almost guaranteed to add
complexity for little to no gain.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/12/2011 12:38 AM, Ross Rose wrote:
> What I meant was an IoC container written in scala that does functional injection, my appologies for the implied statement not being more concrete. It may not even look anything like the Spring of today. The essence of my statement was soley towards the IoC aspect of the funtionality. To take it to a next level, the XML facilities (in scala) could be leveraged in some fashion to produce a dynamic IoC paradigm wherein the "context" can be meta-injected.
>
> Billy
>
> On Sep 10, 2011, at 17:07, Kevin Wright wrote:
>
>> No... No it wouldn't.
>>
>> Adding Spring to our nice pristine scala projects is distinctly *not* cool!
>>
>>
>> On 10 September 2011 22:35, Ross Rose wrote:
>> Be cool to see an IoC container like Spring do function injection based on pattern matching.
>>
>> Billy
>>
>> On Sep 10, 2011, at 15:33, Tony Morris wrote:
>>
> On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>>>>> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.
>
> Sorry, gotta correct you here. Web programming in pure functional
> environments is light years ahead of the rest in terms of ease. Second
> place is not even close.
>
>
>>
>>
>>

Totally agree and I've used that type of hierarchy myself in other projects. The difficulties in practice for the senario I speak of, however, go further than design constraints. Whenever such a solution is updated and rebuilt with said new type T rules, it is required to redeploy to all instances of the solution to maintain a level code base throughout the enterprise. This aspect makes it non-trivial due to the enourmous effort needed to redeploy all domains. Under such constraints DI offers the best solution since the tried and true code base is not rebuilt, only new classes are (which get injected via the context).

Billy
On Sep 11, 2011, at 14:32, Roland Kuhn <google@rkuhn.info> wrote:

Hi Ross,
I fully agree with this. All I’m saying is that DI may well be done without involving XML files. The approach I prefer (BTW: the example was from before I joined Typesafe) is to structure the code base into sub-projects which are then mixed and matched as needed. The joining and wiring happens in a very shallow top-level project, but using a programmatic approach which does not involve any big frameworks. Think of it as “compiling the Spring bean instantiation away” and making it static. One delivered product will always be static in that sense anyway.
Regards,
Roland
On Sep 11, 2011, at 21:21 , Ross Rose wrote:

Perhaps a use case for DI might be in order. Scenario: developing a (very) large solution in field F for a specific domain D that provides service type T. A new domain D2 is later acquired that falls in F and must provide T. Every aspect about T is the same except for the underlying business rules that apply to the data for D2. Without DI, one would be left maintaining an entirely new branch of T as a separate solution rather than simply injecting those classes which apply the rules for the domain. Now, compound this with new domains being added every year or two (sometimes multiple at one time).

Billy
On Sep 11, 2011, at 12:19, Todd Vierling < (tv [at] duh [dot] org> wrote:

On Sunday, September 11, 2011 12:52:31 PM UTC-4, Ittay Dror wrote:

As someone who appriciates DI (IoC is a different concept), I'd love if you could backup your claims with an example. What do you do when service A needs to call service B? Do you use singletons, or do you inject it manually. If manually, then how's using Spring make things so horrible?

This question is loaded with architecture assumptions. I have worked on pretty large apps (50k+ lines of code, running across 4-10 physical systems) but I have yet to see any application that requires so much granularity of code that you even need to ask the question "What do you do when service A needs to call service B?"
If you're thinking like this, then you've already assumed the addition of extra abstraction code just for the purpose of having an abstraction. Generally most of these concerns are addressable through multiple inheritance (mixins) or function/trait signatures that can be resolved completely at compile time, without proliferation of obese and error-prone configuration files, and unnecessary layers of abstraction.
(It's this same reasoning that led me to ask the champions of AOP, at JBoss World some 7 or 8 years ago, whether it was really intended to address so-called "cross-cutting concerns". After 10 minutes of my questioning, Marc Fleury nearly broke down, and finally admitted that his need for AOP was almost entirely to address the lack of multiple inheritance in Java... making the cutpoint concept yet another layer of abstraction that simply Tries Too Hard in order to further abstraction for abstraction's sake.)

Roland KuhnTypesafe – Enterprise-Grade Scala from the Expertstwitter: @rolandkuhn

> Combined with traits -- or if "true" decoupling is needed, structural
> types -- you can get the best of both worlds by making the
> "configuration" consist of a couple lines of code calling 'new ...
> with ...' rather than obtuse XML.
>

On Sun, Sep 11, 2011 at 6:37 PM, Ross Rose wrote:
>> Combined with traits -- or if "true" decoupling is needed, structural
>> types -- you can get the best of both worlds by making the
>> "configuration" consist of a couple lines of code calling 'new ...
>> with ...' rather than obtuse XML.

> As stated, having to recompile said couple of lines for a new domain would require redeployment to all domains to maintain a level code base,

Scala has an entrypoint that accepts uncompiled source code, which can
be linked to precompiled classes. This is how Scala scripts work.

If you like Spring then you like Spring.
Personally, I find moving from coding in an actual language to wiring stuff up with XML config files pretty distasteful.
I certainly appreciate the strengths of DI and so forth but Spring just seems to be another 10-ton gorilla that makes it painful like 1995.
On 11 September 2011 08:10, Ittay Dror <ittay.dror@gmail.com> wrote:

About Spring: I actually like it:

* Being in XML means it is rigid, and thus your top-level services (API) must have a consistent form. I did a project using Spring Java Config and it turned out to be a mess. Spring-dm is a blessing compared to raw OSGI.

* You can define services an any order you like. E.g., each new service declaration can appear at the end and yet injected in other beans. With any other language, you must push it at the right place. You can think of it as lazy symbol evaluation.

* Bean post processing is very nice. E.g., configuration injection is with very little ceremony (${myproperty:defaultvalue})

* Some other things not possible in other languages (template beans, the XxxAware interfaces, AOP, lookup methods)

I kind of wish it would be typesafe and static (i.e., some sort of compilation phase)

Ittay

Adam Jorgensen wrote:

I +10 that. The first project I ever worked on professionally was an extant java web app wired up with a whole lot of Spring and I've since developed a hatred of Spring-style "Magic" and other non-obvious tricks.
Which is not to say I like writing boilerplate, just that I don't like my code to behave strangely due to some tiny bit of config somewhere.
Too bad the python app I work on right now uses some "Magic" :-/
On 11 September 2011 01:04, Raymond Barlow <rbarlow@raymanoz.com> wrote:

I +1 that!!

On 10 Sep 2011, at 23:07, Kevin Wright <kev.lee.wright@gmail.com> wrote:

No... No it wouldn't.
Adding Spring to our nice pristine scala projects is distinctly *not* cool!

On 10 September 2011 22:35, Ross Rose <rossrose69@gmail.com> wrote:

Be cool to see an IoC container like Spring do function injection based on pattern matching.

Billy

On Sep 10, 2011, at 15:33, Tony Morris <tonymorris@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.
>
> Sorry, gotta correct you here. Web programming in pure functional
> environments is light years ahead of the rest in terms of ease. Second
> place is not even close.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOa8miAAoJEPxHMY3rBz0PYvUH/30bB2vC3SQiqW0ctozA7aJZ
> tXi3pBPjv0QkSq6Lcg9p4UAytfBBP2wpkWz1csDD7Ej+9PqcUvvhBvpx6XHa3Gei
> 688QbOpJlASk7SAzvSLgUUU9zyu9IsR5TjjrNEUfeePspvVxlJxBvkwXIydwgBV3
> qrLA/QhpVvd1rYz/Sy19Kv68nxFc5d3wcKUbywu/BpbuocTg3XeidPJWHGAjwcTO
> 1ffjZ7o8vDR+PYInlyCQxFUADuJxyFqDkeFKU1eNpHxnX8y8nLSbEy7v0+Ee8s6j
> jNVTbSDyLf5rdWr6dGDby7nvfcmyLk0uhWdQOcfpSBcHFq3kfMHR9IRzreGaX7k=
> =ea0W
> -----END PGP SIGNATURE-----

--
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

On 09/12/2011 03:38 PM, Adam Jorgensen wrote:
> If you like Spring then you like Spring.
>
> Personally, I find moving from coding in an actual language to wiring stuff up with XML config files pretty distasteful.
>
> I certainly appreciate the strengths of DI and so forth but Spring just seems to be another 10-ton gorilla that makes it
> painful like 1995.
>
> On 11 September 2011 08:10, Ittay Dror <ittay.dror@gmail.com > wrote:
>
> About Spring: I actually like it:
>
> * Being in XML means it is rigid, and thus your top-level services (API) must have a consistent form. I did a project using Spring Java Config and it turned out to be a mess. Spring-dm is a blessing compared to raw OSGI.
>
> * You can define services an any order you like. E.g., each new service declaration can appear at the end and yet injected in other beans. With any other language, you must push it at the right place. You can think of it as lazy symbol evaluation.
>
> * Bean post processing is very nice. E.g., configuration injection is with very little ceremony (${myproperty:defaultvalue})
>
> * Some other things not possible in other languages (template beans, the XxxAware interfaces, AOP, lookup methods)
>
> I kind of wish it would be typesafe and static (i.e., some sort of compilation phase)
>
> Ittay
>
> Adam Jorgensen wrote:
>> I +10 that. The first project I ever worked on professionally was an extant java web app wired up with
>> a whole lot of Spring and I've since developed a hatred of Spring-style "Magic" and other non-obvious
>> tricks.
>>
>> Which is not to say I like writing boilerplate, just that I don't like my code to behave strangely due to
>> some tiny bit of config somewhere.
>>
>> Too bad the python app I work on right now uses some "Magic" :-/
>>
>> On 11 September 2011 01:04, Raymond Barlow <rbarlow@raymanoz.com > wrote:
>>
>> I +1 that!!
>>
>>
>> On 10 Sep 2011, at 23:07, Kevin Wright <kev.lee.wright@gmail.com > wrote:
>>
>>> No... No it wouldn't.
>>>
>>> Adding Spring to our nice pristine scala projects is distinctly *not* cool!
>>>
>>>
>>> On 10 September 2011 22:35, Ross Rose <rossrose69@gmail.com > wrote:
>>>
>>> Be cool to see an IoC container like Spring do function injection based on pattern matching.
>>>
>>> Billy
>>>
>>> On Sep 10, 2011, at 15:33, Tony Morris <tonymorris@gmail.com > wrote:
>>>

On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>>>             >> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.

Sorry, gotta correct you here. Web programming in pure functional
environments is light years ahead of the rest in terms of ease. Second
place is not even close.

>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>

The problem with Spring/DI is that there is nothing in can do that cannot be done a bajazillion times more practically without Spring/DI. I think it is reasonable, perhaps even obligatory, to detest such gross inferiority.

--
Tony Morris
http://tmorris.net/

The problem with Spring/DI is that there is nothing in can do that cannot be done a bajazillion times more practically without Spring/DI. I think it is reasonable, perhaps even obligatory, to detest such gross inferiority.

--
Tony Morris
http://tmorris.net/

Speaking strictly about DI as a design pattern, if one had a clean slate to generate a practical solution to my domain problem, how would that look in scala with the constraints I have mentioned? As an exercise to investigate this matter, I have started porting the DI portions of the Spring framework to pure scala and will attempt to eliminate all deficiencies that concern people. I dub this project "Recoil". I will post a status update from time to time on my findings. Should the effort turn out a failure from a practical stance, then the matter would be settled. My goal is to transform the design into one of object-functional such that the result leverages scala's abilities.
Billy

Also, I would like to move this discussion to the scala-debate group
as it is off topic for the language group. If in the course of my
endeavor I stumble across matters which pertain to this group, I shall
post those concerns here.

Billy

On Sep 12, 5:55 am, Ross Rose wrote:
> > The problem with Spring/DI is that there is nothing in can do that cannot be done a bajazillion times more practically without Spring/DI. I think it is reasonable, perhaps even obligatory, to detest such gross inferiority.
>
> > --
> > Tony Morris
> >http://tmorris.net/
>
> Speaking strictly about DI as a design pattern, if one had a clean slate to generate a practical solution to my domain problem, how would that look in scala with the constraints I have mentioned? As an exercise to investigate this matter, I have started porting the DI portions of the Spring framework to pure scala and will attempt to eliminate all deficiencies that concern people. I dub this project "Recoil". I will post a status update from time to time on my findings. Should the effort turn out a failure from a practical stance, then the matter would be settled. My goal is to transform the design into one of object-functional such that the result leverages scala's abilities.
>
> Billy

Unsubscribe

On Sun, Sep 11, 2011 at 2:10 AM, Ittay Dror <ittay.dror@gmail.com> wrote:

About Spring: I actually like it:

* Being in XML means it is rigid, and thus your top-level services (API) must have a consistent form. I did a project using Spring Java Config and it turned out to be a mess. Spring-dm is a blessing compared to raw OSGI.

* You can define services an any order you like. E.g., each new service declaration can appear at the end and yet injected in other beans. With any other language, you must push it at the right place. You can think of it as lazy symbol evaluation.

* Bean post processing is very nice. E.g., configuration injection is with very little ceremony (${myproperty:defaultvalue})

* Some other things not possible in other languages (template beans, the XxxAware interfaces, AOP, lookup methods)

I kind of wish it would be typesafe and static (i.e., some sort of compilation phase)

Ittay

Adam Jorgensen wrote:

I +10 that. The first project I ever worked on professionally was an extant java web app wired up with a whole lot of Spring and I've since developed a hatred of Spring-style "Magic" and other non-obvious tricks.
Which is not to say I like writing boilerplate, just that I don't like my code to behave strangely due to some tiny bit of config somewhere.
Too bad the python app I work on right now uses some "Magic" :-/
On 11 September 2011 01:04, Raymond Barlow <rbarlow@raymanoz.com> wrote:

I +1 that!!

On 10 Sep 2011, at 23:07, Kevin Wright <kev.lee.wright@gmail.com> wrote:

No... No it wouldn't.
Adding Spring to our nice pristine scala projects is distinctly *not* cool!

On 10 September 2011 22:35, Ross Rose <rossrose69@gmail.com> wrote:

Be cool to see an IoC container like Spring do function injection based on pattern matching.

Billy

On Sep 10, 2011, at 15:33, Tony Morris <tonymorris@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.
>
> Sorry, gotta correct you here. Web programming in pure functional
> environments is light years ahead of the rest in terms of ease. Second
> place is not even close.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOa8miAAoJEPxHMY3rBz0PYvUH/30bB2vC3SQiqW0ctozA7aJZ
> tXi3pBPjv0QkSq6Lcg9p4UAytfBBP2wpkWz1csDD7Ej+9PqcUvvhBvpx6XHa3Gei
> 688QbOpJlASk7SAzvSLgUUU9zyu9IsR5TjjrNEUfeePspvVxlJxBvkwXIydwgBV3
> qrLA/QhpVvd1rYz/Sy19Kv68nxFc5d3wcKUbywu/BpbuocTg3XeidPJWHGAjwcTO
> 1ffjZ7o8vDR+PYInlyCQxFUADuJxyFqDkeFKU1eNpHxnX8y8nLSbEy7v0+Ee8s6j
> jNVTbSDyLf5rdWr6dGDby7nvfcmyLk0uhWdQOcfpSBcHFq3kfMHR9IRzreGaX7k=
> =ea0W
> -----END PGP SIGNATURE-----

--
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

Greetings,

I'm actually on a IoC container called "Sindi" and I tried to enforce application context configuration thru code using a DSL for binding.

It actually look a bit like a mix between guice/spring with a functional flavour, you can view a full example here:
https://github.com/aloiscochard/sindi/tree/master/sindi-examples/demo

Sindi is totally type-safe, and even better... bindings resolution is checked at compile time!

Sindi contain a "processor" system aim for doing what Spring did with bean processing (actually it's used to support Option/Either).

I want to keep Sindi simple and a core IoC component. But I'll start soon an other framework on top of it called "Sinap" where I want to add:
- Easy configuration management (and linking to bindings of course)
- Service infrastructure (i.e. lifecycle managament, automatic-proxy)
- Any ceremony you think it could be useful ?
- ...

In a nutshell I want a good toolbox to design application and make them configurable without the pain I had sometimes with Spring.

Would really like some feedback/ideas/comments, because it looks like some of you could be really interested by what I'm actually implementing.

Alois Cochard


On 11 September 2011 08:10, Ittay Dror <ittay.dror@gmail.com> wrote:

About Spring: I actually like it:

* Being in XML means it is rigid, and thus your top-level services (API) must have a consistent form. I did a project using Spring Java Config and it turned out to be a mess. Spring-dm is a blessing compared to raw OSGI.

* You can define services an any order you like. E.g., each new service declaration can appear at the end and yet injected in other beans. With any other language, you must push it at the right place. You can think of it as lazy symbol evaluation.

* Bean post processing is very nice. E.g., configuration injection is with very little ceremony (${myproperty:defaultvalue})

* Some other things not possible in other languages (template beans, the XxxAware interfaces, AOP, lookup methods)

I kind of wish it would be typesafe and static (i.e., some sort of compilation phase)

Ittay

Adam Jorgensen wrote:

I +10 that. The first project I ever worked on professionally was an extant java web app wired up with a whole lot of Spring and I've since developed a hatred of Spring-style "Magic" and other non-obvious tricks.
Which is not to say I like writing boilerplate, just that I don't like my code to behave strangely due to some tiny bit of config somewhere.
Too bad the python app I work on right now uses some "Magic" :-/
On 11 September 2011 01:04, Raymond Barlow <rbarlow@raymanoz.com> wrote:

I +1 that!!

On 10 Sep 2011, at 23:07, Kevin Wright <kev.lee.wright@gmail.com> wrote:

No... No it wouldn't.
Adding Spring to our nice pristine scala projects is distinctly *not* cool!

On 10 September 2011 22:35, Ross Rose <rossrose69@gmail.com> wrote:

Be cool to see an IoC container like Spring do function injection based on pattern matching.

Billy

On Sep 10, 2011, at 15:33, Tony Morris <tonymorris@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/11/2011 02:20 AM, Giovanni Giorgi wrote:
>> Too pure language are nice, but they fail to get mainstream consensus, and different stuff like web framework are more difficult to write with too-pure language.
>
> Sorry, gotta correct you here. Web programming in pure functional
> environments is light years ahead of the rest in terms of ease. Second
> place is not even close.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOa8miAAoJEPxHMY3rBz0PYvUH/30bB2vC3SQiqW0ctozA7aJZ
> tXi3pBPjv0QkSq6Lcg9p4UAytfBBP2wpkWz1csDD7Ej+9PqcUvvhBvpx6XHa3Gei
> 688QbOpJlASk7SAzvSLgUUU9zyu9IsR5TjjrNEUfeePspvVxlJxBvkwXIydwgBV3
> qrLA/QhpVvd1rYz/Sy19Kv68nxFc5d3wcKUbywu/BpbuocTg3XeidPJWHGAjwcTO
> 1ffjZ7o8vDR+PYInlyCQxFUADuJxyFqDkeFKU1eNpHxnX8y8nLSbEy7v0+Ee8s6j
> jNVTbSDyLf5rdWr6dGDby7nvfcmyLk0uhWdQOcfpSBcHFq3kfMHR9IRzreGaX7k=
> =ea0W
> -----END PGP SIGNATURE-----

--
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

--
Alois Cochardhttp://aloiscochard.blogspot.comhttp://twitter.com/aloiscochard