
Why Arc Isn't Especially Object-Oriented (2002) - kuMei
http://www.paulgraham.com/noop.html
======
geofft
I think these two points are important. From the article:

> _Object-oriented programming is popular in big companies, because it suits
> the way they write software. At big companies, software tends to be written
> by large (and frequently changing) teams of mediocre programmers._

And from the linked analysis by Jonathan Rees:

> _This is related to Lisp being oriented to the solitary hacker and
> discipline-imposing languages being oriented to social packs, another point
> you mention._

I would guess that most of the world-changing programming work that can be
done is work that requires collaborating with other, unknown people. (But not
all! HN itself is a good counterexample, being the work of very few developers
and still having a significant influence on the world.) You'll write something
at a company, get reorged away (or leave for another job), and someone else
will launch it. You'll write some open-source library and years later someone
will make something cool with it. You'll contribute to an existing large-scale
project, because that gives you leverage you couldn't get from your own
project - perhaps because of an inability to replicate the technical
accomplishments of the project, but more likely an inability to replicate the
network effects of it already having users. You'll build a prototype of
something that proves something is doable, but gets significantly rewritten
before it goes into production.

If you're interested in these problems, it's in your interest to work in a
language that lends itself to other unknown people picking up your work and
running with it. If you want to make single-hacker scale projects that will
_not_ grow much beyond you, there's nothing wrong with that - but I think you
have to be either lucky or able to commit time for the next several years if
you want your project to get traction.

~~~
pdimitar
Why is there never a spectrum? Why is it always a "single-hacker project" vs.
"a huge project with tens or hundreds of contributors"? Why is it always in
these discussions that the concept of the functional languages gets hijacked
to "they are only used by hackers"? (And what does "hacker" even mean in this
context? The word has like 50 meanings already.)

This fabricated extreme dichotomy is killing the discussion. Every time. And
it's sad.

We the techies are supposed to be objective and act on a meritocratic basis. I
get very disappointed every time I see us just bickering over imaginary
strawmen.

~~~
geofft
I think the dichotomy is from 'pg in this case. I myself like using languages
with a balance between the two extremes - Python, being neither the
stereotypically enterprisey Java nor the stereotypically write-only Perl,
being a good example. They allow me to be productive with single-person
projects without overhead, and they're _also_ suited to being used for large-
scale projects once you start imposing some structure.

The only thing is you have to be willing to start imposing some structure at
some point, and the language has to make that easy, too. It can't be _solely_
suited for the single hacker; it can't have been designed under the assumption
that a language for use by large teams of people dispersed over time and space
is one designed for "mediocre programmers," and so the things such a language
values must be categorically avoided.

~~~
pdimitar
> _it can 't have been designed under the assumption that a language for use
> by large teams of people dispersed over time and space is one designed for
> "mediocre programmers,"_

I don't know why people find this an offensive statement. EVERY craft on this
planet has a pretty small (in terms of percentage) group of people who just
grok it and "get it" fantastically well, and everybody else in the profession
is pretty average. That's nothing to be offended at: the bell curve
distribution is in full effect there. Perfectly normal, no?

And I would argue with you that some languages -- Go being the most modern
example -- are _specifically_ designed to be an easy onboard for people with
certain backgrouns (C/C++/Java). That Java has been designed to be an easy
onboard for people with C/C++ experience is pretty much a documented
historical fact at this point as well.

Large companies optimize for quantity, not quality. There's nothing shameful
in admitting: "we need a horde of not-amazing programmers who we can treat as
interchangeable nuts and bolts"... yet everybody is denying it, when reality
clearly shows that's their exact attitude... really makes me wonder why people
keep insisting on keeping that circus alive and well (I also heard managers
speak of people like that, in expensive saunas and restaurants -- and they
were talking quite loudly). Most corporations don't need craftsmen and
artisans; they need prentices who build houses with already-made plans.

I am asking for the umpteenth time -- why is this such a bad thing to admit?
_We cannot all be amazing programmers in each and every way._ We have to stop
denying this reality.

> _I myself like using languages with a balance between the two extremes_

Same, that's why I code Elixir: it's FP alright but not "pure" \-- has side
effects but the edges are clearly documented. And we can't get anything done
without side effects anyway. So it's like 95% FP and 5% everything else, in
the right places. Perfect.

> _I think the dichotomy is from 'pg in this case._

I don't know enough about @pg to claim anything but whatever he said, that's
no excuse for everybody else to start gravitating into camps. When people ask
me "do you hate Java or do you hate C#?", you know what I say?

"I hate the people who hate programmers based on what they work with."

~~~
winrid
Because if they admitted it it would hurt public image right?

Also I do not think this is how you build a great company. It's one way to
build a company, but it's not a very good way for the long term.

~~~
pdimitar
Well I guess their PR would suffer, yeah. It just strikes me as so funny -- at
38 year old -- how so much of our world is pretending you don't do stuff for
reasons X and Y while _everybody_ knows you do those things for exactly those
reasons. It's absurd and funny.

As for how to build companies, I wouldn't know, not a big business owner. But
I am guessing from certain point and on they just want to commoditize stuff
and make their management easier and quicker. It all starts with good
intentions on paper and always ends up with horrific and dyfunctional teams. I
have only seen 3 exceptions for 17 years of career of which 9.5 were spent in
offices.

------
payne92
One of the challenges I’ve found with OOP is that’s really easy (encouraged!)
to use a lot of “anti-functional” patterns.

A functional style is not the only way to write programs, but it’s often much
easier to reason about behavior when you’re not chasing side effects.

And OO implementations often have a LOT of side effects.

~~~
krapp
>And OO implementations often have a LOT of side effects.

If you're worried about side effects and want pure functional programming...
Arc is not the language for you.

~~~
dan-robertson
I think pure functional programming is often worse than a looser style which
one often wants. This is sometimes described as functional core, imperative
shell.

The idea is to try to keep state in values (rather than global variables) and
to update those values in a functional,typically immutable, maybe a sort of
careful mutable way. Then on the outside there is some global state of things
that are treated in an imperative way, eg setting up loggin, or a global
variable for “the state of the world”, or reading user inputs, processing, and
outputting.

IO is something that Haskell has to make a big deal about because it is lazy
and “pure.” One can think of it a bit like async in JavaScript: (most) IO
things are async and so an async function is one that does IO, just like any
function returning IO a in Haskell. I think in most programs structured with a
functional core, having IO in the core will typically mean having logging or
debug printing which I think is not really bad and not worthy of eg polluting
type signatures everywhere. Most meaningful IO should go in the outside,
topmost bits of the program because that’s where it belongs (rather than
because your language makes it so painful that you don’t want it any other
way).

I suppose my point is that I don’t think “pure functional programming” is
something one should want throughout a language.

~~~
pdimitar
> _I suppose my point is that I don’t think “pure functional programming” is
> something one should want throughout a language._

Yeah, same here. Haskell struck me as too strict and clunky to get basic stuff
done. Its focus doesn't seem to be productivity. Hence I gravitated towards
Elixir (and lately trying Clojure). It allows me to get stuff done in a small
number of lines, is amazingly well documented and has powerful primitives.

The pursuit of academic purity quickly turned me off of several languages,
Haskell included.

------
jfim
> My own feeling is that object-oriented programming is a useful technique in
> some cases, but it isn't something that has to pervade every program you
> write.

That could apply to pretty much any programming paradigm.

I wouldn't use object oriented programming for small programs. Why bother with
types when you can express things in a couple hundred lines of python with
functions? Why write classes to munge some data that could be better expressed
as a series of map/fold/etc. on lists of tuples?

However, for keeping large codebases approachable and maintainable, OOP is the
best paradigm I have personally seen.

~~~
fuzzy2
> I wouldn't use object oriented programming for small programs. Why bother
> with types when you can express things in a couple hundred lines of python
> with functions?

Hm? Types don't require OO. Even your 100 line program can benefit from type
checking.

Approachable code must be structured in a meaningful way. That doesn't require
OO either.

------
oconnor663
I'd say this more or less the mainstream view these days. Both Go (2012) and
Rust (2015) decided to do polymorphism with a trait system rather than
inheritance, for example.

~~~
krapp
Neither Go nor Rust are mainstream -- that's still C++, Java and Javascript.

~~~
oconnor663
Go is #12 on the TIOBE index, and by that measure more mainstream than Perl or
Ruby. If by mainstream you mean "the top 3-5 programming languages", then
you're not talking about anything invented in the last 20 years, which is
kinda the point.

------
discreteevent
William Cook's response to this is worth a read

[http://wcook.blogspot.com/2011/04/paul-graham-on-objects-
in-...](http://wcook.blogspot.com/2011/04/paul-graham-on-objects-in-
arc.html?m=1)

"Objects are just collections of first-class functions". " the lambda-calculus
was the first object-oriented language: all its data is represented
behaviorally as objects"

~~~
lmm
The lambda calculus is not an object-oriented language, because it does not
have hidden (mutable) state. Noticeably, the idea of using 'at-end? and 'read
messages goes wrong precisely when there's hidden mutable state behind
"stream" (e.g. some other thread consumes the stream in between the 'at-end?
and the 'read). As the saying goes, you wanted a banana but what you got was a
gorilla holding the banana and the entire jungle. That can't happen in the
lambda calculus.

------
aerovistae
I know Hacker news is hardly the place to disparage anything said by Paul
Graham, but I have to ask: is anyone else turned off by his constant reference
to "smart people"? Like in the first sentence of this essay, where he
immediately declares:

> There is a kind of mania for object-oriented programming at the moment, but
> __some of the smartest programmers I know are some of the least excited
> about it. __

Is that supposed to convince me? "Oh, well, if he knows some _smart_ people
who are against it, maybe I should stop liking it, too, because I definitely
want to fit in with the smart people Paul Graham knows."

It's such a common thing in Silicon Valley, it kills me. "Always be the
dumbest person in the room. Surround yourself with people smarter than you."
Like, do I have to ditch any old friends that don't make the cut? What does it
mean for someone to be "smarter than me"? Do they have to have a higher SAT
score? Do they have to play an instrument better than I do? Do they have to be
more financially successful? Can I still learn things from people who are less
successful than me?

I just really don't like the mentality of deeming someone "smart" and then
using their personal preferences as an inherent argument. That's the fallacy
of the argument from authority.

If you don't like OOP, great, carefully explain its shortcomings to me. And
perhaps he goes on to do that. I haven't finished reading yet. I just wanted
to stop after that first sentence and say that as an opener, I hate it.

~~~
Daishiman
However crappy it sounds, there _are_ people who have a hard time grasping
relatively simple programming concepts, and then there are also engineers who
are astoundingly intelligent and productive.

It doesn't necessarily have to be attributed merely to raw intellect, but
denying it isn't in line with reality.

Having worked at many different companies you can definitely see how certain
cultures, problem areas and technologies attract people with distinct
intellectual bents and how that impacts development velocity.

How much these talented people can leverage their skills is still dependent on
the organization, but pretending those differences aren't out there or that
you can't hire for these profiles is naive.

~~~
aerovistae
I'm not arguing that intellect doesn't vary. I'm arguing against "smart" being
the sole measure of who you should spend your time with, and against the act
of anonymously name-dropping "smart people" doing something as support for
your proposition.

~~~
pdimitar
But what would you do? Carry with you a book that has 100 definitions of
"smart" and point people at the one you find apt for the current situation?

Not trolling, I am genuinely wondering what would you do. It's not always
appropriate to go on huge tangents explaining nuances, especially in casual
conversational settings.

You seem to be bothered by the fact that people use shortcut words which carry
their own subjective context with them. But that's what natural language is,
most of the time -- namely a dictionary compression where the dictionaries of
the separate people vary.

~~~
aerovistae
It's not really about describing people as "smart." It's about using the
argument from authority, and separately it's about the questionable notion
that you should only spend time around people who are "smarter" than you.

~~~
pdimitar
> _it 's about the questionable notion that you should only spend time around
> people who are "smarter" than you_

Oh, that I fully agree with. It's a very copy-paste, generic and bland advice
that doesn't tell you anything.

It's further made worse by the very obvious observation that everybody is
smart in one way and dumb in another. That's what makes communication between
humans fun and interesting in the first place.

So yeah, fully agreed.

------
evrydayhustling
16y later: OOP is still pervasive, but enjoys a healthier relationship with
functional primitives in popular languages so that programmers can choose the
right tool for each task. Meanwhile, Paul has built an extraordinary career in
a role where it makes far more sense to aggressively dismiss established
wisdom, creating and coaching new business models. All seems about right!

~~~
pdimitar
Conflating popularity with quality is a very common mistake.

------
13415
I personally prefer fully object-oriented languages, as long as it's an option
and not a must like in Java.

Replacements for OOP are just another fad, in twenty years from now people
will come up with new fancy object-oriented languages, maybe functional ones
with immutable objects, or with some other paradigm that replaces traits,
mixins, interfaces, etc.

OOP is good for domains that naturally give rise to a clearcut inheritance
structure, such as stateful GUI frameworks or ontologies that directly mirror
real-world objects. It's not a magic pink unicorn, but that's true about all
other approaches.

If you want everything but small, compact executables, you can already have
that today in CommonLisp. It can be used to write functional programs or
object-oriented styles and has almost all other programming language concepts
you can imagine. Still not many people use it. The choice of the latest
programming languages has almost nothing to do with their features and more to
do with the availability of tools, libraries, and programmers.

~~~
Retra
>OOP is good for domains that naturally give rise to a clearcut inheritance
structure, such as stateful GUI frameworks or ontologies that directly mirror
real-world objects

Stateful GUI frameworks are not the only way to build UI frameworks... It'd be
pretty easy to argue that people are building stateful UI frameworks _because_
they're predisposed to think about them in terms of OOP.

And so far as I can tell, inheritance ontologies _never_ directly mirror any
real world objects. Real world objects are purely compositional with some
specialized emergent context-sensitive behaviors.

------
mamon
>> Maybe I'm just stupid, or have worked on some limited subset of
applications.

It seems to me that Graham answers this question in the preceeding paragraph:

>> I've done a lot of things (e.g. making hash tables full of closures) that
would have required object-oriented techniques to do in wimpier languages, but
I have never had to use CLOS.

He simply writes ad-hoc implementation of an object system, instead of using
one provided with his favourite language. Seems like a bad case of NIH
syndrome.

~~~
dreamcompiler
I've always disagreed with pg's contention that objects are the poor man's
closures, at least w.r.t. Common Lisp. I write a lot of Common Lisp code and
almost every one of my programs uses CLOS in some way (and many of my programs
use closures too; they're complementary). I'd probably never use CLOS if it
limited me to single inheritance or single dispatch or prohibited
reclassification like most OO systems do, but it doesn't. CLOS is OO without
the arbitrary restrictions.

