Forwarded conversationSubject:
[Lisp] goodbye OOP
------------------------
From: heow <lists@alphageeksinc.com>
Date: Mon, Mar 21, 2011 at 11:10 AM
To: LispNYC <lisp@lispnyc.org>
For good reason, CMU is dropping mandatory OOP from it's CS curriculum:
http://www.infoq.com/news/2011/03/oop-out-at-cmu
_______________________________________________
Lisp mailing list
Lisp@lispnyc.org
http://www.lispnyc.org:8080/mailman/listinfo/lisp
----------
From: Raymond de Lacaze <delaray@hotmail.com>
Date: Mon, Mar 21, 2011 at 11:38 AM
To: Lisp NYC <lisp@lispnyc.org>, Heow Eide-Goodman <heow@alphageeksinc.com>
Cc: Lispers Meperia <lisp-dev@meperia.com>
Heow,
I was going to say "Oh, well!", but I guess the appropriate response is "Oops!"
:-)
Ray
> Date: Mon, 21 Mar 2011 11:10:03 -0400
> From:
lists@alphageeksinc.com> To:
lisp@lispnyc.org
> Subject: [Lisp] goodbye OOP
_______________________________________________
Lisp mailing list
Lisp@lispnyc.org
http://www.lispnyc.org:8080/mailman/listinfo/lisp
----------
From: Andrew Gwozdziewycz <apgwoz@gmail.com>
Date: Mon, Mar 21, 2011 at 11:40 AM
To: Raymond de Lacaze <delaray@hotmail.com>
Cc: Heow Eide-Goodman <heow@alphageeksinc.com>, Lisp NYC <lisp@lispnyc.org>, Lispers Meperia <lisp-dev@meperia.com>
I really wish I could publicly favorite this email.
--
http://www.apgwoz.com
_______________________________________________
Lisp mailing list
Lisp@lispnyc.org
http://www.lispnyc.org:8080/mailman/listinfo/lisp
----------
From: fire crow <fire@firecrow.com>
Date: Mon, Mar 21, 2011 at 11:42 AM
To: heow <lists@alphageeksinc.com>
Cc: LispNYC <lisp@lispnyc.org>
Awesome,
modularity is so much easier to teach in functional, then with oop can
be just a tool, which is nice cause opp encourages a lot of bad habits
in beginning programmers, who make more objects to solve every
problem.
~fire
--
+
| fire crow
| computer programmer
!_____________________
http://firecrow.com, fire@firecrow.com, 917.306.9451, New York City, USA
----------
From: Heow Goodman <lists@alphageeksinc.com>
Date: Mon, Mar 21, 2011 at 1:13 PM
To:
Cc: Lisp NYC <lisp@lispnyc.org>, Lispers Meperia <lisp-dev@meperia.com>
Great idea!
https://www.facebook.com/group.php?gid=19432875259 (LispNYC on FB)
- h
----------
From: Rahul Jain <photinodecay@gmail.com>
Date: Wed, Mar 23, 2011 at 12:21 AM
To: fire crow <fire@firecrow.com>
Cc: LispNYC <lisp@lispnyc.org>, heow <lists@alphageeksinc.com>
People don't learn modularity when they're taught using FP either. It's discipline you learn via hard knocks, and paradigm used is basically irrelevant. Unless you're talking about ML... and teaching people about type inference and the edge cases missed by H-M inference is not first-year CS.
_______________________________________________
Lisp mailing list
Lisp@lispnyc.org
http://www.lispnyc.org:8080/mailman/listinfo/lisp
----------
From: Shaneal Manek <smanek@gmail.com>
Date: Wed, Mar 23, 2011 at 12:37 AM
To: Rahul Jain <photinodecay@gmail.com>
Cc: LispNYC <lisp@lispnyc.org>, heow <lists@alphageeksinc.com>
I think that the lack of global or mutable state (which is encouraged
by FP) naturally leads to less tightly coupled and more modular code.
History has shown that tools/features you can gently curb developers
towards writing more readable/maintainable code (even if they don't
necessarily understand or appreciate it right away). It's obviously
possible to write terrible code in any language, and it's possible to
write great code in any language. But I think most people would agree
that the average newbie Python developer's code is 'better' than the
average newbie Perl developer's code.
-Shaneal
----------
From: Rahul Jain <photinodecay@gmail.com>
Date: Wed, Mar 23, 2011 at 12:49 AM
To: Shaneal Manek <smanek@gmail.com>
Cc: LispNYC <lisp@lispnyc.org>, heow <lists@alphageeksinc.com>
But the data structure designs used in python are representative of OOP and in perl, they are representative of FP :)
Lack of mutability of state doesn't lead to modularity when the state itself is represented in a non-abstracted way (more specifically, abstracted at the wrong level, e.g. using linked list operations to deal with fixed-size data structures).
It's easy to tell people not to use mutable state for interim results. It's easy to tell people to use ADTs. It's hard to teach the discipline to get them to actually do either one, and giving them tools with more freedom allows them to learn discipline through mistakes (even better when there is someone pointing out the mistakes instead of letting them make them and hoping that they'll magically know when their code is not evolvable when they're throwing it away at the end of the task anyway).
_______________________________________________
Lisp mailing list
Lisp@lispnyc.org
http://www.lispnyc.org:8080/mailman/listinfo/lisp
----------
From: Marc Spitzer <mspitzer@gmail.com>
Date: Wed, Mar 23, 2011 at 1:56 PM
To: Rahul Jain <photinodecay@gmail.com>
Cc: heow <lists@alphageeksinc.com>, LispNYC <lisp@lispnyc.org>
Rahul,
your argument boils down to two points:
1: it is hard to teach people good habits
2: it is very hard to get people to unlearn bad ones
This is generally true, but if you set up an environment where you can
not have bad habits as you teach good ones you are orders of magnitude
ahead of the game. Think George Orwell, if you do not have a word for
it it is much harder to come up with the concept. I think the idea
that cmu is pushing is that if we put the right way into their head
*AND* give them no alternative but to do it that way it will take root
and grow. years later when in industry they will have much less
temptation to do something bad/ugly because they have much less need
to do so having he mental tools and experience that show that the bad
bit is not needed or at the least must be minimized, isolated and
watched as a known source of pain.
After all since freshmen do not have any meaningful experience they
should not be given dangerous technical choices.
marc
Freedom is nothing but a chance to be better.
--Albert Camus
The problem with socialism is that eventually you run out
of other people's money.
--Margaret Thatcher
----------
From: Rahul Jain <photinodecay@gmail.com>
Date: Wed, Mar 23, 2011 at 11:49 PM
To: Marc Spitzer <mspitzer@gmail.com>
Cc: heow <lists@alphageeksinc.com>, LispNYC <lisp@lispnyc.org>
Except eventually, they will be able to practice bad habits. Abstinence education does not reduce unwanted pregnancy or STDs... only increases them
_______________________________________________
Lisp mailing list
Lisp@lispnyc.org
http://www.lispnyc.org:8080/mailman/listinfo/lisp
----------
From: Scott Ostler <scottostler@gmail.com>
Date: Thu, Mar 24, 2011 at 1:08 PM
To: lisp@lispnyc.org
That analogy implies there's an instinctive human drive for
imperative/oo programming, which many
on this list might disagree with! Anecdotally, many seasoned
programmers report writing "cleaner" Java/Python/Ruby code after
learning Lisp/Haskell, suggesting that learning FP offers something
more than just additional programming experience.
There are many other explanations, to be sure. I don't know of
much hard evidence in any direction.
----------
From: Rahul Jain <photinodecay@gmail.com>
Date: Fri, Mar 25, 2011 at 8:55 AM
To: Scott Ostler <scottostler@gmail.com>
Cc: lisp@lispnyc.org
You are attributing other peoples' opinions to me. I never said anything of the sort. I said that there's an instinctive drive to writing BAD code in any paradigm because it requires less discipline and forethought. And yes, learning more than one paradigm allows one to look at the world in more ways and choose the one that is best suited for the task at hand. FP does not have a monopoly on good ideas. Thinking that OOP is bad just because Java/Ruby/Python are badly designed implies that Lisp is bad because OOP is bad.
_______________________________________________
Lisp mailing list
Lisp@lispnyc.org
http://www.lispnyc.org:8080/mailman/listinfo/lisp
----------
From: Yusuke Shinyama <yusuke@cs.nyu.edu>
Date: Fri, Mar 25, 2011 at 10:28 AM
To: Rahul Jain <photinodecay@gmail.com>
Cc: lisp@lispnyc.org, Scott Ostler <scottostler@gmail.com>
I'd rather say that students should be exposed to as many
dangerous ideas as possible from the beginning, as well as good
ones. I think the point of higher education is to teach
methodology, and not to teach a particular set of knowledge.
Personally, I don't think a student is becoming very bright if
he/she is not curious enough to be drawn toward silly ideas.
Constant exploration and experimentation is a must for any serious
profession.
In this respect, the things to teach students at their first year
seems pretty much a matter of taste, as they have to learn
many other things in coming years.
Yusuke
----------
From: Joe O'Donnell <galabad@yahoo.com>
Date: Fri, Mar 25, 2011 at 1:33 PM
To: Rahul Jain <photinodecay@gmail.com>, Yusuke Shinyama <yusuke@cs.nyu.edu>
Cc: lisp@lispnyc.org, Scott Ostler <scottostler@gmail.com>
Hello all, I suppose now is as good a time as any to delurk and start
sharing thoughts with this esteemed list. I appreciate greatly the idea
of focusing on teaching methodology, I don't think skepticism and
personally testing the roots of study material is respected enough in
many universities.
My ideal vision of higher education, would be one in which the
professor leads the student through guiding questions, readings and
exercises to discover the subjects cannon, step by step. This would
combine and balance teaching methodology, student experimentation and a
core curriculum through the interaction of the students curiosity and
skepticism with the professors experienced command of the subject.
I do think there is a core curriculum to learn in most subjects,
including computer science and programming, and I do think it's
critical to learn it. For example, would it be advisable for freshman
chemistry students to spend 2 months experimenting with the theory of
phlogistin?
I think the core first year subject of computer science and
programming should be the Lambda Calculus. Not in it's Church papers
forms right away, but in the 'form' of SICP or the more approachable
'Concrete Abstractions.'
The Lambda Calculus is programming in it's most reasonably usable
'turing complete' mathematical form. Lisp is the most powerful and
important programming language because it's a reasonable to program,
homoiconic, programmable programming language. The basic course of
study in SICP covers the programming fundamentals of both. Every
compsci student should be educated in those three critically important
and fundamental facts of computing. In my opinion, while McCarthy
didn't set out to build Lisp primarily as an applied Lambda Calculus, I
think that is more or less the gist of what he ended up with. Even if
Lisp soon became more of a hybrid language focused on the creation of
imperative like DSL's using 'special forms' created by 'macros.'
Although the hybrid direction of Lisp and it's culture led it mostly
Away from functional programming, and into the area of elite Common
Lisp industry programmers for whom OO is important for organizing
large/ish team/shared projects, imho it's important not to forget that
macros are reasonably possible because Lisp is homoiconic.
To jump in further with my first high falutin post: I think OO can and
should be taught as a state and modularity/code management technique
After the basics of algos,data structures and Lambda Calculus are
learned. What good is knowing how to manage state and modules/code for
example if one doesn't understand the procedural and recursive code
versions of Fib, the processes they produce, and the time and space
they use?
I think combinators, Haskell, type inference, monads, STM and the
curry-howard isomophism should be the second year curriculum. Ideally
the students would write a Haskell in Scheme. Haskell is one of the most powerful DSL's of Lisp, or rather at least should be.
Imho the general OO area is best learned first using ones own closure hash tables as a
basic state handling technique, and later using monads, and STM. That is the direction things
are going in.
Finally if your still reading, I have to say I think OO since it's start with Simula has mixed
up a kind of a primitive 'virtual machine', the class and object, into
what should be self contained chunks of functional code. I think OO
ultimately needs to be separated into 2 components: state management
(with monads and/or STM), and a formal methods usable protocol to
handle communication and relationships between virtual machines.
This is because OO as it is used now isn't much amenable to the bug avoiding nature of functional
programming, much less formal methods afaik, and imo that's important
for the future.
The convenience of OO inheritance and state management on a small
scale should probably be handled by composed sets of monads. Maybe CLOS can morph into that over time. I would
add that I'm not expecting this to happen tomorrow, or for Common Lisp
programmers to stop doing great code and state management things with
CLOS.
Regards,
Joe O'Donnell |
_______________________________________________
Lisp mailing list
Lisp@lispnyc.org
http://www.lispnyc.org:8080/mailman/listinfo/lisp
----------
From: Rahul Jain <photinodecay@gmail.com>
Date: Sat, Mar 26, 2011 at 10:34 AM
To: Joe O'Donnell <galabad@yahoo.com>
Cc: lisp@lispnyc.org, Scott Ostler <scottostler@gmail.com>
Just to comment on one thing, I think the ideal DSL is declarative in that it declares exactly the intent of the programmer at the level of abstraction that the target domain operates. Now whether that's a set of instructions and choices to be followed in order or if it's a set of logical assertions that must be maintained is simply a matter of what is appropriate for the target domain. OOP is just a declarative DSL in Lisp, for example, where some things that are declared (methods and method combinations) can have imperative code inside of them.
I do agree that first year students shouldn't care about these issues, and they should focus just on the concept of writing functions with relatively homogeneous data and data structures and understanding how to determine the performance and correctness and reliability of the code. In that respect, avoiding state is a good thing. Things like inheritance/polymorphism, type inference, and STM should be taught after a data structures and algos class, I think. Monads are a bit confusing. Maybe an optional 4th year course.
I also agree that OOP should separate the concept of defining a type, defining a namespace, and defining operations that are available. Fortunately, CLOS already does this, so it's a non-issue on this mailing list. :)
Both monads and STM are very interesting, especially monads as implemented for clojure, since those are dynamic monads rather than static monads. The most tedious aspect of monads in haskell simply disappears, but is replaced with the inability to get certain optimizations with them, IIRC, but I think those optimizations can be achieved if you simply switch paradigms in that part of the code. This is the beauty of lisp. Swiss army knife.
_______________________________________________
Lisp mailing list
Lisp@lispnyc.org
http://www.lispnyc.org:8080/mailman/listinfo/lisp
----------
From: Zachary Elliott <zacharyelliott1@gmail.com>
Date: Sat, Mar 26, 2011 at 3:46 PM
To: Rahul Jain <photinodecay@gmail.com>
Cc: lisp@lispnyc.org, Scott Ostler <scottostler@gmail.com>
Just for reference all, slashdot finally caught up with us Story about CMU
--
I enjoy the massacre of ads. This sentence will slaughter ads without a messy bloodbath.
_______________________________________________
Lisp mailing list
Lisp@lispnyc.org
http://www.lispnyc.org:8080/mailman/listinfo/lisp