Complexity Analogy: Graphical User Interfaces

30 replies

Wed, 2011-11-16, 02:41

kolotyluk

Joined: 2010-06-04,

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'

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
>

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:

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'

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

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

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:

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'

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

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

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

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

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.

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'

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.

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'

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. :)

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.

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'

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:

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'

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.

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.

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:

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'

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.

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. :)

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.

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'

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

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,RazvanOn 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.

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. :)

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.

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'

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

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.

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.

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. :)

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.

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'

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.

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

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.

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

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

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.

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

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

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 BranniganNo, 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!