--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
What's really mystifying to me is that I really don't see OO and functional operate at the same level, let alone being mutually exclusive with each other.Functional is more about the implementation of your methods while OO gives you a way to organize them in a way that maximizes reuse and encapsulation.--Cédric
I am sure its nothing to do with job satification of teaching, helping
the next generation to get skills that will enable them to get a good
life, more flexible work hours, to be paid to look into new technologies
to determine their relevance to course materials, to have the
possibility of doing funded research, then having a pool of bright
students you can use to progress your research interests where the only
requirement is to make sure they learn something along the way, .... ;-)
I used to work at a university - most of the fellow professors did not
*want* to get a "real" job as you put it. They got paid less, but had a
lot more fun and a lot less stress! Its not clear to me yet who is
"smarter" here.
Just my 2c worth.
Alan
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
There is a aspect to this which is correct - but it can be taken too
far. Just because their personal objective is not business oriented
does not mean they cannot teach things useful to programmers who will
work in the business world.
However, Professors also teach multiple subjects, and the ones I know
teach some subjects that are not so interesting to them, but they accept
that as part of the job. We all have things in our jobs that are less
enjoyable I suspect.
How do you get feedback from real industry? Well, the University I was
at teaches post graduate students whom the lecturers talk to. They do
read up on various sources. They talk to people in industry. But they
also see the importance of teaching skills like problem solving and
giving breadth of experience. Teaching a student one technology is not
always that useful - technology dates. Its teaching the skill to pick
up new technologies that is more useful. You just have to pick some
technology to use in practice as a vehicle.
Anyway, I don't think this line of discussion is being that productive
so I am going to drop out of it. I just reacted to what appeared to be
pretty blanket statements. I know a number of academics that have moved
into industry, and industry people that teach at Universities. I would
not necessarily agree that business people are better teachers than
Professors. But I do agree that I have come across Professors that are
very much focussed on their own pet interests - but I find similar
people in industry too! I think its a part of being human! ;-)
Alan
If this is the attitude people are going to have and express it's no
wonder the world is a totally f$$$ed up place.
There are a very large number of people out in industry and commerce who
are so appallingly awful at programming they shouldn't be allowed
anywhere near an IDE let alone an editor.
It is true there are people trying to teach programming who do not have
a clue what they are talking about. It is also true that there are
people teaching programming who are far, far, far better programmers
than anyone in industry and commerce -- bar none.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
I think we can see fallout from the 1980s. Then it was Imperative vs.
Declarative but rather than coming to any sane resolution, the battle
evolved into Functional vs Object-oriented. Of course C was what people
who weren't using Pascal, Fortran, Ada, Modula-2, Smalltalk, etc. were
using and thus C++ became the poster child of object-orientation. Which
in itself is a bit strange as the object-oriented of C++ wasn't the
object-oriented that the object-oriented folk were fighting for!
In the UK, successive governments have over the last 20 years tried to
destroy the university system. Most of the quality
imperative-supporting programmers/teachers left for sensible work--life
balance and salaries, leaving a much higher percentage of
declarative/functional-supporting folk in academia. These people
remember the 1980s and are now going in for the final victory of the
Paradigm Wars. Looks like something analogous is happening in the USA.
Did you fight in the Paradigm Wars?
Like Macdonald's bought the USA school system?
> I remember the 80's and by golly they were awesome and we are not
> talking the regular kind of awesome rather the double fireball attack,
> laser dynamite rocket underpants ninja nuclear plasma war rabbit kind
> of awesome. Except for the recession but I was a child so that wasn't
> my problem.
What I liked about the 1980s was that at UCL we were able to teach the
first course in programming for computer scientists using Miranda for 10
weeks then C++ for 10 weeks. I like to think we created a more rounded
sort of programmer than the current system does. Of course we taught
economists, physicists and chemists Fortran just as they asked. And C
to the electronics engineers, because they thought C++ was too airy
fairy -- classes, that not real code.
If it hadn't been for all the people taking sides based on politics and
"belonging to a particular group" then object-oriented would not be
where it is today.
Read Thomas Kuhn, "The Structure of Scientific Revolutions". The
Functional vs. Object-oriented Paradigm War is a wonderful paradigm of
exactly what he was putting forward as science.
On Mon, 2011-03-21 at 20:22 -0700, Cédric Beust ♔ wrote:
[ . . . ]
>[ . . . ]
> It looks like whoever made that decision has a pretty big chip on
> their shoulder and it's pretty clear from that sentence alone that
> students going to his/her class will get a pretty incomplete and
> biased picture.
>
I think we can see fallout from the 1980s. Then it was Imperative vs.
Declarative but rather than coming to any sane resolution, the battle
evolved into Functional vs Object-oriented. Of course C was what people
who weren't using Pascal, Fortran, Ada, Modula-2, Smalltalk, etc. were
using and thus C++ became the poster child of object-orientation. Which
in itself is a bit strange as the object-oriented of C++ wasn't the
object-oriented that the object-oriented folk were fighting for!
In the UK, successive governments have over the last 20 years tried to
destroy the university system. Most of the quality
imperative-supporting programmers/teachers left for sensible work--life
balance and salaries, leaving a much higher percentage of
declarative/functional-supporting folk in academia. These people
remember the 1980s and are now going in for the final victory of the
Paradigm Wars. Looks like something analogous is happening in the USA.
Did you fight in the Paradigm Wars?
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
> My experience is that most folk familiar with FP are still thinking of
> it in terms of imperative vs declarative, and only those firmly
> entrenched in C++ and its offspring seem to think that OO is somehow
> the opposite to FP.
And then there is "applicative" which for a while appeared to be
distinct from "declarative" and "functional". That's the problem with
jargon, there is an awful lot of it, and each clique defines it
differently ;-)
> In many ways, declarative programming *has* become wildly successful,
> and was almost guaranteed to be used in any system with a data storage
> requirement prior to the NoSQL movement - making it more widely
> adopted than Java, C++, C#, etc. Even now, all the NoSQL alternatives
> that I've seen have a declarative query syntax, with SQL already
> having proved the power of this paradigm when it came to clustering,
> sharding, and other such requirements for an application to scale
> outwards.
As we know C++ template programming is functional programming, so much
of C++ is functional :-) Also of course the whole STL generic
programming and especially generic functions has made a huge difference
to C++ such that declarative is a massive factor. Unlike Java which
chose to ignore iterators à la C++ -- another paradigm war but this one
was fought in the late 1990s. Joshua Bloch has at least acknowledged
that the Java Collections framework took the wrong architectural
decision; that the JGL architecture would have been far superior. I
even wrote the beginnings of a algorithms and data structures library
myself mixing the best of all bits. Of course it went nowhere because
Sun was a bit of a steam roller enforcing "right thinking" about Java.
And then there is Functional Java.
> As for the OO that folk were originally asking for; independent units
> that communicate by message passing, we now have it. That particular
> style is now known as actors, and the current showcase for the
> technique is Erlang, typically considered to be an FP sort of a
> language. It does amuse me how these things so often come full
> circle...
But actors pre-date object-oriented by about 10 years. It still
irritates me that C++ rejected message passing in favour of some
doublethink about function call being equivalent to message passing.
Long live active objects! Pool-T, UC++, KC++ rule . . .
Unlike Java which
chose to ignore iterators à la C++ -- another paradigm war but this one
was fought in the late 1990s.
Joshua Bloch has at least acknowledged
that the Java Collections framework took the wrong architectural
decision;
I think he is referring to the fact that iterators were not an
original part of the collections framework.
On 23 Mar 2011 20:53, "Cédric Beust ♔" <ced...@beust.com> wrote:
>
>
>
> On Wed, Mar 23, 2011 at 1:23 PM, Russel Winder <rus...@russel.org.uk> wrote:
>>
>> Unlike Java which
>> chose to ignore iterators à la C++ -- another paradigm war but this one
>> was fought in the late 1990s.
>
>
> First of all, before the enhanced for loop came out, Java was using iterators pretty much everywhere in collection loops:
>
> for (Iterator it = collection.iterator(); it.hasNext(); ) {
> Object o = it.next();
> }
>
> This followed the techniques made popular by the STL, but it was seen as not just a lot of boiler plate but also exposing users to needless implementation details: if all you want is enumerating the objects in a collection, why should you even care about the concept of iterators?
>
> Thus, the enhanced for loop was born:
>
> for (Object o : collection) {
> ...
> }
>
> No more iterators, much easier to read, and the only objects involved in this construct are the ones you care about: the collection and the objects it contains.
>
Of course there are iterators, they're just made implicit through a bit of syntactic sugar. Ultimately, the name of this construct is a dead giveaway, it's a for "loop".
The thing is fundamentally imperative, and only has value through iterating over every element in a collection and optionally performing some side effect. If it were to return a value of some sort, then it's possible to imagine a future version of Java in which iterators weren't involved, but that simply ain't the case right now.
My point was that the interface of Iterator, and Enumerator before it,
was the wrong choice. This implements forward iterator which is very
restrictive -- especially if what you really want is bidirectional
iterator or random access iterator.
> This followed the techniques made popular by the STL, but it was seen
> as not just a lot of boiler plate but also exposing users to needless
> implementation details: if all you want is enumerating the objects in
> a collection, why should you even care about the concept of iterators?
No, Collections did not follow STL. Iterator (and indeed Enumerator
before it) didn't learn the lessons of STL at all. The STL has a far
richer view of iterator than Collections offers. It was JGL that tried
to realize this richness, as did my own ADS -- a library created to
teach all this stuff to students -- Collections ignored all the
knowledge of how to use iterators in C++ that STL had built up.
You cannot build up the rich generic programming style that the C++
iterator infrastructure allows based only on forward iterator. This is
why JGL (and ADS) were created. However, Collections was the standard,
so JGL died. The story of ADS is for another place.
>
> Thus, the enhanced for loop was born:
>
>
> for (Object o : collection) {
> ...
> }
Well this (or at least something like it) should have been in Java in
the first place. This idiom was already in many languages in the early
1990s, but the Oak/Java folk chose to stick to the very low-level view
of iteration. They should perhaps have talked more to the Self folk
who apparently were in the next door offices.
>
> No more iterators, much easier to read, and the only objects involved
> in this construct are the ones you care about: the collection and the
> objects it contains.
If all you want is a forward iterator. In the cases where you want
that, foreach is ideal -- witness that most languages have this
construct these days.
>
>
> Joshua Bloch has at least acknowledged
> that the Java Collections framework took the wrong
> architectural
> decision;
>
>
> Uh, citation? We came up with the enhanced for loop precisely to hide
> iterators, so I still claim that the enhanced for loop is a big
> improvement over what we had before.
I am not disagreeing with this for the one use case of forward iteration
over the whole container -- which happens to be a majority use case and
so crucially important. However, it is not 100% of the use cases, so
other iteration structures are needed. C++, D, etc. provide that richer
iteration framework, Java does not. java.util.Iterator is and always
will be a forward iterator that does not provide a rich enough iteration
structure to provide the generic programming as seen in C++, D, etc.
>
> Or are you referring to something else?
Personal communication, JavaOne 2004.
I finally met up with Neal Gafter, with whom I had been having various
email exchanges over the previous 8 years, on the Sun stand and Joshua
Block was there as well. The conversation naturally turned to
Collections and thence to the iterator structures. Paraphrased
Joshua's comment was "I am happy with the way things are going forward,
but if I were to do it again, I would probably do it differently, more
like STL."