This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Complexity Analogy: Graphical User Interfaces

30 replies
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Analogies and Metaphors can be dicey because it is often easy to poke holes in them, but I'll proceed anyway.

I first learned to program in 1970 using BASIC with optical mark cards. I would write my program on the cards, put them in the card reader, push the start button, and the output would appear on a line-printer. The complexity of this was extremely low, as was the productivity.

Until 1981 all my programs had a command line user interface. The complexity of writing the UI code was also quite low, as was the productivity of the user. On the other hand the complexity to the user was enormously high - if you did not have decent documentation you were almost completely hosed, and there were so few decent standards in UI design it was a nightmare for the user.

After finishing my undergraduate degree, my first job, first project, was to rewrite the Operator Console for the Michigan Terminal System. Rather than a command line interface this was a 'full screen' application using a newly developed API we called the 'Screen Support Routines' which abstracted a standard UI onto various devices such as IBM 3270 and generic ASCII terminals. This was analogous to the Unix Curses API, but quite different in design. While the basic API was quite simple, designing and implementing a UI was much more complex than a command line UI as there were so many more considerations to deal with. In the end though, while the complexity was high for me (the developer) the complexity for the computer operators was low, and the flexibility was high because they could now use a variety of different terminals instead of only the old IBM 370 console. Basically the complexity was high but so was the value.

When the Macintosh first came out I soon tried my hand at writing an application using the Quick Draw API. Again, the complexity of the API and application was even higher than before, but the value of the resulting application was also higher.

If we consider programming languages and plot complexity against value (productivity) we might have something that looks like:

         Java                         Scala
(low complexity, high value) (high complexity, high value)

         BASIC                         C++
(low complexity, low value)  (high complexity, low value)

Please, no religious comments, these are gross example to express a point. If we simply accept the fact that Scala is complex (for many people), then if we want more people to use it we need to market the value (productivity). I am appealing to everyone who argues Scala is not complex to realize, you are not the consumer we are marketing to, we are marketing to the consumers who believe Scala is complex.

Going back to UI APIs.. writing those early Macintosh applications was a bitch, there was so much raw complexity. Looking at modern GUI platforms like Swing, WPF, or Java FX (using FX Script or now Scala), the actual complexity is quite fierce compared to the original Macintosh, but most of that complexity is far removed from the designer/developer because we have simply learned how to architect better APIs, and the rest of the complexity is tolerable because the overall education and culture of developers is better wrt GUI design/implementation.

I would conclude that if you really want more people to adopt Scala then some things that would help are:
  1. Accept/Admit that Scala is complex, but improve the marketing of the overall value (productivity). Automobiles are way more complex than bicycles, yet more people still use automobiles.
  2. Continue to remove the developer from the complexity with things like better IDE support and better integration with existing tools, improved APIs, improved language features, etc.
  3. Continue to improve the educational and cultural experience for new developers
Already I see a new discussion on "Actual complexity in Scala that warrants simplification" that seems to address (2). From my perspective there is no silver bullet for getting people to adopt Scala, it will simply take time; continuing enthusiasm, advocacy and marketing savvy; and dedication to continuous improvements to the 'developer experience'

Cheers, Eric
Adam Jorgensen
Joined: 2011-04-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces

Nice analogy.

Off topic question:

Where do you see languages like Ruby and Python fitting into the diagram?

On 16 November 2011 03:41, Eric Kolotyluk wrote:
> Analogies and Metaphors can be dicey because it is often easy to poke holes
> in them, but I'll proceed anyway.
>
> I first learned to program in 1970 using BASIC with optical mark cards. I
> would write my program on the cards, put them in the card reader, push the
> start button, and the output would appear on a line-printer. The complexity
> of this was extremely low, as was the productivity.
>
> Until 1981 all my programs had a command line user interface. The complexity
> of writing the UI code was also quite low, as was the productivity of the
> user. On the other hand the complexity to the user was enormously high - if
> you did not have decent documentation you were almost completely hosed, and
> there were so few decent standards in UI design it was a nightmare for the
> user.
>
> After finishing my undergraduate degree, my first job, first project, was to
> rewrite the Operator Console for the Michigan Terminal System. Rather than a
> command line interface this was a 'full screen' application using a newly
> developed API we called the 'Screen Support Routines' which abstracted a
> standard UI onto various devices such as IBM 3270 and generic ASCII
> terminals. This was analogous to the Unix Curses API, but quite different in
> design. While the basic API was quite simple, designing and implementing a
> UI was much more complex than a command line UI as there were so many more
> considerations to deal with. In the end though, while the complexity was
> high for me (the developer) the complexity for the computer operators was
> low, and the flexibility was high because they could now use a variety of
> different terminals instead of only the old IBM 370 console. Basically the
> complexity was high but so was the value.
>
> When the Macintosh first came out I soon tried my hand at writing an
> application using the Quick Draw API. Again, the complexity of the API and
> application was even higher than before, but the value of the resulting
> application was also higher.
>
> If we consider programming languages and plot complexity against value
> (productivity) we might have something that looks like:
>
>          Java                         Scala
> (low complexity, high value) (high complexity, high value)
>
>          BASIC                         C++
> (low complexity, low value)  (high complexity, low value)
>
> Please, no religious comments, these are gross example to express a point.
> If we simply accept the fact that Scala is complex (for many people), then
> if we want more people to use it we need to market the value (productivity).
> I am appealing to everyone who argues Scala is not complex to realize, you
> are not the consumer we are marketing to, we are marketing to the consumers
> who believe Scala is complex.
>
> Going back to UI APIs.. writing those early Macintosh applications was a
> bitch, there was so much raw complexity. Looking at modern GUI platforms
> like Swing, WPF, or Java FX (using FX Script or now Scala), the actual
> complexity is quite fierce compared to the original Macintosh, but most of
> that complexity is far removed from the designer/developer because we have
> simply learned how to architect better APIs, and the rest of the complexity
> is tolerable because the overall education and culture of developers is
> better wrt GUI design/implementation.
>
> I would conclude that if you really want more people to adopt Scala then
> some things that would help are:
>
> Accept/Admit that Scala is complex, but improve the marketing of the overall
> value (productivity). Automobiles are way more complex than bicycles, yet
> more people still use automobiles.
> Continue to remove the developer from the complexity with things like better
> IDE support and better integration with existing tools, improved APIs,
> improved language features, etc.
> Continue to improve the educational and cultural experience for new
> developers
>
> Already I see a new discussion on "Actual complexity in Scala that warrants
> simplification" that seems to address (2). From my perspective there is no
> silver bullet for getting people to adopt Scala, it will simply take time;
> continuing enthusiasm, advocacy and marketing savvy; and dedication to
> continuous improvements to the 'developer experience'
>
> Cheers, Eric
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces
The very idea that Java is less complex than Scala is ridiculous, perpetuated only by people who know neither Java nor Scala. Too bad for them, but why should you further entertain the silliness with "gross metaphors"?

This discussion originated from the proposed question of how to make scala more popular in typical programming environments. Have you guys worked this out yet? Would you like some hints? It's really way easier than it is being made out to be.



On 11/16/2011 11:41 AM, Eric Kolotyluk wrote:
4EC314DC [dot] 3000702 [at] gmail [dot] com" type="cite"> Analogies and Metaphors can be dicey because it is often easy to poke holes in them, but I'll proceed anyway.

I first learned to program in 1970 using BASIC with optical mark cards. I would write my program on the cards, put them in the card reader, push the start button, and the output would appear on a line-printer. The complexity of this was extremely low, as was the productivity.

Until 1981 all my programs had a command line user interface. The complexity of writing the UI code was also quite low, as was the productivity of the user. On the other hand the complexity to the user was enormously high - if you did not have decent documentation you were almost completely hosed, and there were so few decent standards in UI design it was a nightmare for the user.

After finishing my undergraduate degree, my first job, first project, was to rewrite the Operator Console for the Michigan Terminal System. Rather than a command line interface this was a 'full screen' application using a newly developed API we called the 'Screen Support Routines' which abstracted a standard UI onto various devices such as IBM 3270 and generic ASCII terminals. This was analogous to the Unix Curses API, but quite different in design. While the basic API was quite simple, designing and implementing a UI was much more complex than a command line UI as there were so many more considerations to deal with. In the end though, while the complexity was high for me (the developer) the complexity for the computer operators was low, and the flexibility was high because they could now use a variety of different terminals instead of only the old IBM 370 console. Basically the complexity was high but so was the value.

When the Macintosh first came out I soon tried my hand at writing an application using the Quick Draw API. Again, the complexity of the API and application was even higher than before, but the value of the resulting application was also higher.

If we consider programming languages and plot complexity against value (productivity) we might have something that looks like:

         Java                         Scala
(low complexity, high value) (high complexity, high value)

         BASIC                         C++
(low complexity, low value)  (high complexity, low value)

Please, no religious comments, these are gross example to express a point. If we simply accept the fact that Scala is complex (for many people), then if we want more people to use it we need to market the value (productivity). I am appealing to everyone who argues Scala is not complex to realize, you are not the consumer we are marketing to, we are marketing to the consumers who believe Scala is complex.

Going back to UI APIs.. writing those early Macintosh applications was a bitch, there was so much raw complexity. Looking at modern GUI platforms like Swing, WPF, or Java FX (using FX Script or now Scala), the actual complexity is quite fierce compared to the original Macintosh, but most of that complexity is far removed from the designer/developer because we have simply learned how to architect better APIs, and the rest of the complexity is tolerable because the overall education and culture of developers is better wrt GUI design/implementation.

I would conclude that if you really want more people to adopt Scala then some things that would help are:
  1. Accept/Admit that Scala is complex, but improve the marketing of the overall value (productivity). Automobiles are way more complex than bicycles, yet more people still use automobiles.
  2. Continue to remove the developer from the complexity with things like better IDE support and better integration with existing tools, improved APIs, improved language features, etc.
  3. Continue to improve the educational and cultural experience for new developers
Already I see a new discussion on "Actual complexity in Scala that warrants simplification" that seems to address (2). From my perspective there is no silver bullet for getting people to adopt Scala, it will simply take time; continuing enthusiasm, advocacy and marketing savvy; and dedication to continuous improvements to the 'developer experience'

Cheers, Eric


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

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces

Thanks.

I would see Ruby fitting in on the top shelf with Java with Groovy. I am
not sure whether they are to the right or left of Java. I am more
familiar with Groovy and to me it just feels like a better Java,
possibly less complex. I am less familiar with Python, but suspect it is
somewhere near Java too.

For people looking at BASIC, I mean the BASIC I learned in 1970, not
today's Visual Basic which is closer to C++.

Also, my diagram is crude, otherwise it would also show Scala as higher
value than Java.

Cheers, Eric

On 2011-11-15 10:14 PM, Adam Jorgensen wrote:
> Nice analogy.
>
> Off topic question:
>
> Where do you see languages like Ruby and Python fitting into the diagram?
>
>
> On 16 November 2011 03:41, Eric Kolotyluk wrote:
>> Analogies and Metaphors can be dicey because it is often easy to poke holes
>> in them, but I'll proceed anyway.
>>
>> I first learned to program in 1970 using BASIC with optical mark cards. I
>> would write my program on the cards, put them in the card reader, push the
>> start button, and the output would appear on a line-printer. The complexity
>> of this was extremely low, as was the productivity.
>>
>> Until 1981 all my programs had a command line user interface. The complexity
>> of writing the UI code was also quite low, as was the productivity of the
>> user. On the other hand the complexity to the user was enormously high - if
>> you did not have decent documentation you were almost completely hosed, and
>> there were so few decent standards in UI design it was a nightmare for the
>> user.
>>
>> After finishing my undergraduate degree, my first job, first project, was to
>> rewrite the Operator Console for the Michigan Terminal System. Rather than a
>> command line interface this was a 'full screen' application using a newly
>> developed API we called the 'Screen Support Routines' which abstracted a
>> standard UI onto various devices such as IBM 3270 and generic ASCII
>> terminals. This was analogous to the Unix Curses API, but quite different in
>> design. While the basic API was quite simple, designing and implementing a
>> UI was much more complex than a command line UI as there were so many more
>> considerations to deal with. In the end though, while the complexity was
>> high for me (the developer) the complexity for the computer operators was
>> low, and the flexibility was high because they could now use a variety of
>> different terminals instead of only the old IBM 370 console. Basically the
>> complexity was high but so was the value.
>>
>> When the Macintosh first came out I soon tried my hand at writing an
>> application using the Quick Draw API. Again, the complexity of the API and
>> application was even higher than before, but the value of the resulting
>> application was also higher.
>>
>> If we consider programming languages and plot complexity against value
>> (productivity) we might have something that looks like:
>>
>> Java Scala
>> (low complexity, high value) (high complexity, high value)
>>
>> BASIC C++
>> (low complexity, low value) (high complexity, low value)
>>
>> Please, no religious comments, these are gross example to express a point.
>> If we simply accept the fact that Scala is complex (for many people), then
>> if we want more people to use it we need to market the value (productivity).
>> I am appealing to everyone who argues Scala is not complex to realize, you
>> are not the consumer we are marketing to, we are marketing to the consumers
>> who believe Scala is complex.
>>
>> Going back to UI APIs.. writing those early Macintosh applications was a
>> bitch, there was so much raw complexity. Looking at modern GUI platforms
>> like Swing, WPF, or Java FX (using FX Script or now Scala), the actual
>> complexity is quite fierce compared to the original Macintosh, but most of
>> that complexity is far removed from the designer/developer because we have
>> simply learned how to architect better APIs, and the rest of the complexity
>> is tolerable because the overall education and culture of developers is
>> better wrt GUI design/implementation.
>>
>> I would conclude that if you really want more people to adopt Scala then
>> some things that would help are:
>>
>> Accept/Admit that Scala is complex, but improve the marketing of the overall
>> value (productivity). Automobiles are way more complex than bicycles, yet
>> more people still use automobiles.
>> Continue to remove the developer from the complexity with things like better
>> IDE support and better integration with existing tools, improved APIs,
>> improved language features, etc.
>> Continue to improve the educational and cultural experience for new
>> developers
>>
>> Already I see a new discussion on "Actual complexity in Scala that warrants
>> simplification" that seems to address (2). From my perspective there is no
>> silver bullet for getting people to adopt Scala, it will simply take time;
>> continuing enthusiasm, advocacy and marketing savvy; and dedication to
>> continuous improvements to the 'developer experience'
>>
>> Cheers, Eric
>>

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces
This kind of response is a good example of what I would consider is one of the problems with Scala...

On 2011-11-15 10:22 PM, Tony Morris wrote:
4EC3569E [dot] 4040309 [at] gmail [dot] com" type="cite"> The very idea that Java is less complex than Scala is ridiculous, perpetuated only by people who know neither Java nor Scala. Too bad for them, but why should you further entertain the silliness with "gross metaphors"?

Here we see an example of an author desperately trying to invalidate someone's point of view. First of all, they seem to be talking in black and white (inflexible) terms here, using hyperbole, and immediately dismissing the possibility that other people may find Scala more complex than Java. Second of all they seem to make it personal by viewing people who do not agree with their reality as 'perpetrators' and casting them as not knowing the subject they are talking about. Finally they seem to use a condescending tone by classifying someone else's ideas as 'silliness.'

You may want to check out http://www.mentalhelp.net/poc/view_doc.php?type=doc&id=440&cn=8 for a deeper analysis of these kinds of remarks and how it affects the people the remarks are aimed at.

The point I am trying to make here is (3) Continue to improve the educational and cultural experience for new developers. Negative kinds of responses make it more difficult for people (newbies in particular) to feel safe or comfortable working with the larger community and culture of Scala experts. It is difficult and frustrating to deal with people who assume you do not know what you are talking about by dismissing your ideas as 'ridiculous' and 'silliness'. People naturally feel more motivated to consider Scala and ideas about Scala when they feel the culture and community is safe and supportive.

4EC3569E [dot] 4040309 [at] gmail [dot] com" type="cite">
This discussion originated from the proposed question of how to make scala more popular in typical programming environments. Have you guys worked this out yet? Would you like some hints? It's really way easier than it is being made out to be.


Here we see the author appears to have a good understanding of the real underlying issue, but then resorting to what seems like taunting. It seems like the author is cognizant on one level, but possibly malevolent on some other level. We all encounter people smarter than us and it is great to work with them, unless you cannot trust them to treat you with respect and understanding. Again, this goes back to culture and community and the need for people to feel safe and supported in their educational experience.

One of the things I really admire about Martin Odersky is that he is clearly very smart and vastly more expert in his domain than I am. Yet I feel safe and I trust what he has to say because when necessary he can speak to Scala newbies in a way that is not (too) confusing or overly complicated, yet he is also able to soar with the eagles while the rest of us are still testing our wings on the ground. Martin is not alone, there are many other bright and compassionate people who make it motivating to learn more about Scala and embrace the kinds of innovation it represents. These voices should sing the loudest.

4EC3569E [dot] 4040309 [at] gmail [dot] com" type="cite">

On 11/16/2011 11:41 AM, Eric Kolotyluk wrote:
4EC314DC [dot] 3000702 [at] gmail [dot] com" type="cite"> Analogies and Metaphors can be dicey because it is often easy to poke holes in them, but I'll proceed anyway.

I first learned to program in 1970 using BASIC with optical mark cards. I would write my program on the cards, put them in the card reader, push the start button, and the output would appear on a line-printer. The complexity of this was extremely low, as was the productivity.

Until 1981 all my programs had a command line user interface. The complexity of writing the UI code was also quite low, as was the productivity of the user. On the other hand the complexity to the user was enormously high - if you did not have decent documentation you were almost completely hosed, and there were so few decent standards in UI design it was a nightmare for the user.

After finishing my undergraduate degree, my first job, first project, was to rewrite the Operator Console for the Michigan Terminal System. Rather than a command line interface this was a 'full screen' application using a newly developed API we called the 'Screen Support Routines' which abstracted a standard UI onto various devices such as IBM 3270 and generic ASCII terminals. This was analogous to the Unix Curses API, but quite different in design. While the basic API was quite simple, designing and implementing a UI was much more complex than a command line UI as there were so many more considerations to deal with. In the end though, while the complexity was high for me (the developer) the complexity for the computer operators was low, and the flexibility was high because they could now use a variety of different terminals instead of only the old IBM 370 console. Basically the complexity was high but so was the value.

When the Macintosh first came out I soon tried my hand at writing an application using the Quick Draw API. Again, the complexity of the API and application was even higher than before, but the value of the resulting application was also higher.

If we consider programming languages and plot complexity against value (productivity) we might have something that looks like:

         Java                         Scala
(low complexity, high value) (high complexity, high value)

         BASIC                         C++
(low complexity, low value)  (high complexity, low value)

Please, no religious comments, these are gross example to express a point. If we simply accept the fact that Scala is complex (for many people), then if we want more people to use it we need to market the value (productivity). I am appealing to everyone who argues Scala is not complex to realize, you are not the consumer we are marketing to, we are marketing to the consumers who believe Scala is complex.

Going back to UI APIs.. writing those early Macintosh applications was a bitch, there was so much raw complexity. Looking at modern GUI platforms like Swing, WPF, or Java FX (using FX Script or now Scala), the actual complexity is quite fierce compared to the original Macintosh, but most of that complexity is far removed from the designer/developer because we have simply learned how to architect better APIs, and the rest of the complexity is tolerable because the overall education and culture of developers is better wrt GUI design/implementation.

I would conclude that if you really want more people to adopt Scala then some things that would help are:
  1. Accept/Admit that Scala is complex, but improve the marketing of the overall value (productivity). Automobiles are way more complex than bicycles, yet more people still use automobiles.
  2. Continue to remove the developer from the complexity with things like better IDE support and better integration with existing tools, improved APIs, improved language features, etc.
  3. Continue to improve the educational and cultural experience for new developers
Already I see a new discussion on "Actual complexity in Scala that warrants simplification" that seems to address (2). From my perspective there is no silver bullet for getting people to adopt Scala, it will simply take time; continuing enthusiasm, advocacy and marketing savvy; and dedication to continuous improvements to the 'developer experience'

Cheers, Eric


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

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces

When C++ first started out and I started using it, it did seem like a
better C at the time. It was more often the case that once my code
compiled it would work correctly at run-time.

Over time I stopped using C++ for a while, then tried to come back to
it. The language was so much more complex than C with many subtle
features that were hard to remember, it was such a frustrating
experience I tended to fall back to plain old C because at least I could
write code without having to pull the textbook off the shelf constantly.

My more recent experiences with ATL and COM, Hungarian Notation, Smart
Pointers, and the other abuses C++ has suffered at the hands of
Microsoft has devalued C++ by making it too complex but not adding
significant enough new value.

To answer your question I would tend to say the ecosystem of Java bring
equal value (or more) compared to C++ ecosystem, but far less
complexity. That is, the net value of Java is higher in my opinion.

Java, the language, lies between C and C++ in overall complexity, but I
find I can be just as expressive in Java as I can be in C++. There are
too many feature in C++ that just don't offer enough value and are too
often only useful in niche areas.

The bottom line for me is that I am vastly more productive in the Java
language and ecosystem than say the C++ language and Microsoft
ecosystem. I also feel that it is possible to be more productive with
C++ in say a Gnu ecosystem, but I still prefer Java - especially since I
have encountered Maven.

Sorry for the long and windy answer ;-)

Cheers, Eric

On 2011-11-16 5:17 AM, Razvan Cojocaru wrote:
> Just curious here: Why do you think Java brings more value than C++? Is it because of its ecosystem or is it intrinsic to the language?
>
> Thanks,
> Razvan
>
> On 2011-11-16, at 8:03 AM, Eric Kolotyluk wrote:
>
>> Thanks.
>>
>> I would see Ruby fitting in on the top shelf with Java with Groovy. I am not sure whether they are to the right or left of Java. I am more familiar with Groovy and to me it just feels like a better Java, possibly less complex. I am less familiar with Python, but suspect it is somewhere near Java too.
>>
>> For people looking at BASIC, I mean the BASIC I learned in 1970, not today's Visual Basic which is closer to C++.
>>
>> Also, my diagram is crude, otherwise it would also show Scala as higher value than Java.
>>
>> Cheers, Eric
>>
>> On 2011-11-15 10:14 PM, Adam Jorgensen wrote:
>>> Nice analogy.
>>>
>>> Off topic question:
>>>
>>> Where do you see languages like Ruby and Python fitting into the diagram?
>>>
>>>
>>> On 16 November 2011 03:41, Eric Kolotyluk wrote:
>>>> Analogies and Metaphors can be dicey because it is often easy to poke holes
>>>> in them, but I'll proceed anyway.
>>>>
>>>> I first learned to program in 1970 using BASIC with optical mark cards. I
>>>> would write my program on the cards, put them in the card reader, push the
>>>> start button, and the output would appear on a line-printer. The complexity
>>>> of this was extremely low, as was the productivity.
>>>>
>>>> Until 1981 all my programs had a command line user interface. The complexity
>>>> of writing the UI code was also quite low, as was the productivity of the
>>>> user. On the other hand the complexity to the user was enormously high - if
>>>> you did not have decent documentation you were almost completely hosed, and
>>>> there were so few decent standards in UI design it was a nightmare for the
>>>> user.
>>>>
>>>> After finishing my undergraduate degree, my first job, first project, was to
>>>> rewrite the Operator Console for the Michigan Terminal System. Rather than a
>>>> command line interface this was a 'full screen' application using a newly
>>>> developed API we called the 'Screen Support Routines' which abstracted a
>>>> standard UI onto various devices such as IBM 3270 and generic ASCII
>>>> terminals. This was analogous to the Unix Curses API, but quite different in
>>>> design. While the basic API was quite simple, designing and implementing a
>>>> UI was much more complex than a command line UI as there were so many more
>>>> considerations to deal with. In the end though, while the complexity was
>>>> high for me (the developer) the complexity for the computer operators was
>>>> low, and the flexibility was high because they could now use a variety of
>>>> different terminals instead of only the old IBM 370 console. Basically the
>>>> complexity was high but so was the value.
>>>>
>>>> When the Macintosh first came out I soon tried my hand at writing an
>>>> application using the Quick Draw API. Again, the complexity of the API and
>>>> application was even higher than before, but the value of the resulting
>>>> application was also higher.
>>>>
>>>> If we consider programming languages and plot complexity against value
>>>> (productivity) we might have something that looks like:
>>>>
>>>> Java Scala
>>>> (low complexity, high value) (high complexity, high value)
>>>>
>>>> BASIC C++
>>>> (low complexity, low value) (high complexity, low value)
>>>>
>>>> Please, no religious comments, these are gross example to express a point.
>>>> If we simply accept the fact that Scala is complex (for many people), then
>>>> if we want more people to use it we need to market the value (productivity).
>>>> I am appealing to everyone who argues Scala is not complex to realize, you
>>>> are not the consumer we are marketing to, we are marketing to the consumers
>>>> who believe Scala is complex.
>>>>
>>>> Going back to UI APIs.. writing those early Macintosh applications was a
>>>> bitch, there was so much raw complexity. Looking at modern GUI platforms
>>>> like Swing, WPF, or Java FX (using FX Script or now Scala), the actual
>>>> complexity is quite fierce compared to the original Macintosh, but most of
>>>> that complexity is far removed from the designer/developer because we have
>>>> simply learned how to architect better APIs, and the rest of the complexity
>>>> is tolerable because the overall education and culture of developers is
>>>> better wrt GUI design/implementation.
>>>>
>>>> I would conclude that if you really want more people to adopt Scala then
>>>> some things that would help are:
>>>>
>>>> Accept/Admit that Scala is complex, but improve the marketing of the overall
>>>> value (productivity). Automobiles are way more complex than bicycles, yet
>>>> more people still use automobiles.
>>>> Continue to remove the developer from the complexity with things like better
>>>> IDE support and better integration with existing tools, improved APIs,
>>>> improved language features, etc.
>>>> Continue to improve the educational and cultural experience for new
>>>> developers
>>>>
>>>> Already I see a new discussion on "Actual complexity in Scala that warrants
>>>> simplification" that seems to address (2). From my perspective there is no
>>>> silver bullet for getting people to adopt Scala, it will simply take time;
>>>> continuing enthusiasm, advocacy and marketing savvy; and dedication to
>>>> continuous improvements to the 'developer experience'
>>>>
>>>> Cheers, Eric
>>>>

Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
RE: Complexity Analogy: Graphical User Interfaces

That's fair.

Not looking for an argument and speaking strictly for myself - I've always
enjoyed the multitude of tools and paradigms in C++, never had a serious
issue with using it for over 15 years and never really found comfort in the
limited toolbox that is Java. I guess I am of the kind that writes a
multi-threaded web server from scratch just for sport, if I don't find one I
like :)

... missing the extensive open-source library support, or even stuff like
the middleware servers/containers with JTA/JMS/RMI, that Java has enabled -
is not something that would phase me out - in fact, having to (re)write some
of that myself would make life more interesting, not less :)

Heh - imagine how happy I am that scala came along :)

Anyways - sorry for the side-tracking here...

P.S. - can't help it - got to throw a wrench in this: restarting a C++
executable was less than 5 seconds while re-deploying the equivalent Java
EAR file, on WL, still takes about 10 MINUTES on a T2K :)

-----Original Message-----
From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com]
On Behalf Of Eric Kolotyluk
Sent: November-16-11 9:25 AM
To: scala-debate
Subject: Re: [scala-debate] Complexity Analogy: Graphical User Interfaces

When C++ first started out and I started using it, it did seem like a better
C at the time. It was more often the case that once my code compiled it
would work correctly at run-time.

Over time I stopped using C++ for a while, then tried to come back to it.
The language was so much more complex than C with many subtle features that
were hard to remember, it was such a frustrating experience I tended to fall
back to plain old C because at least I could write code without having to
pull the textbook off the shelf constantly.

My more recent experiences with ATL and COM, Hungarian Notation, Smart
Pointers, and the other abuses C++ has suffered at the hands of Microsoft
has devalued C++ by making it too complex but not adding significant enough
new value.

To answer your question I would tend to say the ecosystem of Java bring
equal value (or more) compared to C++ ecosystem, but far less complexity.
That is, the net value of Java is higher in my opinion.

Java, the language, lies between C and C++ in overall complexity, but I find
I can be just as expressive in Java as I can be in C++. There are too many
feature in C++ that just don't offer enough value and are too often only
useful in niche areas.

The bottom line for me is that I am vastly more productive in the Java
language and ecosystem than say the C++ language and Microsoft ecosystem. I
also feel that it is possible to be more productive with
C++ in say a Gnu ecosystem, but I still prefer Java - especially since I
have encountered Maven.

Sorry for the long and windy answer ;-)

Cheers, Eric

On 2011-11-16 5:17 AM, Razvan Cojocaru wrote:
> Just curious here: Why do you think Java brings more value than C++? Is it
because of its ecosystem or is it intrinsic to the language?
>
> Thanks,
> Razvan
>
> On 2011-11-16, at 8:03 AM, Eric Kolotyluk
wrote:
>
>> Thanks.
>>
>> I would see Ruby fitting in on the top shelf with Java with Groovy. I am
not sure whether they are to the right or left of Java. I am more familiar
with Groovy and to me it just feels like a better Java, possibly less
complex. I am less familiar with Python, but suspect it is somewhere near
Java too.
>>
>> For people looking at BASIC, I mean the BASIC I learned in 1970, not
today's Visual Basic which is closer to C++.
>>
>> Also, my diagram is crude, otherwise it would also show Scala as higher
value than Java.
>>
>> Cheers, Eric
>>
>> On 2011-11-15 10:14 PM, Adam Jorgensen wrote:
>>> Nice analogy.
>>>
>>> Off topic question:
>>>
>>> Where do you see languages like Ruby and Python fitting into the
diagram?
>>>
>>>
>>> On 16 November 2011 03:41, Eric Kolotyluk
wrote:
>>>> Analogies and Metaphors can be dicey because it is often easy to poke
holes
>>>> in them, but I'll proceed anyway.
>>>>
>>>> I first learned to program in 1970 using BASIC with optical mark cards.
I
>>>> would write my program on the cards, put them in the card reader, push
the
>>>> start button, and the output would appear on a line-printer. The
complexity
>>>> of this was extremely low, as was the productivity.
>>>>
>>>> Until 1981 all my programs had a command line user interface. The
complexity
>>>> of writing the UI code was also quite low, as was the productivity of
the
>>>> user. On the other hand the complexity to the user was enormously high
- if
>>>> you did not have decent documentation you were almost completely hosed,
and
>>>> there were so few decent standards in UI design it was a nightmare for
the
>>>> user.
>>>>
>>>> After finishing my undergraduate degree, my first job, first project,
was to
>>>> rewrite the Operator Console for the Michigan Terminal System. Rather
than a
>>>> command line interface this was a 'full screen' application using a
newly
>>>> developed API we called the 'Screen Support Routines' which abstracted
a
>>>> standard UI onto various devices such as IBM 3270 and generic ASCII
>>>> terminals. This was analogous to the Unix Curses API, but quite
different in
>>>> design. While the basic API was quite simple, designing and
implementing a
>>>> UI was much more complex than a command line UI as there were so many
more
>>>> considerations to deal with. In the end though, while the complexity
was
>>>> high for me (the developer) the complexity for the computer operators
was
>>>> low, and the flexibility was high because they could now use a variety
of
>>>> different terminals instead of only the old IBM 370 console. Basically
the
>>>> complexity was high but so was the value.
>>>>
>>>> When the Macintosh first came out I soon tried my hand at writing an
>>>> application using the Quick Draw API. Again, the complexity of the API
and
>>>> application was even higher than before, but the value of the resulting
>>>> application was also higher.
>>>>
>>>> If we consider programming languages and plot complexity against value
>>>> (productivity) we might have something that looks like:
>>>>
>>>> Java Scala
>>>> (low complexity, high value) (high complexity, high value)
>>>>
>>>> BASIC C++
>>>> (low complexity, low value) (high complexity, low value)
>>>>
>>>> Please, no religious comments, these are gross example to express a
point.
>>>> If we simply accept the fact that Scala is complex (for many people),
then
>>>> if we want more people to use it we need to market the value
(productivity).
>>>> I am appealing to everyone who argues Scala is not complex to realize,
you
>>>> are not the consumer we are marketing to, we are marketing to the
consumers
>>>> who believe Scala is complex.
>>>>
>>>> Going back to UI APIs.. writing those early Macintosh applications was
a
>>>> bitch, there was so much raw complexity. Looking at modern GUI
platforms
>>>> like Swing, WPF, or Java FX (using FX Script or now Scala), the actual
>>>> complexity is quite fierce compared to the original Macintosh, but most
of
>>>> that complexity is far removed from the designer/developer because we
have
>>>> simply learned how to architect better APIs, and the rest of the
complexity
>>>> is tolerable because the overall education and culture of developers is
>>>> better wrt GUI design/implementation.
>>>>
>>>> I would conclude that if you really want more people to adopt Scala
then
>>>> some things that would help are:
>>>>
>>>> Accept/Admit that Scala is complex, but improve the marketing of the
overall
>>>> value (productivity). Automobiles are way more complex than bicycles,
yet
>>>> more people still use automobiles.
>>>> Continue to remove the developer from the complexity with things like
better
>>>> IDE support and better integration with existing tools, improved APIs,
>>>> improved language features, etc.
>>>> Continue to improve the educational and cultural experience for new
>>>> developers
>>>>
>>>> Already I see a new discussion on "Actual complexity in Scala that
warrants
>>>> simplification" that seems to address (2). From my perspective there is
no
>>>> silver bullet for getting people to adopt Scala, it will simply take
time;
>>>> continuing enthusiasm, advocacy and marketing savvy; and dedication to
>>>> continuous improvements to the 'developer experience'
>>>>
>>>> Cheers, Eric
>>>>

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces

Thanks, I was not trying to debate languages per se, just use some
example people might relate to.

I remember in the old days I use to write/maintain C++ code; and
importing technologies and running Gnu CONFIGURE. It was amazing how
often something that complex actually worked! Now I am still trying to
get up-to-speed with Maven, and it's a bitch sometimes, but I really
prefer it to CONFIGURE, and there is an amazing amount of cool
open-source JVM based stuff out there. Maven Central and the myriad
other repositories out there have enormous value.

One day I was playing around with Eclipse and found an archetype for a
Scala project, and tried it. Holy cow - it worked great - and restored
my faith that some things can be easy and relatively simple.

lol - there are many things of value, and many people value things
differently - sometimes we even agree on the same things and the same
values.

Cheers, Eric

On 2011-11-16 10:32 AM, Razvan Cojocaru wrote:
> That's fair.
>
> Not looking for an argument and speaking strictly for myself - I've always
> enjoyed the multitude of tools and paradigms in C++, never had a serious
> issue with using it for over 15 years and never really found comfort in the
> limited toolbox that is Java. I guess I am of the kind that writes a
> multi-threaded web server from scratch just for sport, if I don't find one I
> like :)
>
> ... missing the extensive open-source library support, or even stuff like
> the middleware servers/containers with JTA/JMS/RMI, that Java has enabled -
> is not something that would phase me out - in fact, having to (re)write some
> of that myself would make life more interesting, not less :)
>
> Heh - imagine how happy I am that scala came along :)
>
> Anyways - sorry for the side-tracking here...
>
> P.S. - can't help it - got to throw a wrench in this: restarting a C++
> executable was less than 5 seconds while re-deploying the equivalent Java
> EAR file, on WL, still takes about 10 MINUTES on a T2K :)
>
> -----Original Message-----
> From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com]
> On Behalf Of Eric Kolotyluk
> Sent: November-16-11 9:25 AM
> To: scala-debate
> Subject: Re: [scala-debate] Complexity Analogy: Graphical User Interfaces
>
> When C++ first started out and I started using it, it did seem like a better
> C at the time. It was more often the case that once my code compiled it
> would work correctly at run-time.
>
> Over time I stopped using C++ for a while, then tried to come back to it.
> The language was so much more complex than C with many subtle features that
> were hard to remember, it was such a frustrating experience I tended to fall
> back to plain old C because at least I could write code without having to
> pull the textbook off the shelf constantly.
>
> My more recent experiences with ATL and COM, Hungarian Notation, Smart
> Pointers, and the other abuses C++ has suffered at the hands of Microsoft
> has devalued C++ by making it too complex but not adding significant enough
> new value.
>
> To answer your question I would tend to say the ecosystem of Java bring
> equal value (or more) compared to C++ ecosystem, but far less complexity.
> That is, the net value of Java is higher in my opinion.
>
> Java, the language, lies between C and C++ in overall complexity, but I find
> I can be just as expressive in Java as I can be in C++. There are too many
> feature in C++ that just don't offer enough value and are too often only
> useful in niche areas.
>
> The bottom line for me is that I am vastly more productive in the Java
> language and ecosystem than say the C++ language and Microsoft ecosystem. I
> also feel that it is possible to be more productive with
> C++ in say a Gnu ecosystem, but I still prefer Java - especially since I
> have encountered Maven.
>
> Sorry for the long and windy answer ;-)
>
> Cheers, Eric
>
> On 2011-11-16 5:17 AM, Razvan Cojocaru wrote:
>> Just curious here: Why do you think Java brings more value than C++? Is it
> because of its ecosystem or is it intrinsic to the language?
>> Thanks,
>> Razvan
>>
>> On 2011-11-16, at 8:03 AM, Eric Kolotyluk
> wrote:
>>> Thanks.
>>>
>>> I would see Ruby fitting in on the top shelf with Java with Groovy. I am
> not sure whether they are to the right or left of Java. I am more familiar
> with Groovy and to me it just feels like a better Java, possibly less
> complex. I am less familiar with Python, but suspect it is somewhere near
> Java too.
>>> For people looking at BASIC, I mean the BASIC I learned in 1970, not
> today's Visual Basic which is closer to C++.
>>> Also, my diagram is crude, otherwise it would also show Scala as higher
> value than Java.
>>> Cheers, Eric
>>>
>>> On 2011-11-15 10:14 PM, Adam Jorgensen wrote:
>>>> Nice analogy.
>>>>
>>>> Off topic question:
>>>>
>>>> Where do you see languages like Ruby and Python fitting into the
> diagram?
>>>>
>>>> On 16 November 2011 03:41, Eric Kolotyluk
> wrote:
>>>>> Analogies and Metaphors can be dicey because it is often easy to poke
> holes
>>>>> in them, but I'll proceed anyway.
>>>>>
>>>>> I first learned to program in 1970 using BASIC with optical mark cards.
> I
>>>>> would write my program on the cards, put them in the card reader, push
> the
>>>>> start button, and the output would appear on a line-printer. The
> complexity
>>>>> of this was extremely low, as was the productivity.
>>>>>
>>>>> Until 1981 all my programs had a command line user interface. The
> complexity
>>>>> of writing the UI code was also quite low, as was the productivity of
> the
>>>>> user. On the other hand the complexity to the user was enormously high
> - if
>>>>> you did not have decent documentation you were almost completely hosed,
> and
>>>>> there were so few decent standards in UI design it was a nightmare for
> the
>>>>> user.
>>>>>
>>>>> After finishing my undergraduate degree, my first job, first project,
> was to
>>>>> rewrite the Operator Console for the Michigan Terminal System. Rather
> than a
>>>>> command line interface this was a 'full screen' application using a
> newly
>>>>> developed API we called the 'Screen Support Routines' which abstracted
> a
>>>>> standard UI onto various devices such as IBM 3270 and generic ASCII
>>>>> terminals. This was analogous to the Unix Curses API, but quite
> different in
>>>>> design. While the basic API was quite simple, designing and
> implementing a
>>>>> UI was much more complex than a command line UI as there were so many
> more
>>>>> considerations to deal with. In the end though, while the complexity
> was
>>>>> high for me (the developer) the complexity for the computer operators
> was
>>>>> low, and the flexibility was high because they could now use a variety
> of
>>>>> different terminals instead of only the old IBM 370 console. Basically
> the
>>>>> complexity was high but so was the value.
>>>>>
>>>>> When the Macintosh first came out I soon tried my hand at writing an
>>>>> application using the Quick Draw API. Again, the complexity of the API
> and
>>>>> application was even higher than before, but the value of the resulting
>>>>> application was also higher.
>>>>>
>>>>> If we consider programming languages and plot complexity against value
>>>>> (productivity) we might have something that looks like:
>>>>>
>>>>> Java Scala
>>>>> (low complexity, high value) (high complexity, high value)
>>>>>
>>>>> BASIC C++
>>>>> (low complexity, low value) (high complexity, low value)
>>>>>
>>>>> Please, no religious comments, these are gross example to express a
> point.
>>>>> If we simply accept the fact that Scala is complex (for many people),
> then
>>>>> if we want more people to use it we need to market the value
> (productivity).
>>>>> I am appealing to everyone who argues Scala is not complex to realize,
> you
>>>>> are not the consumer we are marketing to, we are marketing to the
> consumers
>>>>> who believe Scala is complex.
>>>>>
>>>>> Going back to UI APIs.. writing those early Macintosh applications was
> a
>>>>> bitch, there was so much raw complexity. Looking at modern GUI
> platforms
>>>>> like Swing, WPF, or Java FX (using FX Script or now Scala), the actual
>>>>> complexity is quite fierce compared to the original Macintosh, but most
> of
>>>>> that complexity is far removed from the designer/developer because we
> have
>>>>> simply learned how to architect better APIs, and the rest of the
> complexity
>>>>> is tolerable because the overall education and culture of developers is
>>>>> better wrt GUI design/implementation.
>>>>>
>>>>> I would conclude that if you really want more people to adopt Scala
> then
>>>>> some things that would help are:
>>>>>
>>>>> Accept/Admit that Scala is complex, but improve the marketing of the
> overall
>>>>> value (productivity). Automobiles are way more complex than bicycles,
> yet
>>>>> more people still use automobiles.
>>>>> Continue to remove the developer from the complexity with things like
> better
>>>>> IDE support and better integration with existing tools, improved APIs,
>>>>> improved language features, etc.
>>>>> Continue to improve the educational and cultural experience for new
>>>>> developers
>>>>>
>>>>> Already I see a new discussion on "Actual complexity in Scala that
> warrants
>>>>> simplification" that seems to address (2). From my perspective there is
> no
>>>>> silver bullet for getting people to adopt Scala, it will simply take
> time;
>>>>> continuing enthusiasm, advocacy and marketing savvy; and dedication to
>>>>> continuous improvements to the 'developer experience'
>>>>>
>>>>> Cheers, Eric
>>>>>

tolsen77
Joined: 2008-10-08,
User offline. Last seen 1 year 38 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces
Not compared to orchestrating Javascript + HTML + CSS! I've toiled with my little project for some years now. It's part Scala, Javascript, and Actionscipt 3, and Scala, second to Javascript, has always been the easiest (and expressive) language to work in. Mind you, I did spend time learning the language properly, and avoided using advanced features I had no use for. For new users who want to learn it in one go, forget it! It can be a multi-year learning experience depending on your educational background. Better IDEs, APIs and whatnot won't be of any help. I recommend every new user to read & work through Programming in Scala, and spend the required time to nail down the basics. Blame the acolytes of programming language theory for making it so, but it does, and always will, require at a minimum some months of dedicated work just to get started. With that in mind you can have a great learning experience while practising the Scala-ble language.

On 16 November 2011 02:41, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
Going back to UI APIs.. writing those early Macintosh applications was a bitch, there was so much raw complexity. Looking at modern GUI platforms like Swing, WPF, or Java FX (using FX Script or now Scala), the actual complexity is quite fierce compared to the original Macintosh, but most of that complexity is far removed from the designer/developer because we have simply learned how to architect better APIs, and the rest of the complexity is tolerable because the overall education and culture of developers is better wrt GUI design/implementation.

I would conclude that if you really want more people to adopt Scala then some things that would help are:
  1. Accept/Admit that Scala is complex, but improve the marketing of the overall value (productivity). Automobiles are way more complex than bicycles, yet more people still use automobiles.
  2. Continue to remove the developer from the complexity with things like better IDE support and better integration with existing tools, improved APIs, improved language features, etc.
  3. Continue to improve the educational and cultural experience for new developers
Already I see a new discussion on "Actual complexity in Scala that warrants simplification" that seems to address (2). From my perspective there is no silver bullet for getting people to adopt Scala, it will simply take time; continuing enthusiasm, advocacy and marketing savvy; and dedication to continuous improvements to the 'developer experience'

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces
I'm not sure what your point is as I got lost somewhere along the way - I am not sure if I am agreeing or disagreeing with you :-)

If you are complaining about JavaScript + HTML + CSS; try adding Struts, Faces, JSP, EJB, etc. to all that too - I agree with you, I personally hate all that crap with a passion (but I may be in the minority).

IMHO, the future is working with things like GWT, Silverlight, Java FX, etc. - Rich Internet Applications as opposed 'Web Apps'. Building an RIA is much closer to building a desktop application and far kinder to the software developer. The fact that some of these environments can be deployed in both a web browser and a desktop makes the actual applications that more flexible and valuable to the end users. When Java FX drag-and-drop works well it is unbelievably cool, and the code is not necessarily that much harder to write. If Google Chrome O/S succeeds, however, there will no longer be any desktops, just a skookum web browser attached to the cloud.

I am still asking myself why we can't replace JavaScript in the browser with Scala. I still cannot figure out why we cannot build a web browser that executes JVM byte-code as well as JavaScript source code. It is truly bizarre that GWT compiles Java into JavaScript - but it actually seems to work. It is relatively quick and easy to get started with your first GWT application as Google have done a pretty good job with the packaging.

I really do see GUI design and implementation as getting better. While the underlying technologies continue to add complexity, the good solutions bury it far enough down to minimize frustration for the developer.

There are some really cool ideas, such as continuations and Deprecating the Observer Pattern, that could make GUI design and implementation even better, and hopefully we will see some real solutions emerge from this soon. I am still trying to find time to write my First Java FX 2.0 application in Scala. For something really 'tasty' see http://javafx.steveonjava.com/javafx-2-0-and-scala-like-milk-and-cookies

Getting back to Scala - I feel that as Scala and the Scala ecosystem mature, things will get better/easier over time, but it has taken decades for GUI technology to get to where it is now. Scala is to Java what GUI is to command line, and what automobiles are to bicycles. As a software architect I have to be alert and wise as to when the best opportunity is for my particular employer and my particular team to invest in Scala.

Cheers, Eric

On 2011-11-16 3:28 PM, Trond Olsen wrote:
ZQnStsVjUKY5toG7+EazD4A+uA [at] mail [dot] gmail [dot] com" type="cite">Not compared to orchestrating Javascript + HTML + CSS! I've toiled with my little project for some years now. It's part Scala, Javascript, and Actionscipt 3, and Scala, second to Javascript, has always been the easiest (and expressive) language to work in. Mind you, I did spend time learning the language properly, and avoided using advanced features I had no use for. For new users who want to learn it in one go, forget it! It can be a multi-year learning experience depending on your educational background. Better IDEs, APIs and whatnot won't be of any help. I recommend every new user to read & work through Programming in Scala, and spend the required time to nail down the basics. Blame the acolytes of programming language theory for making it so, but it does, and always will, require at a minimum some months of dedicated work just to get started. With that in mind you can have a great learning experience while practising the Scala-ble language.

On 16 November 2011 02:41, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
Going back to UI APIs.. writing those early Macintosh applications was a bitch, there was so much raw complexity. Looking at modern GUI platforms like Swing, WPF, or Java FX (using FX Script or now Scala), the actual complexity is quite fierce compared to the original Macintosh, but most of that complexity is far removed from the designer/developer because we have simply learned how to architect better APIs, and the rest of the complexity is tolerable because the overall education and culture of developers is better wrt GUI design/implementation.

I would conclude that if you really want more people to adopt Scala then some things that would help are:
  1. Accept/Admit that Scala is complex, but improve the marketing of the overall value (productivity). Automobiles are way more complex than bicycles, yet more people still use automobiles.
  2. Continue to remove the developer from the complexity with things like better IDE support and better integration with existing tools, improved APIs, improved language features, etc.
  3. Continue to improve the educational and cultural experience for new developers
Already I see a new discussion on "Actual complexity in Scala that warrants simplification" that seems to address (2). From my perspective there is no silver bullet for getting people to adopt Scala, it will simply take time; continuing enthusiasm, advocacy and marketing savvy; and dedication to continuous improvements to the 'developer experience'

tolsen77
Joined: 2008-10-08,
User offline. Last seen 1 year 38 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces
Hehe, all I'm saying it takes time to learn Scala which I guess it your point too. People should be aware of that. Its complexity isn't the same as C++ with lots of quirky details, but instead offers a lot of fundamental concepts from the theory-side of language design which people aren't necessarily accustomed to.

On UI: Despite all problems I personally prefer standard webapps to Rich Internet Applications (as in whole window). I now have applet, flash, and html+css+javascript working together fairly seamless. Applet does the heavy cpu processing and 2d-canvas drawing, flash does vector graphics, and html+css+javascript the rest of the ui + server communication. Not an ideal solution, but it was the only viable path when I chose to keep it as a standard webpage. When html5 is ready I might be able to deprecate flash but applets are still required.

I agree the reactive data-flow stuff looks promising even though I have zero experience with it. :)

On 17 November 2011 01:16, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
I'm not sure what your point is as I got lost somewhere along the way - I am not sure if I am agreeing or disagreeing with you :-)
 
On 2011-11-16 3:28 PM, Trond Olsen wrote:
Not compared to orchestrating Javascript + HTML + CSS! I've toiled with my little project for some years now. It's part Scala, Javascript, and Actionscipt 3, and Scala, second to Javascript, has always been the easiest (and expressive) language to work in. Mind you, I did spend time learning the language properly, and avoided using advanced features I had no use for. For new users who want to learn it in one go, forget it! It can be a multi-year learning experience depending on your educational background. Better IDEs, APIs and whatnot won't be of any help. I recommend every new user to read & work through Programming in Scala, and spend the required time to nail down the basics. Blame the acolytes of programming language theory for making it so, but it does, and always will, require at a minimum some months of dedicated work just to get started. With that in mind you can have a great learning experience while practising the Scala-ble language.

On 16 November 2011 02:41, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
Going back to UI APIs.. writing those early Macintosh applications was a bitch, there was so much raw complexity. Looking at modern GUI platforms like Swing, WPF, or Java FX (using FX Script or now Scala), the actual complexity is quite fierce compared to the original Macintosh, but most of that complexity is far removed from the designer/developer because we have simply learned how to architect better APIs, and the rest of the complexity is tolerable because the overall education and culture of developers is better wrt GUI design/implementation.

I would conclude that if you really want more people to adopt Scala then some things that would help are:
  1. Accept/Admit that Scala is complex, but improve the marketing of the overall value (productivity). Automobiles are way more complex than bicycles, yet more people still use automobiles.
  2. Continue to remove the developer from the complexity with things like better IDE support and better integration with existing tools, improved APIs, improved language features, etc.
  3. Continue to improve the educational and cultural experience for new developers
Already I see a new discussion on "Actual complexity in Scala that warrants simplification" that seems to address (2). From my perspective there is no silver bullet for getting people to adopt Scala, it will simply take time; continuing enthusiasm, advocacy and marketing savvy; and dedication to continuous improvements to the 'developer experience'


H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces
Am 16.11.2011 02:41, schrieb Eric Kolotyluk:
4EC314DC [dot] 3000702 [at] gmail [dot] com" type="cite"> Analogies and Metaphors can be dicey because it is often easy to poke holes in them, but I'll proceed anyway.

I first learned to program in 1970 using BASIC with optical mark cards. I would write my program on the cards, put them in the card reader, push the start button, and the output would appear on a line-printer. The complexity of this was extremely low, as was the productivity.

Until 1981 all my programs had a command line user interface. The complexity of writing the UI code was also quite low, as was the productivity of the user. On the other hand the complexity to the user was enormously high - if you did not have decent documentation you were almost completely hosed, and there were so few decent standards in UI design it was a nightmare for the user.

After finishing my undergraduate degree, my first job, first project, was to rewrite the Operator Console for the Michigan Terminal System. Rather than a command line interface this was a 'full screen' application using a newly developed API we called the 'Screen Support Routines' which abstracted a standard UI onto various devices such as IBM 3270 and generic ASCII terminals. This was analogous to the Unix Curses API, but quite different in design. While the basic API was quite simple, designing and implementing a UI was much more complex than a command line UI as there were so many more considerations to deal with. In the end though, while the complexity was high for me (the developer) the complexity for the computer operators was low, and the flexibility was high because they could now use a variety of different terminals instead of only the old IBM 370 console. Basically the complexity was high but so was the value.

When the Macintosh first came out I soon tried my hand at writing an application using the Quick Draw API. Again, the complexity of the API and application was even higher than before, but the value of the resulting application was also higher.

If we consider programming languages and plot complexity against value (productivity) we might have something that looks like:

         Java                         Scala
(low complexity, high value) (high complexity, high value)

         BASIC                         C++
(low complexity, low value)  (high complexity, low value)

if i wanted to sell scala for money, i would put it this way:
x = complexity, y = value

pick a few common use cases and rate them in this coordinate system. how complex is it to solve the problem with the given language? the overall complexity is irrelevant, you don't have to use it in practice. what's relevant is the complexity the language forces on you.
next, i would draw another chart with "investment cost" instead of "complexity". complexity sounds dangerous, but what it actually means is "how much do i have to invest in learning/training" until i can use the promised productivity.

next, i would use a rating per language that tells the manager how much units of productivity he gets for each unit of investment and what the maximum productivity and investments are.


4EC314DC [dot] 3000702 [at] gmail [dot] com" type="cite">
Please, no religious comments, these are gross example to express a point. If we simply accept the fact that Scala is complex (for many people), then if we want more people to use it we need to market the value (productivity). I am appealing to everyone who argues Scala is not complex to realize, you are not the consumer we are marketing to, we are marketing to the consumers who believe Scala is complex.

Going back to UI APIs.. writing those early Macintosh applications was a bitch, there was so much raw complexity. Looking at modern GUI platforms like Swing, WPF, or Java FX (using FX Script or now Scala), the actual complexity is quite fierce compared to the original Macintosh, but most of that complexity is far removed from the designer/developer because we have simply learned how to architect better APIs, and the rest of the complexity is tolerable because the overall education and culture of developers is better wrt GUI design/implementation.

I would conclude that if you really want more people to adopt Scala then some things that would help are:
  1. Accept/Admit that Scala is complex, but improve the marketing of the overall value (productivity). Automobiles are way more complex than bicycles, yet more people still use automobiles.
  2. Continue to remove the developer from the complexity with things like better IDE support and better integration with existing tools, improved APIs, improved language features, etc.
  3. Continue to improve the educational and cultural experience for new developers
Already I see a new discussion on "Actual complexity in Scala that warrants simplification" that seems to address (2). From my perspective there is no silver bullet for getting people to adopt Scala, it will simply take time; continuing enthusiasm, advocacy and marketing savvy; and dedication to continuous improvements to the 'developer experience'

Cheers, Eric


Tom Switzer
Joined: 2011-07-19,
User offline. Last seen 42 years 45 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces
pick a few common use cases and rate them in this coordinate system. how complex is it to solve the problem with the given language? the overall complexity is irrelevant, you don't have to use it in practice. what's relevant is the complexity the language forces on you.

Interesting... each language would actually end up as a curve, since, even with Java, most languages don't force you to use all features. In this case, I think Scala's curve would probably be a lower bound on most competitors and cover a larger range/domain.
Tom Switzer
Joined: 2011-07-19,
User offline. Last seen 42 years 45 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces
Oops, I was thinking value was x, complexity was y. In the case where x = complexity & y = value, I'd say Scala is an upper bound :S

On Thu, Nov 17, 2011 at 12:47 PM, Tom Switzer <thomas [dot] switzer [at] gmail [dot] com> wrote:
pick a few common use cases and rate them in this coordinate system. how complex is it to solve the problem with the given language? the overall complexity is irrelevant, you don't have to use it in practice. what's relevant is the complexity the language forces on you.

Interesting... each language would actually end up as a curve, since, even with Java, most languages don't force you to use all features. In this case, I think Scala's curve would probably be a lower bound on most competitors and cover a larger range/domain.

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces
On 2011-11-17 9:36 AM, HamsterofDeath wrote:
4EC5461A [dot] 4000102 [at] gmx [dot] de" type="cite"> Am 16.11.2011 02:41, schrieb Eric Kolotyluk:
4EC314DC [dot] 3000702 [at] gmail [dot] com" type="cite"> Analogies and Metaphors can be dicey because it is often easy to poke holes in them, but I'll proceed anyway.

I first learned to program in 1970 using BASIC with optical mark cards. I would write my program on the cards, put them in the card reader, push the start button, and the output would appear on a line-printer. The complexity of this was extremely low, as was the productivity.

Until 1981 all my programs had a command line user interface. The complexity of writing the UI code was also quite low, as was the productivity of the user. On the other hand the complexity to the user was enormously high - if you did not have decent documentation you were almost completely hosed, and there were so few decent standards in UI design it was a nightmare for the user.

After finishing my undergraduate degree, my first job, first project, was to rewrite the Operator Console for the Michigan Terminal System. Rather than a command line interface this was a 'full screen' application using a newly developed API we called the 'Screen Support Routines' which abstracted a standard UI onto various devices such as IBM 3270 and generic ASCII terminals. This was analogous to the Unix Curses API, but quite different in design. While the basic API was quite simple, designing and implementing a UI was much more complex than a command line UI as there were so many more considerations to deal with. In the end though, while the complexity was high for me (the developer) the complexity for the computer operators was low, and the flexibility was high because they could now use a variety of different terminals instead of only the old IBM 370 console. Basically the complexity was high but so was the value.

When the Macintosh first came out I soon tried my hand at writing an application using the Quick Draw API. Again, the complexity of the API and application was even higher than before, but the value of the resulting application was also higher.

If we consider programming languages and plot complexity against value (productivity) we might have something that looks like:

         Java                         Scala
(low complexity, high value) (high complexity, high value)

         BASIC                         C++
(low complexity, low value)  (high complexity, low value)

if i wanted to sell scala for money, i would put it this way:
x = complexity, y = value

pick a few common use cases and rate them in this coordinate system. how complex is it to solve the problem with the given language? the overall complexity is irrelevant, you don't have to use it in practice. what's relevant is the complexity the language forces on you.
next, i would draw another chart with "investment cost" instead of "complexity". complexity sounds dangerous, but what it actually means is "how much do i have to invest in learning/training" until i can use the promised productivity.

next, i would use a rating per language that tells the manager how much units of productivity he gets for each unit of investment and what the maximum productivity and investments are.


Interesting approach. I'm sure there are many ways to look at value vs. liability (complexity). Which ever one works to get people motivated to try or invest in Scala would be a good one.

4EC5461A [dot] 4000102 [at] gmx [dot] de" type="cite">
4EC314DC [dot] 3000702 [at] gmail [dot] com" type="cite">
Please, no religious comments, these are gross example to express a point. If we simply accept the fact that Scala is complex (for many people), then if we want more people to use it we need to market the value (productivity). I am appealing to everyone who argues Scala is not complex to realize, you are not the consumer we are marketing to, we are marketing to the consumers who believe Scala is complex.

Going back to UI APIs.. writing those early Macintosh applications was a bitch, there was so much raw complexity. Looking at modern GUI platforms like Swing, WPF, or Java FX (using FX Script or now Scala), the actual complexity is quite fierce compared to the original Macintosh, but most of that complexity is far removed from the designer/developer because we have simply learned how to architect better APIs, and the rest of the complexity is tolerable because the overall education and culture of developers is better wrt GUI design/implementation.

I would conclude that if you really want more people to adopt Scala then some things that would help are:
  1. Accept/Admit that Scala is complex, but improve the marketing of the overall value (productivity). Automobiles are way more complex than bicycles, yet more people still use automobiles.
  2. Continue to remove the developer from the complexity with things like better IDE support and better integration with existing tools, improved APIs, improved language features, etc.
  3. Continue to improve the educational and cultural experience for new developers
Already I see a new discussion on "Actual complexity in Scala that warrants simplification" that seems to address (2). From my perspective there is no silver bullet for getting people to adopt Scala, it will simply take time; continuing enthusiasm, advocacy and marketing savvy; and dedication to continuous improvements to the 'developer experience'

Cheers, Eric


kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces
It may just be that in the future programming languages will continue to grow more sophisticated, and their complexity will swing from high to low and back like a pendulum as we continue to refine programming concepts and embody them in the new languages, but over all there will be more demands on better education and more experience from future programmers. After all, we will surely expect future programmers to be more productive than we are now. Maybe that is what we are seeing with Scala and we just have to accept it. Bye-bye forever BASIC circa 1970.

Various people have advocated that newbies not engage more sophisticated language features and programming concepts (i.e. type design) until they are ready. Razvan offered some good advice/insight - never ask lesser skilled programmers to work on [sophisticated] code implemented by highly skilled programmers. This is a really good point, and I know that where I work, we have not always done that well. For example, many times I have had to go back and clean up (refactor) Java code written by lesser skilled programmers. Often their problem was that they were in over their head conceptually, or they did not know how to properly use new language features like generics. The reality is that some software developers have maybe 2 years training from a technical school, while other have undergraduate or graduate degrees from university. Even people with graduate degrees have varying degrees of conceptual skills.

I think people need to pay more attention to the A1, A2, A3, L1, L2, L3 scales and think about how best to manage people's skills and software architectures with that in mind. Maybe this needs to be stressed better when people complain about the complexity and perils of Scala. I know I have changed my thinking on this a lot in the last year, the last few months especially.

I am beginning to believe that it is perfectly fine for an A1 programmer to work with Scala and benefit from it. They can be productive for a long time (maybe forever) without having to venture into A2 or L2 territory. Maybe that is just the beauty of Scala, one language can meet many people's needs, especially if expectations are set accordingly.

Maybe we need scala-user-A1, scala-user-A2, scala-user-A3, scala-user-L1, scala-user-L2, and scala-user-L3 mailing lists :-) I am just joking of course.

Cheers, Eric

On 2011-11-17 8:54 AM, Trond Olsen wrote:
owkb+05Ff9uWwUA4F049rh+SEg [at] mail [dot] gmail [dot] com" type="cite">Hehe, all I'm saying it takes time to learn Scala which I guess it your point too. People should be aware of that. Its complexity isn't the same as C++ with lots of quirky details, but instead offers a lot of fundamental concepts from the theory-side of language design which people aren't necessarily accustomed to.

On UI: Despite all problems I personally prefer standard webapps to Rich Internet Applications (as in whole window). I now have applet, flash, and html+css+javascript working together fairly seamless. Applet does the heavy cpu processing and 2d-canvas drawing, flash does vector graphics, and html+css+javascript the rest of the ui + server communication. Not an ideal solution, but it was the only viable path when I chose to keep it as a standard webpage. When html5 is ready I might be able to deprecate flash but applets are still required.

I agree the reactive data-flow stuff looks promising even though I have zero experience with it. :)

On 17 November 2011 01:16, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
I'm not sure what your point is as I got lost somewhere along the way - I am not sure if I am agreeing or disagreeing with you :-)
 
On 2011-11-16 3:28 PM, Trond Olsen wrote:
Not compared to orchestrating Javascript + HTML + CSS! I've toiled with my little project for some years now. It's part Scala, Javascript, and Actionscipt 3, and Scala, second to Javascript, has always been the easiest (and expressive) language to work in. Mind you, I did spend time learning the language properly, and avoided using advanced features I had no use for. For new users who want to learn it in one go, forget it! It can be a multi-year learning experience depending on your educational background. Better IDEs, APIs and whatnot won't be of any help. I recommend every new user to read & work through Programming in Scala, and spend the required time to nail down the basics. Blame the acolytes of programming language theory for making it so, but it does, and always will, require at a minimum some months of dedicated work just to get started. With that in mind you can have a great learning experience while practising the Scala-ble language.

On 16 November 2011 02:41, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" target="_blank" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
Going back to UI APIs.. writing those early Macintosh applications was a bitch, there was so much raw complexity. Looking at modern GUI platforms like Swing, WPF, or Java FX (using FX Script or now Scala), the actual complexity is quite fierce compared to the original Macintosh, but most of that complexity is far removed from the designer/developer because we have simply learned how to architect better APIs, and the rest of the complexity is tolerable because the overall education and culture of developers is better wrt GUI design/implementation.

I would conclude that if you really want more people to adopt Scala then some things that would help are:
  1. Accept/Admit that Scala is complex, but improve the marketing of the overall value (productivity). Automobiles are way more complex than bicycles, yet more people still use automobiles.
  2. Continue to remove the developer from the complexity with things like better IDE support and better integration with existing tools, improved APIs, improved language features, etc.
  3. Continue to improve the educational and cultural experience for new developers
Already I see a new discussion on "Actual complexity in Scala that warrants simplification" that seems to address (2). From my perspective there is no silver bullet for getting people to adopt Scala, it will simply take time; continuing enthusiasm, advocacy and marketing savvy; and dedication to continuous improvements to the 'developer experience'


Justin du coeur
Joined: 2009-03-04,
User offline. Last seen 42 years 45 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces
On Thu, Nov 17, 2011 at 1:25 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
but over all there will be more demands on better education and more experience from future programmers.

More, or simply different?
Seriously -- I'm not sure that we actually expect *more* from programmers today than we did 30 years ago.  But the concepts we teach them, and what we expect from them, has changed radically.
Just to name one relatively recent example: 15 years ago, I would have expected a decent programmer to know a *lot* about memory management, how to implement that, how to debug problems in it, and so forth.  Nowadays, that's an advanced skill, that most engineers never even think about, because the level of abstraction we focus on has changed.
I suspect that the same is happening here.  It's not that Scala demands more, or even that the concepts in scalaz are inherently harder -- it's that they are relatively new and very *different*, and we still aren't very good at teaching them.  But give it a decade of evolution in education, and the rise of higher-level languages, and I suspect tomorrow's programmers will find them completely natural.  But they'll be as unable to program efficiently *without* those concepts as most Java programmers are when thrown at C...
Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces
Yup. 
As everywhere else in society, we keep moving up the abstraction ladder and that won't stop. It would suck if it did... Bet you in two decades we'll have a different set of languages. 

As everywhere else in life, people move at different speeds on this ladder and that has to be accounted for... Just remember that 80% of drivers think, as I do, that they're above average, eh? 
Thanks,Razvan
On 2011-11-17, at 1:25 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:

It may just be that in the future programming languages will continue to grow more sophisticated, and their complexity will swing from high to low and back like a pendulum as we continue to refine programming concepts and embody them in the new languages, but over all there will be more demands on better education and more experience from future programmers. After all, we will surely expect future programmers to be more productive than we are now. Maybe that is what we are seeing with Scala and we just have to accept it. Bye-bye forever BASIC circa 1970.

Various people have advocated that newbies not engage more sophisticated language features and programming concepts (i.e. type design) until they are ready. Razvan offered some good advice/insight - never ask lesser skilled programmers to work on [sophisticated] code implemented by highly skilled programmers. This is a really good point, and I know that where I work, we have not always done that well. For example, many times I have had to go back and clean up (refactor) Java code written by lesser skilled programmers. Often their problem was that they were in over their head conceptually, or they did not know how to properly use new language features like generics. The reality is that some software developers have maybe 2 years training from a technical school, while other have undergraduate or graduate degrees from university. Even people with graduate degrees have varying degrees of conceptual skills.

I think people need to pay more attention to the A1, A2, A3, L1, L2, L3 scales and think about how best to manage people's skills and software architectures with that in mind. Maybe this needs to be stressed better when people complain about the complexity and perils of Scala. I know I have changed my thinking on this a lot in the last year, the last few months especially.

I am beginning to believe that it is perfectly fine for an A1 programmer to work with Scala and benefit from it. They can be productive for a long time (maybe forever) without having to venture into A2 or L2 territory. Maybe that is just the beauty of Scala, one language can meet many people's needs, especially if expectations are set accordingly.

Maybe we need scala-user-A1, scala-user-A2, scala-user-A3, scala-user-L1, scala-user-L2, and scala-user-L3 mailing lists :-) I am just joking of course.

Cheers, Eric

On 2011-11-17 8:54 AM, Trond Olsen wrote:
owkb+05Ff9uWwUA4F049rh+SEg [at] mail [dot] gmail [dot] com" type="cite">Hehe, all I'm saying it takes time to learn Scala which I guess it your point too. People should be aware of that. Its complexity isn't the same as C++ with lots of quirky details, but instead offers a lot of fundamental concepts from the theory-side of language design which people aren't necessarily accustomed to.

On UI: Despite all problems I personally prefer standard webapps to Rich Internet Applications (as in whole window). I now have applet, flash, and html+css+javascript working together fairly seamless. Applet does the heavy cpu processing and 2d-canvas drawing, flash does vector graphics, and html+css+javascript the rest of the ui + server communication. Not an ideal solution, but it was the only viable path when I chose to keep it as a standard webpage. When html5 is ready I might be able to deprecate flash but applets are still required.

I agree the reactive data-flow stuff looks promising even though I have zero experience with it. :)

On 17 November 2011 01:16, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
I'm not sure what your point is as I got lost somewhere along the way - I am not sure if I am agreeing or disagreeing with you :-)
 
On 2011-11-16 3:28 PM, Trond Olsen wrote:
Not compared to orchestrating Javascript + HTML + CSS! I've toiled with my little project for some years now. It's part Scala, Javascript, and Actionscipt 3, and Scala, second to Javascript, has always been the easiest (and expressive) language to work in. Mind you, I did spend time learning the language properly, and avoided using advanced features I had no use for. For new users who want to learn it in one go, forget it! It can be a multi-year learning experience depending on your educational background. Better IDEs, APIs and whatnot won't be of any help. I recommend every new user to read & work through Programming in Scala, and spend the required time to nail down the basics. Blame the acolytes of programming language theory for making it so, but it does, and always will, require at a minimum some months of dedicated work just to get started. With that in mind you can have a great learning experience while practising the Scala-ble language.

On 16 November 2011 02:41, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" target="_blank" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
Going back to UI APIs.. writing those early Macintosh applications was a bitch, there was so much raw complexity. Looking at modern GUI platforms like Swing, WPF, or Java FX (using FX Script or now Scala), the actual complexity is quite fierce compared to the original Macintosh, but most of that complexity is far removed from the designer/developer because we have simply learned how to architect better APIs, and the rest of the complexity is tolerable because the overall education and culture of developers is better wrt GUI design/implementation.

I would conclude that if you really want more people to adopt Scala then some things that would help are:
  1. Accept/Admit that Scala is complex, but improve the marketing of the overall value (productivity). Automobiles are way more complex than bicycles, yet more people still use automobiles.
  2. Continue to remove the developer from the complexity with things like better IDE support and better integration with existing tools, improved APIs, improved language features, etc.
  3. Continue to improve the educational and cultural experience for new developers
Already I see a new discussion on "Actual complexity in Scala that warrants simplification" that seems to address (2). From my perspective there is no silver bullet for getting people to adopt Scala, it will simply take time; continuing enthusiasm, advocacy and marketing savvy; and dedication to continuous improvements to the 'developer experience'


Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces

On Thu, Nov 17, 2011 at 1:03 PM, Razvan Cojocaru <pub [at] razie [dot] com> wrote:
Just remember that 80% of drivers think, as I do, that they're above average, eh? 

... which is statistically quite possible.
-- Cédric
Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
RE: Complexity Analogy: Graphical User Interfaces

I don’t think that has enough of a fat tail – possible, true, but I don’t think so… he he

 

From: cbeust [at] gmail [dot] com [mailto:cbeust [at] gmail [dot] com] On Behalf Of Cédric Beust ?
Sent: November-17-11 4:13 PM
To: Razvan Cojocaru
Cc: Eric Kolotyluk; scala-debate
Subject: Re: [scala-debate] Complexity Analogy: Graphical User Interfaces

 

 

On Thu, Nov 17, 2011 at 1:03 PM, Razvan Cojocaru <pub [at] razie [dot] com> wrote:

Just remember that 80% of drivers think, as I do, that they're above average, eh? 

 

... which is statistically quite possible.

 

-- 

Cédric

 

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces
On 2011-11-17 10:49 AM, Justin du coeur wrote:
X_g [at] mail [dot] gmail [dot] com" type="cite"> On Thu, Nov 17, 2011 at 1:25 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
but over all there will be more demands on better education and more experience from future programmers.

More, or simply different?
Seriously -- I'm not sure that we actually expect *more* from programmers today than we did 30 years ago.  But the concepts we teach them, and what we expect from them, has changed radically.
Just to name one relatively recent example: 15 years ago, I would have expected a decent programmer to know a *lot* about memory management, how to implement that, how to debug problems in it, and so forth.  Nowadays, that's an advanced skill, that most engineers never even think about, because the level of abstraction we focus on has changed.
I suspect that the same is happening here.  It's not that Scala demands more, or even that the concepts in scalaz are inherently harder -- it's that they are relatively new and very *different*, and we still aren't very good at teaching them.  But give it a decade of evolution in education, and the rise of higher-level languages, and I suspect tomorrow's programmers will find them completely natural.  But they'll be as unable to program efficiently *without* those concepts as most Java programmers are when thrown at C...

30 years ago was about when I was finishing my undergraduate degree - 40 years ago was when I started programming.

30 years ago my education was not a good as today's undergraduates because the science was still young. Today's undergraduates are standing on the shoulders of those who came before them. 30 years ago state-of-the-art languages were C and Pascal - both were trivial to learn and master - although Pascal was 'nicer'. We also had the advent of SmallTalk, which was fairly easy to learn but more challenging to master because it gave the programmer much more power.

Fast forward to today and my sense is that Scala is like the SmallTalk of this era. For a subset of Scala I don't think it is much harder than C or Pascal to learn, especially because you don't have to deal with 'memory management' (as you mentioned) because we have garbage collection. My sense is also that Scala is a lot more sophisticated than SmallTalk (I may be wrong) and my sense also tells me you need to be on the leading edge of Computing Science research and education to make the most of Scala. A decade from now I think most undergraduates will be able to make the most of Scala because the education and experience will be better by then.

What has been difficult for me to come to terms with is the range of power that Scala has, especially compared to C, Pascal and even Java. It used to be that anyone who could write code could master all of C or Pascal. Most people can still master most of Java, but you do have to stretch a little further to master type design, generics, concurrency, etc. I feel like you have to a mental athlete to master all of Scala, but even the addle minded (like me) can still enjoy it :-)

I think for the most part I agree with what you are saying as well.

Cheers, Eric
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces
Anyone who drives slower than me is an idiot, and anyone who drives faster than me is a maniac - lol

Maybe every download of Scala needs to come with a coupon for a free Red Bull ;-)

Cheers, Eric

On 2011-11-17 1:03 PM, Razvan Cojocaru wrote:
B12A675C-E6E3-4B6D-9BB7-E622983C77CF [at] razie [dot] com" type="cite"> Yup. 
As everywhere else in society, we keep moving up the abstraction ladder and that won't stop. It would suck if it did... Bet you in two decades we'll have a different set of languages. 

As everywhere else in life, people move at different speeds on this ladder and that has to be accounted for... Just remember that 80% of drivers think, as I do, that they're above average, eh? 
Thanks, Razvan
On 2011-11-17, at 1:25 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:

It may just be that in the future programming languages will continue to grow more sophisticated, and their complexity will swing from high to low and back like a pendulum as we continue to refine programming concepts and embody them in the new languages, but over all there will be more demands on better education and more experience from future programmers. After all, we will surely expect future programmers to be more productive than we are now. Maybe that is what we are seeing with Scala and we just have to accept it. Bye-bye forever BASIC circa 1970.

Various people have advocated that newbies not engage more sophisticated language features and programming concepts (i.e. type design) until they are ready. Razvan offered some good advice/insight - never ask lesser skilled programmers to work on [sophisticated] code implemented by highly skilled programmers. This is a really good point, and I know that where I work, we have not always done that well. For example, many times I have had to go back and clean up (refactor) Java code written by lesser skilled programmers. Often their problem was that they were in over their head conceptually, or they did not know how to properly use new language features like generics. The reality is that some software developers have maybe 2 years training from a technical school, while other have undergraduate or graduate degrees from university. Even people with graduate degrees have varying degrees of conceptual skills.

I think people need to pay more attention to the A1, A2, A3, L1, L2, L3 scales and think about how best to manage people's skills and software architectures with that in mind. Maybe this needs to be stressed better when people complain about the complexity and perils of Scala. I know I have changed my thinking on this a lot in the last year, the last few months especially.

I am beginning to believe that it is perfectly fine for an A1 programmer to work with Scala and benefit from it. They can be productive for a long time (maybe forever) without having to venture into A2 or L2 territory. Maybe that is just the beauty of Scala, one language can meet many people's needs, especially if expectations are set accordingly.

Maybe we need scala-user-A1, scala-user-A2, scala-user-A3, scala-user-L1, scala-user-L2, and scala-user-L3 mailing lists :-) I am just joking of course.

Cheers, Eric

On 2011-11-17 8:54 AM, Trond Olsen wrote:
owkb+05Ff9uWwUA4F049rh+SEg [at] mail [dot] gmail [dot] com" type="cite">Hehe, all I'm saying it takes time to learn Scala which I guess it your point too. People should be aware of that. Its complexity isn't the same as C++ with lots of quirky details, but instead offers a lot of fundamental concepts from the theory-side of language design which people aren't necessarily accustomed to.

On UI: Despite all problems I personally prefer standard webapps to Rich Internet Applications (as in whole window). I now have applet, flash, and html+css+javascript working together fairly seamless. Applet does the heavy cpu processing and 2d-canvas drawing, flash does vector graphics, and html+css+javascript the rest of the ui + server communication. Not an ideal solution, but it was the only viable path when I chose to keep it as a standard webpage. When html5 is ready I might be able to deprecate flash but applets are still required.

I agree the reactive data-flow stuff looks promising even though I have zero experience with it. :)

On 17 November 2011 01:16, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
I'm not sure what your point is as I got lost somewhere along the way - I am not sure if I am agreeing or disagreeing with you :-)
 
On 2011-11-16 3:28 PM, Trond Olsen wrote:
Not compared to orchestrating Javascript + HTML + CSS! I've toiled with my little project for some years now. It's part Scala, Javascript, and Actionscipt 3, and Scala, second to Javascript, has always been the easiest (and expressive) language to work in. Mind you, I did spend time learning the language properly, and avoided using advanced features I had no use for. For new users who want to learn it in one go, forget it! It can be a multi-year learning experience depending on your educational background. Better IDEs, APIs and whatnot won't be of any help. I recommend every new user to read & work through Programming in Scala, and spend the required time to nail down the basics. Blame the acolytes of programming language theory for making it so, but it does, and always will, require at a minimum some months of dedicated work just to get started. With that in mind you can have a great learning experience while practising the Scala-ble language.

On 16 November 2011 02:41, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" target="_blank" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
Going back to UI APIs.. writing those early Macintosh applications was a bitch, there was so much raw complexity. Looking at modern GUI platforms like Swing, WPF, or Java FX (using FX Script or now Scala), the actual complexity is quite fierce compared to the original Macintosh, but most of that complexity is far removed from the designer/developer because we have simply learned how to architect better APIs, and the rest of the complexity is tolerable because the overall education and culture of developers is better wrt GUI design/implementation.

I would conclude that if you really want more people to adopt Scala then some things that would help are:
  1. Accept/Admit that Scala is complex, but improve the marketing of the overall value (productivity). Automobiles are way more complex than bicycles, yet more people still use automobiles.
  2. Continue to remove the developer from the complexity with things like better IDE support and better integration with existing tools, improved APIs, improved language features, etc.
  3. Continue to improve the educational and cultural experience for new developers
Already I see a new discussion on "Actual complexity in Scala that warrants simplification" that seems to address (2). From my perspective there is no silver bullet for getting people to adopt Scala, it will simply take time; continuing enthusiasm, advocacy and marketing savvy; and dedication to continuous improvements to the 'developer experience'


Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces
On Thu, Nov 17, 2011 at 8:42 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:

30 years ago my education was not a good as today's undergraduates because the science was still young. Today's undergraduates are standing on the shoulders of those who came before them. 30 years ago state-of-the-art languages were C and Pascal - both were trivial to learn and master - although Pascal was 'nicer'. We also had the advent of SmallTalk, which was fairly easy to learn but more challenging to master because it gave the programmer much more power.

C is "trivial to learn and master"? Are you serious? The language rules may be relatively simple, but applying them without making errors is notoriously difficult. Saying that you've mastered C because you know its rules is a bit like saying that you've mastered Chess because you know all the rules for how to move the players. I think of using C as analogous to riding a motorcycle, whereas using higher-level languages is more like driving a car. Yeah, you can get great performance on a motorcycle if you are highly skilled, but you are likely to do serious damage if you aren't and think you are.


Fast forward to today and my sense is that Scala is like the SmallTalk of this era. For a subset of Scala I don't think it is much harder than C or Pascal to learn, especially because you don't have to deal with 'memory management' (as you mentioned) because we have garbage collection. My sense is also that Scala is a lot more sophisticated than SmallTalk (I may be wrong) and my sense also tells me you need to be on the leading edge of Computing Science research and education to make the most of Scala. A decade from now I think most undergraduates will be able to make the most of Scala because the education and experience will be better by then.

What has been difficult for me to come to terms with is the range of power that Scala has, especially compared to C, Pascal and even Java. It used to be that anyone who could write code could master all of C or Pascal. Most people can still master most of Java, but you do have to stretch a little further to master type design, generics, concurrency, etc. I feel like you have to a mental athlete to master all of Scala, but even the addle minded (like me) can still enjoy it :-)


Using Scala is more like flying a high-performance airplane. You need a different kind of skill than you need for riding a motorcycle, higher-level skills.

--Russ P.

--
http://RussP.us
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces
On 2011-11-17 10:59 PM, Russ Paielli wrote:
CAHy81hPfJ3hjT6oWdCeDr6T7QoTWg6aze9Y3bbj4CSfn31gegA [at] mail [dot] gmail [dot] com" type="cite">On Thu, Nov 17, 2011 at 8:42 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:

30 years ago my education was not a good as today's undergraduates because the science was still young. Today's undergraduates are standing on the shoulders of those who came before them. 30 years ago state-of-the-art languages were C and Pascal - both were trivial to learn and master - although Pascal was 'nicer'. We also had the advent of SmallTalk, which was fairly easy to learn but more challenging to master because it gave the programmer much more power.

C is "trivial to learn and master"? Are you serious? The language rules may be relatively simple, but applying them without making errors is notoriously difficult. Saying that you've mastered C because you know its rules is a bit like saying that you've mastered Chess because you know all the rules for how to move the players. I think of using C as analogous to riding a motorcycle, whereas using higher-level languages is more like driving a car. Yeah, you can get great performance on a motorcycle if you are highly skilled, but you are likely to do serious damage if you aren't and think you are.

Strangely I learned C after learning Pascal. I think this helped me because I transferred many of my habits of organization from Pascal to C and did not get into trouble too often. I would agree with you about the subtleties and danger in C, but if you already had good coding habits it helped to avoid them. Working on some other people's C code I saw clearly how messed up some people got.

I first learned to ride a bicycle (like I learned assembler before learning C), then I learned to drive tractors, trucks and cars. By the time I bought my first motorcycle I found it pretty trivial because I already had road and traffic skills and good driving habits, and it was not too different than riding a bicycle, and I never got into any serious problems. just a few close calls.

However, every person's life experience is different and there may be people who got into more trouble with C than I did. Maybe C was a poor example. I was tempted to use Lisp as an example though, but I thought I might get a different kind of complaint from people ;-)

CAHy81hPfJ3hjT6oWdCeDr6T7QoTWg6aze9Y3bbj4CSfn31gegA [at] mail [dot] gmail [dot] com" type="cite">

Fast forward to today and my sense is that Scala is like the SmallTalk of this era. For a subset of Scala I don't think it is much harder than C or Pascal to learn, especially because you don't have to deal with 'memory management' (as you mentioned) because we have garbage collection. My sense is also that Scala is a lot more sophisticated than SmallTalk (I may be wrong) and my sense also tells me you need to be on the leading edge of Computing Science research and education to make the most of Scala. A decade from now I think most undergraduates will be able to make the most of Scala because the education and experience will be better by then.

What has been difficult for me to come to terms with is the range of power that Scala has, especially compared to C, Pascal and even Java. It used to be that anyone who could write code could master all of C or Pascal. Most people can still master most of Java, but you do have to stretch a little further to master type design, generics, concurrency, etc. I feel like you have to a mental athlete to master all of Scala, but even the addle minded (like me) can still enjoy it :-)


Using Scala is more like flying a high-performance airplane. You need a different kind of skill than you need for riding a motorcycle, higher-level skills.

Yet, some motorcycle skills are more transferable to flying skills as you cannot bank a car when going into a turn. But your point about Scala is a good one, although while any Java programmer can dive right into Scala using the basics, even a season motorcycle or automobile driver is really unprepared to just get into the cockpit of a plane and fly, although they are probably OK just taxiing the plane around on the ground.

Another good comparison is that like Scala, you need a much better education - with grounding in concepts, theory, weather, instruments, communications, navigation, etc. - and safe practice to learn to fly in order to get the most of the plane.

Thanks for the flying analogy/metaphor - I really like it :-)

Cheers, Eric

CAHy81hPfJ3hjT6oWdCeDr6T7QoTWg6aze9Y3bbj4CSfn31gegA [at] mail [dot] gmail [dot] com" type="cite">
--Russ P.

--
http://RussP.us
Ken McDonald
Joined: 2011-02-13,
User offline. Last seen 42 years 45 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces
On Wednesday, November 16, 2011 8:01:52 AM UTC-6, Eric Kolotyluk wrote:
This kind of response is a good example of what I would consider is one of the problems with Scala...

On 2011-11-15 10:22 PM, Tony Morris wrote:
The very idea that Java is less complex than Scala is ridiculous, perpetuated only by people who know neither Java nor Scala. Too bad for them, but why should you further entertain the silliness with "gross metaphors"?

Here we see an example of an author desperately trying to invalidate someone's point of view. First of all, they seem to be talking in black and white (inflexible) terms here, using hyperbole, and immediately dismissing the possibility that other people may find Scala more complex than Java. Second of all they seem to make it personal by viewing people who do not agree with their reality as 'perpetrators' and casting them as not knowing the subject they are talking about. Finally they seem to use a condescending tone by classifying someone else's ideas as 'silliness.'

You are responding to Tony Morris, "The Man Who Is Always Right(TM)". Please don't feed the Tonies. :-)
Ken 
Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: Complexity Analogy: Graphical User Interfaces
On Fri, Nov 18, 2011 at 10:22 PM, Kenneth McDonald <ykkenmcd [at] gmail [dot] com> wrote:
On Wednesday, November 16, 2011 8:01:52 AM UTC-6, Eric Kolotyluk wrote:
This kind of response is a good example of what I would consider is one of the problems with Scala...

On 2011-11-15 10:22 PM, Tony Morris wrote:
The very idea that Java is less complex than Scala is ridiculous, perpetuated only by people who know neither Java nor Scala. Too bad for them, but why should you further entertain the silliness with "gross metaphors"?

Here we see an example of an author desperately trying to invalidate someone's point of view. First of all, they seem to be talking in black and white (inflexible) terms here, using hyperbole, and immediately dismissing the possibility that other people may find Scala more complex than Java. Second of all they seem to make it personal by viewing people who do not agree with their reality as 'perpetrators' and casting them as not knowing the subject they are talking about. Finally they seem to use a condescending tone by classifying someone else's ideas as 'silliness.'

You are responding to Tony Morris, "The Man Who Is Always Right(TM)". Please don't feed the Tonies. :-)

Well, the Tonies will come anyway, and that's generally a good thing.
Firstly, the initial "chart" ranges from "not even useful" to "seriously flawed".  A more accurate chart would read:
         Java                                       Scala
(most familiar with,                         (Still thinking it's Java,  only a few more idiosyncrasies to learn)      It's not Java; it's considerably better                                                AND simpler than Java)
         BASIC                                       C++
(It's named BASIC after all,                 (Bash C++, Bash C++ [because it deserves it?])   Anything named BASIC must be low value  right?)

If I had to hazard a guess as to where you went wrong it would be when you started out worrying about languages at all.  Firstly, think about the problem you have to deal with.  Then think about how you would define the operations that would solve that problems, abstractly (remember, abstraction is your friend).  Then, as you refine your solution you should discover that Scala will, generally, rise to meet you before Java is even visible on the horizon.  Expressing solutions to problems succinctly and clearly is a sign of a well designed language (and libraries) and does not indicate complexity.  (Yes, there are better designed languages than Scala that rise up to meet you during problem refinement much earlier, but Scala is heads-and-shoulders superior to Java in all meaningful ways, except at being Java.  Left as an exercise why that is a bad thing).
--
Jim Powers
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces
On 2011-11-20 4:22 PM, Jim Powers wrote:
+DOojcg [at] mail [dot] gmail [dot] com" type="cite">On Fri, Nov 18, 2011 at 10:22 PM, Kenneth McDonald <ykkenmcd [at] gmail [dot] com" target="_blank" rel="nofollow">ykkenmcd [at] gmail [dot] com> wrote:
On Wednesday, November 16, 2011 8:01:52 AM UTC-6, Eric Kolotyluk wrote:
This kind of response is a good example of what I would consider is one of the problems with Scala...

On 2011-11-15 10:22 PM, Tony Morris wrote:
The very idea that Java is less complex than Scala is ridiculous, perpetuated only by people who know neither Java nor Scala. Too bad for them, but why should you further entertain the silliness with "gross metaphors"?

Here we see an example of an author desperately trying to invalidate someone's point of view. First of all, they seem to be talking in black and white (inflexible) terms here, using hyperbole, and immediately dismissing the possibility that other people may find Scala more complex than Java. Second of all they seem to make it personal by viewing people who do not agree with their reality as 'perpetrators' and casting them as not knowing the subject they are talking about. Finally they seem to use a condescending tone by classifying someone else's ideas as 'silliness.'

You are responding to Tony Morris, "The Man Who Is Always Right(TM)". Please don't feed the Tonies. :-)

Well, the Tonies will come anyway, and that's generally a good thing.

OK, I am not sure if you are serious, or using satire to make some other point. Jim, my response was not to Tony, it was to the readers and my point was that comments such as the kind Tony sometimes makes, are not at all helpful to people who are interested in Scala (yet hesitant or undecided about investing in it). I cannot see how such comments are a "good thing" in this context.

+DOojcg [at] mail [dot] gmail [dot] com" type="cite">
Firstly, the initial "chart" ranges from "not even useful" to "seriously flawed".

In my opening statement to this thread I said "Please, no religious comments, these are gross example to express a point."

+DOojcg [at] mail [dot] gmail [dot] com" type="cite"> A more accurate chart would read:
         Java                                       Scala
(most familiar with,                         (Still thinking it's Java,  only a few more idiosyncrasies to learn)      It's not Java; it's considerably better                                                AND simpler than Java)
         BASIC                                       C++
(It's named BASIC after all,                 (Bash C++, Bash C++ [because it deserves it?])   Anything named BASIC must be low value   right?)


Ok, I can see you have a sense of humor, but from my perspective you are still making a religious comment. I think this would be better appreciated on the [scala-theology] mailing list - all denominations accepted our course ;-)

+DOojcg [at] mail [dot] gmail [dot] com" type="cite"> If I had to hazard a guess as to where you went wrong it would be when you started out worrying about languages at all.  Firstly, think about the problem you have to deal with.  Then think about how you would define the operations that would solve that problems, abstractly (remember, abstraction is your friend).  Then, as you refine your solution you should discover that Scala will, generally, rise to meet you before Java is even visible on the horizon.  Expressing solutions to problems succinctly and clearly is a sign of a well designed language (and libraries) and does not indicate complexity.  (Yes, there are better designed languages than Scala that rise up to meet you during problem refinement much earlier, but Scala is heads-and-shoulders superior to Java in all meaningful ways, except at being Java.  Left as an exercise why that is a bad thing).
--
Jim Powers

Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: Complexity Analogy: Graphical User Interfaces
On Sun, Nov 20, 2011 at 7:46 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
Ok, I can see you have a sense of humor, but from my perspective you are still making a religious comment. I think this would be better appreciated on the [scala-theology] mailing list - all denominations accepted our course ;-)
If I had to hazard a guess as to where you went wrong it would be when you started out worrying about languages at all.  Firstly, think about the problem you have to deal with.  Then think about how you would define the operations that would solve that problems, abstractly (remember, abstraction is your friend).  Then, as you refine your solution you should discover that Scala will, generally, rise to meet you before Java is even visible on the horizon.  Expressing solutions to problems succinctly and clearly is a sign of a well designed language (and libraries) and does not indicate complexity.  (Yes, there are better designed languages than Scala that rise up to meet you during problem refinement much earlier, but Scala is heads-and-shoulders superior to Java in all meaningful ways, except at being Java.  Left as an exercise why that is a bad thing).
Not even remotely so.
If your premise is flawed, the conclusions are almost certainly going to be useless, or worse: they could devolve into disinformation.
Try this: Solve a problem in say, Java and then in Scala.  Try to do this only using the "standard" libraries for both languages for starters.  Then make the case that the Java version is "less complex" (of course, defining your notion of complex).  Next, take a stab at generalizing that this pattern to all solutions to problems in each language.  If you can convince yourself that something about *any* Scala solution is always more complex than the equivalent Java solution then well, it appears that Java is the language for you, by your own initial condition: 
           Java                         Scala
(low complexity, high value) (high complexity, high value)
You have apparently arrived at Nirvana and this entire thread is for naught.  Or just stick to writing "Java in Scala" complete with Spring, AspectJ, Guice, and so forth, it (amazingly) all works and save yourself some semicolons.  If you suspect that there is more to Scala than that then you might want to reconsider what the "Tonys" are saying.  When I first came to working with Scala I too encountered "the Tony" and approached his comments with my own opinions.  Although I don't always agree with "the Tony" I've found that I've gotten a hell of a lot more out of thinking about what "the hell he's talking about" than assuming that he's psychotic (in an ultra-FP-religious way).  The bottom line really was: most of my notions about utility was wrong.  Kinda strange to come to that point after 23 years of programming.  It was a worth-while revelation.
--
Jim Powers
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Complexity Analogy: Graphical User Interfaces
On 2011-11-20 5:18 PM, Jim Powers wrote:
fo51bd0ig0A3Vw [at] mail [dot] gmail [dot] com" type="cite">On Sun, Nov 20, 2011 at 7:46 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
Ok, I can see you have a sense of humor, but from my perspective you are still making a religious comment. I think this would be better appreciated on the [scala-theology] mailing list - all denominations accepted our course ;-)
If I had to hazard a guess as to where you went wrong it would be when you started out worrying about languages at all.  Firstly, think about the problem you have to deal with.  Then think about how you would define the operations that would solve that problems, abstractly (remember, abstraction is your friend).  Then, as you refine your solution you should discover that Scala will, generally, rise to meet you before Java is even visible on the horizon.  Expressing solutions to problems succinctly and clearly is a sign of a well designed language (and libraries) and does not indicate complexity.  (Yes, there are better designed languages than Scala that rise up to meet you during problem refinement much earlier, but Scala is heads-and-shoulders superior to Java in all meaningful ways, except at being Java.  Left as an exercise why that is a bad thing).
Not even remotely so.
If your premise is flawed, the conclusions are almost certainly going to be useless, or worse: they could devolve into disinformation.
Try this: Solve a problem in say, Java and then in Scala.  Try to do this only using the "standard" libraries for both languages for starters.  Then make the case that the Java version is "less complex" (of course, defining your notion of complex).  Next, take a stab at generalizing that this pattern to all solutions to problems in each language.  If you can convince yourself that something about *any* Scala solution is always more complex than the equivalent Java solution then well, it appears that Java is the language for you, by your own initial condition: 
           Java                         Scala
(low complexity, high value) (high complexity, high value)
You have apparently arrived at Nirvana and this entire thread is for naught.  Or just stick to writing "Java in Scala" complete with Spring, AspectJ, Guice, and so forth, it (amazingly) all works and save yourself some semicolons.  If you suspect that there is more to Scala than that then you might want to reconsider what the "Tonys" are saying.  When I first came to working with Scala I too encountered "the Tony" and approached his comments with my own opinions.  Although I don't always agree with "the Tony" I've found that I've gotten a hell of a lot more out of thinking about what "the hell he's talking about" than assuming that he's psychotic (in an ultra-FP-religious way).  The bottom line really was: most of my notions about utility was wrong.  Kinda strange to come to that point after 23 years of programming.  It was a worth-while revelation.
--
Jim Powers
OK Jim, I can see you are serious, but unfamiliar with the concepts of analogies or metaphors, so I won't bother.

Cheers, Eric
Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: Complexity Analogy: Graphical User Interfaces
On Sun, Nov 20, 2011 at 8:31 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
OK Jim, I can see you are serious, but unfamiliar with the concepts of analogies or metaphors, so I won't bother.

If we hit that bullseye, the rest of the dominoes will fall like a house of cards. Checkmate. -- Zapp Brannigan
No, that's not it either.  Some analogies are like a container where half its volume has one substance and the other half has another substance: not very useful.
Whatever you're agreeing with yourself about you're CRUSHING IT!
Peace out, yo!

--
Jim Powers
Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Complexity Analogy: Graphical User Interfaces

On Thu, Nov 17, 2011 at 11:54 AM, Trond Olsen <trond [at] steinbit [dot] org> wrote:

I agree the reactive data-flow stuff looks promising even though I have zero experience with it. :)



Have you seen reactive-web

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland