Tying to come back at a bad professor

[tomwilde]

Hi gophers,

Slightly off-topic but involves Go (and C):

Professor: "who knows what the main difference between Java and C is?"

Student: "Java is object-oriented and C is not."

Professor: "Correct, C does not support classes."

Me: "I disagree; a language not having classes does not make it any more or less object-oriented than Java."

Professor: "You're wrong; OO equals classes."

Me: "Counter-examples; JavaScript, Go."

Professor: "An object oriented language supports classes and operator overloading. Hence C is by definition not object-oriented."

Me: "Does Java have operator overloading?"

Professor: "I don't know and I don't care. C is procedural and procedural is the opposite of Object-oriented."

(Personal opinion: the term "object-oriented" has no place in a higher education establishment.)

This professor also taught us that C is "sometimes" pass-by-reference and made it clear that variables are pointer values.

As you might guess, I'm pissed and I'm looking for any citation (or a benevolent high-profile gopher who's willing to create one for me) that corroborates my standpoint.

Any and all contributions are greatly appreciated.

Tom

[Rob Pike]

Drop the course, but first you might say:

Smalltalk has no classes but may be the most object-oriented language
of all time. Alan Kay (designer of original Smalltalk, coiner of the
term "object-oriented") would support that position, although it's
hard to find a citation that expresses his definition precisely.

Procedural and object-oriented are orthogonal.

C is always pass-by-value. Always.

-rob

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Thomas Bushnell, BSG]

On Tue, Sep 16, 2014 at 2:04 PM, Rob Pike <r...@golang.org> wrote:

Drop the course, but first you might say:

Smalltalk has no classes but may be the most object-oriented language
of all time. Alan Kay (designer of original Smalltalk, coiner of the
term "object-oriented") would support that position, although it's
hard to find a citation that expresses his definition precisely.

I think he was most interested in dynamic dispatch and things that get called "duck typing" today; by his lights, I think C++ would not be object-oriented.

But in what sense do you mean that Smalltalk has no classes? It has things it calls classes, metaclasses, class variables, and so forth, and invented most of those concepts.

Thomas

 

[Jesper Louis Andersen]

The old "Rees on OO" answer is also good. Originally written by Jonathan Rees, it dissects the maze that is the term OO:

http://www.paulgraham.com/reesoo.html

I would recommend you find a professor who actually knows what he is talking about when discussing the merits or lack thereof of language concepts.

--
J.

[Rob Pike]

I oversold due to fading memory. But I stand by the fundamental point.
In C++ you don't add 3 to 2 by sending 2 a message.

-rob

[Thomas Wilde]

Thank you guys so much.

This community is truly spectacular; I vented, made a pizza, came back and had 3 meaningful, to-the-point replies.

Makes me proud to be a gopher.

[Aram Hăvărneanu]

> This community is truly spectacular; I vented, made a pizza, came back and
> had 3 meaningful, to-the-point replies.
>
> Makes me proud to be a gopher.

Where can I get some pizza?

--
Aram Hăvărneanu

[Thomas Wilde]

Call Gorgio, the pizzaiolo gopher! :)

[Dan Kortschak]

Wrong for so many reasons. Others have detailed the language taxonomy issues, but (speaking as as a lecturer) a teacher who is not prepared admit error or enter into discussion is not a teacher in anything except name. You do not want to continue with this course unless it is a requirement for your programme.

--

[Skip Tavakkolian]

PizzaFactory?

[Devon H. O'Dell]

We found that people wanted different types of pizzas, so a single
pizza factory was not sufficient. So we came up with the pizza factory
factory.

[Qian Qiao]

On 16 September 2014 18:49, Devon H. O'Dell <devon...@gmail.com> wrote:

We found that people wanted different types of pizzas, so a single
pizza factory was not sufficient. So we came up with the pizza factory
factory.

2014-09-16 15:48 GMT-07:00 Skip Tavakkolian <skip.tav...@gmail.com>:

> PizzaFactory?
>
>
> On Tue, Sep 16, 2014 at 2:25 PM, Aram Hăvărneanu <ara...@mgk.ro> wrote:
>>
>> > This community is truly spectacular; I vented, made a pizza, came back
>> > and
>> > had 3 meaningful, to-the-point replies.
>> >
>> > Makes me proud to be a gopher.
>>
>> Where can I get some pizza?
>>
>> --
>> Aram Hăvărneanu

You mean the IDistributedInjectedAsynchronousJdbcPizzaFactoryBuilderProducerImpl?

-- Joe

[Devon H. O'Dell]

No impl, we just sell plans.

[akwillis]

I'd argue that OOP is paradigm so abstract that any debate about it would be restrictly opinionated. But I'd argue the fundamentals would be messaging/methods and encapsulation. 

I'd argue that java is a metamodel of many independent concepts - Encapsulation, Polymorphism, Inheritance, Messaging, Data, etc.

I'd argue that classes are an independent model - a schema/semantic data model.

[akwillis]

I'd also argue that java 8 incorporates both functional and OO within the same data model(classes).

[Jesper Louis Andersen]

On Wed, Sep 17, 2014 at 2:28 AM, akwillis <akwi...@gmail.com> wrote:

I'd argue that OOP is paradigm so abstract that any debate about it would be restrictly opinionated. But I'd argue the fundamentals would be messaging/methods and encapsulation. 

The underlying problem is that the concepts are *extremely* fuzzy. Before you can engage in a meaningful conversation about OOP you need to spend about 15 minutes just trying to gather what the rules of the game are. Everyone has their own view of what OOP encompasses and what it is not. The case in point is one opinionated professor.

Once you latch onto "the" definition of yours, you invariably end up rejecting certain programming languages which people in general call OO in a form or fashion. Unless--and this is the crux--your definition is so weak it doesn't matter.

A good list of languages to study:

* Smalltalk

* Modula-3 (In general: If Luca Cardelli has been involved, look at it :) - Modula 3 is interesting for a lot of features. Maybe the language feels "clunky" by todays standards, but there were so many good ideas in this language.

* Standard ML - The module systems of Standard ML and OCaml are currently the leaders in the area of advanced module systems. The basics stems from a 1986 paper by David MacQueen. The expressiveness of these systems are not surpassed by anything yet, but few understand their beauty.

* Common Lisp - study CLOS, which goes much father than a single dispatch/inheritance scheme of more standard languages.

* Self - Javascript can also be used, but Self is closer to the roots

* Go - While OCaml had structural subtyping long before Go was created, the idioms of Go is to exploit structurality all the time, whereas OCaml programmers tend to avoid the concept on the grounds that other language features are better at expressing abstraction.

* Java - essentially a cleaned up C++ model

* C++ - Because it is not the OOP system alone, but rather its interaction with other language features. Notably parametric polymorphism at the type level (read: templates).

* Erlang - you can argue that actors are *the* implementation of the OOP model and everyone else are wrong. Totally wrong. Depending on which features you pick from the a la carte recipe by Rees, this statement is either true or false.

I tend to find Ruby and Python to be boring implementations, which are mostly covered by other languages in the above.

--
J.

[akwillis]

On Tuesday, September 16, 2014 8:52:17 PM UTC-4, Jesper Louis Andersen wrote:

On Wed, Sep 17, 2014 at 2:28 AM, akwillis <akwi...@gmail.com> wrote:

I'd argue that OOP is paradigm so abstract that any debate about it would be restrictly opinionated. But I'd argue the fundamentals would be messaging/methods and encapsulation. 

The underlying problem is that the concepts are *extremely* fuzzy. Before you can engage in a meaningful conversation about OOP you need to spend about 15 minutes just trying to gather what the rules of the game are. Everyone has their own view of what OOP encompasses and what it is not. The case in point is one opinionated professor.

I'd argue that the OO model is nothing more and nothing less than messaging/methods and encapsulation and that any view of a model that has more is over complicated or any model that has less is not OO - that would be my opinion.

I'd argue that classes are a data model independent of the OO model, and that would be my opinion.

Once you latch onto "the" definition of yours, you invariably end up rejecting certain programming languages which people in general call OO in a form or fashion. Unless--and this is the crux--your definition is so weak it doesn't matter.

Languages can be many things. If the language lacks encapsulation and messaging than its not OO,and if the language incorporates more than its OO+ (for the sake of simplicity regarding the topic), and that would be my opinion.

The real crux is that opinions don't matter and that was the point I made in the first sentence, but if I were to argue then that would be that the professor is over-complicating the OO model, and I touched on that point in the second sentence. I also gave a few other opinions which could be used against the professors opinion.

 

[N. Riesco - GMail account]

I'm going to play devil's advocate here by quoting the proverb: "When the wise man points to the moon, all the fool sees is the finger".

In this case the finger is bickering about whether the OO label applies or not. And the moon is understanding what concepts have been implemented in a given language.

It is a sad truth that bad teachers can handicap the learning of good students. But it also sadly true that a bickering attitude may hinder the learning process.

[Geoffrey Teale]

It's also worth remembering the price of being right.

Education should be about learning how to learn, and make reasoned investigations of your own.  Sadly, that isn't what most educational establishments offer.  Be happy in yourself that you have understood something more deeply, but remember also that the professor knows the curriculum and when you're faced with an examination you'd do well to remember the view, no matter how skewed, he/she presented.  I learned the hard way, from my economics professor.  Arguments he agreed with weak arguments and poor references scored higher marks than reasoned debate and references to the works of eminent economists who also dissented form his view and the curriculum.  He even told me that such debates had no place in the teaching of economics and were for postgraduates only.  I'm arrogant enough to think it was a brush off, but in either case, he held the power, and getting a good grade meant agreeing.

When you graduate you can go away with your credentials and be right in your own space ;-)  

-- 

Geoff Teale

--

[egon]

One quite good article about the meaning of OO, is "The Quarks of Object-Oriented Development" [1], which summarizes the different concepts people use to describe OO.

[1] http://agp.hx0.ru/oop/quarks.pdf

[tomwilde]

I agree with you in the general case. 

I'm open to people having different ideas about the term "OO" I don't care if you call your favorite language OO or not; it's a highly-disputed topic. Everybody knows that. However, if you're a professor at a university and you really decide to "go there" and touch the topic then you better be open to discussion and not present your own view of it as an absolute fact to your students.

Additionally, if you're supposed to teach C you better understand that a variable name, a pointer and an L-value are different things. Mixing them up creates a false perception of abstraction. I am convinced the professor does not understand these concepts because he explicitly wrote "C: pass-by-value and pass-by-reference" on his slides.

I'm aware I'm taking a risk by talking back but I guess that's just who I am. I talk back.

[Tahir]

Maybe he meant to talk about passing the value of a pointer and dereferencing  in the function body ? :p

[egon]

On Wednesday, 17 September 2014 03:52:17 UTC+3, Jesper Louis Andersen wrote:

Forgot to add more confusion into the topic :) ...

One could argue that Java/C++ are not Object-Oriented, but rather Class-Oriented, because the primary design tool is Classes and not Objects. ( http://www.infoq.com/interviews/coplien-dci-architecture )

+ egon

[Michael Jones]

Excellent language list. I'll add one for historical completeness: Simula 67. Dahl and Nygaard came up with objects, classes and subclasses, inheritance, and abstract/virtual methods all in one language. This was the first expression of the ideas and encouraged many other language designers and language efforts.

--

[Bakul Shah]

Nygaard's later programming language Beta is also worth studying. It was built around one concept: patterns. A Beta pattern generalizes classes, procedures, generators etc. Consequently "advanced features" such as nested classes came for free. IMHO it was vastly superior to other class based languages but for various reasons it never took off.

[Responding to the comment about Erlang in Anderdon's message:]

Erlang is (supposedly) based on Hewitt's Actor model of concurrent computation. So calling actors as "*the* implementation of the OOP model" is rather funny! OOP is really just about organizing sequential computation. 

[Michael Jones]

Thanks! You taught me something. Just downloaded the Beta book:

http://cs.au.dk/~beta/Books/betabook.pdf

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[gerald...@gmail.com]

switch to coursera or udacity :)

https://www.coursera.org/

https://www.udacity.com/

[egon]

On Wednesday, 17 September 2014 20:10:14 UTC+3, Bakul Shah wrote:

Nygaard's later programming language Beta is also worth studying. It was built around one concept: patterns. A Beta pattern generalizes classes, procedures, generators etc. Consequently "advanced features" such as nested classes came for free. IMHO it was vastly superior to other class based languages but for various reasons it never took off.

[Responding to the comment about Erlang in Anderdon's message:]

Erlang is (supposedly) based on Hewitt's Actor model of concurrent computation. So calling actors as "*the* implementation of the OOP model" is rather funny! OOP is really just about organizing sequential computation. 

Taking Alan Kay's one of the comments about OOP:

Just a gentle reminder that I took some pains at the last OOPSLA to try to
remind everyone that Smalltalk is not only NOT its syntax or the class
library, it is not even about classes. I'm sorry that I long ago coined the
term "objects" for this topic because it gets many people to focus on the
lesser idea.

The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak
is all about (and it's something that was never quite completed in our
Xerox PARC phase). The Japanese have a small word -- ma -- for "that which
is in between" -- perhaps the nearest English equivalent is "interstitial".
The key in making great and growable systems is much more to design how its
modules communicate rather than what their internal properties and
behaviors should be. Think of the internet -- to live, it (a) has to allow
many different kinds of ideas and realizations that are beyond any single
standard and (b) to allow varying degrees of safe interoperability between
these ideas.

...

http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

+ egon

[Michael Jones]

Excellent choice of quotes. Alan is a friend. He and my long-time buddy David Smith built Croquet (http://en.wikipedia.org/wiki/Croquet_Project) based around a fascinating generalization of the message passing idea -- time stamped across networks -- which allows massively shared environments where all events are in lock step: a shared, dynamic, collaborative space. Quite the feat, small, and fast. The quote you chose anticipates this with the key observation about the systemic importance of loose coupling in design, be it OOP, Unix pipes and filters, or physical construction from screws and bolts to Le Corbusier's modulor. 

[Eric Johnson]

Straight out of school, in my first programming job, one of the software architects at the company shared with me:

"All taxonomy is arbitrary." That definitely applies here.

Being married to a professor, I suggest you might have a little bit more patience for your professor. For the rest of the class (but apparently not you!), pedagogically, the professor needs to construct a taxonomy by which the rest of the students can start to understand the universe of languages. Only having done that, and then by understanding the limitations of that taxonomy, can the professor then come back and challenge the students to understand how the taxonomy itself might be refined/replaced. Part of learning is making mistakes, and learning from those mistakes, but you have to start somewhere!

More thoughts below.

On Tuesday, September 16, 2014 1:57:58 PM UTC-7, tomwilde wrote:

Hi gophers,

Slightly off-topic but involves Go (and C):

Professor: "who knows what the main difference between Java and C is?"

Student: "Java is object-oriented and C is not."

Professor: "Correct, C does not support classes."

Me: "I disagree; a language not having classes does not make it any more or less object-oriented than Java."

You're being too pedantic. What is possible in a language is radically different from what a language facilitates. C does not facilitate good object-oriented design, even if it can be used that way.

At least for the rest of the class, I think the professor got this answer right.

 

Professor: "You're wrong; OO equals classes."

Me: "Counter-examples; JavaScript, Go."

My take - now both the professor and you are wrong. Object oriented does not mean "classes" (although that might be a rough approximation). However, for your counter-examples, Javascript is a prototype-based language, and Go is a structure-based language. This starts to eat at the very question of how you define your taxonomy of languages.

To me, the answer to the question of whether Go is object oriented is part of the beauty of Go. Go forced me to rethink my language categories, so I don't think of it as object oriented, because that would lead me to think more narrowly about its capabilities than it deserves.

Professor: "An object oriented language supports classes and operator overloading. Hence C is by definition not object-oriented."

Me: "Does Java have operator overloading?"

Professor: "I don't know and I don't care. C is procedural and procedural is the opposite of Object-oriented."

Professor clearly annoyed at student. Said something imprecise to dismiss discussion, because class time was being taken up by discussions that were irrelevant to the overall point.

 

(Personal opinion: the term "object-oriented" has no place in a higher education establishment.)

Disagree again. Object oriented is a perfectly good architectural style to understand and leverage (as you imply, it is even possible to leverage in languages that don't facilitate it, such as C). In the early days of languages, architectural styles were strongly associated with languages, whereas now, we've learned that the best languages facilitate multiple architectural styles.

 

This professor also taught us that C is "sometimes" pass-by-reference and made it clear that variables are pointer values.

Partially one of perspective - are you talking about the container, or the thing being contained? Rob Pike says this more elegantly than I can, so I won't try.

Keep in mind the professor has a very difficult challenge here - teaching the meaning of pointers. Pointers apparently trip some people up in the early phases of learning programming. You're apparently not one of those people (I wasn't either). So perhaps you're being too hard on the professor for trying to introduce a subject in a particular way. The professor may have learned his/her approach brings along those students that typically have trouble.

I was bored out of my skull in an Econ class once, because the professor spent two (or more?) class periods essentially bringing the rest of the class up to speed on the derivation of the (mathematical) first derivative of an equation. Since I'd mastered derivatives three years prior, this was relatively confusing at first, and annoying once I understood what the professor was doing. But it was essential pedagogically to bring the rest of the class along to understand the rest of the semester.

 

As you might guess, I'm pissed and I'm looking for any citation (or a benevolent high-profile gopher who's willing to create one for me) that corroborates my standpoint.

Any and all contributions are greatly appreciated.

What I see is evidence that you're in a class that is too introductory for your skills. Move to a higher-level class. Don't blame the professor, and don't waste your energy being pissed at the professor, because you can put that energy to better use learning doing something productive, like writing more Go code.

Eric.

[Dan Kortschak]

I think this is an extremely overly generous response wrt the approach taken by the lecturer. It is easy to parenthetically say that the situation is more complex than initially being presented, an to not enter into an argument that will construct obviously erroneous misconceptions (difficult to eradicate later) in the weaker students. From the description here, the lecturer performed extremely badly - much more like a school teacher than a university lecturer.

On 18/09/2014, at 4:36 AM, "Eric Johnson" <er...@tibco.com> wrote:
.

[Bakul Shah]

To explain my earlier one liner:
Managing complexity is orthogonal to concurrent programming.
No matter how you slice and dice (organize) your concurrent
program, you're still left dealing with shared memory +
semaphores/mutexes + threads or pipes/channels + messgaes/RPCs
+ threads/processes. So in a sense OOP brings nothing to the
concurrent programming party! Except distraction.

The big idea is not just messaging but concurrency & messaging
together (may be that is what Alan Kay implied). And we still
don't have a good handle on managing/debugging concurrency.
We still use printfs and logs to probe what may be going on!
May be we can use a race detector in a single Go program but
we are at sea when it comes to debugging distributed systems.
[and even if you build a "provably correct" distributed system,
things can still go wrong so can't get away from debugging]

On Wed, 17 Sep 2014 11:12:15 PDT "'Michael Jones' via golang-nuts" <golan...@googlegroups.com> wrote:
>
> Excellent choice of quotes. Alan is a friend. He and my long-time buddy
> David Smith built Croquet (http://en.wikipedia.org/wiki/Croquet_Project)
> based around a fascinating generalization of the message passing idea --
> time stamped across networks -- which allows massively shared environments
> where all events are in lock step: a shared, dynamic, collaborative space.
> Quite the feat, small, and fast. The quote you chose anticipates this with
> the key observation about the systemic importance of loose coupling in
> design, be it OOP, Unix pipes and filters, or physical construction from

> screws and bolts to Le Corbusier's *modulor*.

>
> On Wed, Sep 17, 2014 at 10:58 AM, egon <egon...@gmail.com> wrote:
>
> >
> >
> > On Wednesday, 17 September 2014 20:10:14 UTC+3, Bakul Shah wrote:
> >>
> >> Nygaard's later programming language Beta is also worth studying. It was
> >> built around one concept: patterns. A Beta pattern generalizes classes,
> >> procedures, generators etc. Consequently "advanced features" such as neste
> d
> >> classes came for free. IMHO it was vastly superior to other class based
> >> languages but for various reasons it never took off.
> >>
> >> [Responding to the comment about Erlang in Anderdon's message:]
> >> Erlang is (supposedly) based on Hewitt's Actor model of concurrent
> >> computation. So calling actors as "*the* implementation of the OOP model"
> >> is rather funny! OOP is really just about organizing sequential
> >> computation.
> >>
> >
> > Taking Alan Kay's one of the comments about OOP:
> >

> > *Just a gentle reminder that I took some pains at the last OOPSLA to try to

> > remind everyone that Smalltalk is not only NOT its syntax or the class
> > library, it is not even about classes. I'm sorry that I long ago coined the
> > term "objects" for this topic because it gets many people to focus on the
> > lesser idea.
> >
> > The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak
> > is all about (and it's something that was never quite completed in our
> > Xerox PARC phase). The Japanese have a small word -- ma -- for "that which
> > is in between" -- perhaps the nearest English equivalent is "interstitial".
> > The key in making great and growable systems is much more to design how its
> > modules communicate rather than what their internal properties and
> > behaviors should be. Think of the internet -- to live, it (a) has to allow
> > many different kinds of ideas and realizations that are beyond any single
> > standard and (b) to allow varying degrees of safe interoperability between

> > these ideas.*
> >
> >
> > *...*
> >
> >
> >
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.
> html

> *Michael T. Jones | Chief Technology Advocate | m...@google.com
> <m...@google.com> | +1 650-335-5765 <%2B1%20650-335-5765>*

[tomwilde]

On Wednesday, September 17, 2014 9:06:15 PM UTC+2, Eric Johnson wrote:

Straight out of school, in my first programming job, one of the software architects at the company shared with me:

"All taxonomy is arbitrary." That definitely applies here.

I could not agree more with that statement.

 

As for the rest; I'm sure the professor's job is not easy but I've had other professors teach me Haskell and Java and they all deliberately watched their vocabulary as not to make any false assertions or implications, even when explaining something basic (that's a pretty hard thing to do out of the blue, especially the implications part.) If this lead to confusion or protest, they'd take the time to explain it in another 3 ways which also did not infringe the truth.

The class in question is systems programming (!), which is compulsory and is supposed to teach me to architect structures where there are none. That's a pretty bad start, wouldn't you agree? Maybe it's just not the guy's vocation.

[Jesper Louis Andersen]

On Wed, Sep 17, 2014 at 7:09 PM, Bakul Shah <ba...@bitblocks.com> wrote:

Erlang is (supposedly) based on Hewitt's Actor model of concurrent computation. So calling actors as "*the* implementation of the OOP model" is rather funny! OOP is really just about organizing sequential computation. 

Actually, this is a misconception.

1. The Erlang Authors, Williams, Armstrong and Virding did not have the actor model in mind when they built the initial language design. I can basically cite all of them as "private conversation" in this regard :)

 

2. Hewitt himself does not recognize Erlang as an Actor language: http://arxiv.org/pdf/1008.1459.pdf though he is slightly wrong on both accounts:

* Erlang has an asynchronous exception mechanism. Actually it has two: links and monitors. These allow the forming of "webs" of processes such that if one terminates, the web untangles and all accompanying processes terminate or gets notified. The details of why there is two is mostly historical: one is bidirectional and the other is not.

In the context of Go, the way to achieve some of the same properties is to use Google's recently released Context package: http://blog.golang.org/context though the semantics are vastly different from what Erlang provides. It is good that we now, as Go programmers, recognize the need for proper goroutine hierarchy termination.

* Second, Hewitts point is that Erlang processes are not automatically garbage collected. This is true: if an erlang process is spawned and never communicates with anyone, it represents a memory leak unless it terminates itself. But properly designed Erlang systems tie any spawned process into a supervision tree so they can be forcefully terminated once that part of the supervision tree terminates.

I think the problem is somewhat the same in Go. You need to bind some kind of termination into your goroutine fabric to make sure you don't accidentally lose your goroutines. Again, this is the purpose of package context.

--
J.

[Michael Jones]

Pure genius parodies taxonomic zealotry:

http://en.wikipedia.org/wiki/Celestial_Emporium_of_Benevolent_Knowledge

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765