How Class-based Programming Sucks (2011)

http://loup-vaillant.fr/articles/classes-suck

by vimes656 • 13 years ago

140 139 13 years ago

choult• 13 years ago

The thing about "Class based Programming" - or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one approach is ever going to be perfect; OO being mutable makes it perhaps less founded (on the face of things) on formal principles, but for a lot of large codebases it can have a great beneficial effect on readability and maintainability - cognitive overhead is, perhaps, reduced when you can "ground" your understanding in real-life terms.

At the end of the day, pick what language and coding paradigms best suit your problem domain and you as a coder. Pick right, and there's no mistake there.

danenania• 13 years ago

OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time.

In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next.

Immutable state isn't just a formal exercise--it's a more authentic model of the world.

arethuza4• 13 years ago

"everything is a process"

To me that's as bad as saying "everything is an object".

I'd rather try and understand where each approach is best rather than picking a single approach and dogmatically applying it in every scenario.

theseoafs• 13 years ago

I'm sorry, are you arguing that immutability models the world more well than OO because no object in the real world ever stays the same?

w0utert2• 13 years ago

> In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next.

Been reading up on Heraclitus lately?

While this is an interesting statement for a philosophical dialogue, it doesn't really make much sense in the context of programming, where many things are constant, many things are not processes, and there are plenty of use cases for both mutable and immutable state (which is exactly why I always get really defensive reading articles like this one, that pretend all problem domains would be best modelled by a single programming language/paradigm/model of computation).

collyw2• 13 years ago

"OOP actually doesn't model the real world well at all."

Surely that is in part due to the developer. Poor developers will choose the wrong abstractions, and have a poor OOP model as a result. Better developers will choose the correct abstractions, and have better models. Obviously the domain you are modeling will make it easier or harder to model things, and in some cases OPP may not be a good choice at all.

In my day to day work I use Django. I start with a data model - based on an ER diagram. I code that in the Django model classes. Is that OOP modeling or ER modeling? I don't know. I don't really care too much. It works fairly well for most things I am doing.

hcarvalhoalves• 13 years ago

OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time.

This is important, and something almost everybody ignores.

Get an OO codebase, and try to implement a time-dependent feature, like snapshots, or even a simple undo. The abstractions fall apart.

mrkhwrd3• 13 years ago

A criminal tells the arresting police officer: - You're wrong, officer. It was yesterday-me who committed the crime but you are trying to arrest now-me. How wrong are you!

I bet the authorities around the world don't like your time-inclusive-dimenstion view much.

homami• 13 years ago

We can think the state of the world is immutable. When the state changes, it's a different world.

If space-time is discontinuous, then we can think any change of state, like motion, as a set of discrete changes. If we think the motion of a particle from one energy bin to another is immediate (meaning the particle cannot be found on the border between the bins, or one moment the particle is in Bin A, next it is in Bin B) then we can think the particle was destroyed in Bin A and another one was created at Bin B. And this is what we call motion from A -> B.

kitsune_• 13 years ago

Mutable state can be a huge pain in the ass. A common mistake OOP beginners, and even "experienced" developers, make is the creation of this complex jungle of entangled objects that all directly or indirectly manipulate each other's internal states. If you've ever had to work with such a code base for a prolonged amount of time you are pretty quickly ripe for a year-long sabbatical. There is simply no way to reason about the control flow and state of the program without investing a lot of time and mental effort. Sometimes it's almost impossible.

I don't know, I think it's a point where education fails. Your average enterprise developer should be forced to read books like "Clean Code" by Bob Martin before being allowed to touch a keyboard.

w0utert2• 13 years ago

> Mutable state can be a huge pain in the ass [..] 8I don't know, I think it's a point where education fails*

I'd argue that the problem with software quality is not so much in the (ab)use of mutable state, but the fact that (especially in enterprises) software often reflects the organizational structure of the people who worked on it.

Exhibit A: the software solution where every tiny part of the system is developed by some (semi) random group of people that often changes, doesn't directly communicate with any of the other groups, doesn't bother to much with the 'architecture' of the complete system (a big ball of mud), and has no interest improving either the overall architecture of the system, or any of the components outside their scope. Add pervasive mutable state into this mix, and you have a recipe for disaster.

That's not to say the mantra 'eliminate (almost) all forms of mutable state' will improve this problem much.

drharris3• 13 years ago

> Immutable state can be a huge pain in the ass. A common mistake FP beginners, and even "experienced" developers, make is the creation of this complex jungle of entangled functions.

See what I did there.

JackMorgan2• 13 years ago

I agree wholly that picking the right tool is critical. I also think you have to be skilled at a broad subset of all the tools to be able to even make any sort of comparison.

Many times I've heard this argument from someone who only knows the one or two tools they learned in college or in their first job, and they try to dress up their ignorance as wisdom for "not wasting time on the wrong tools".

I recommend http://norvig.com/21-days.html as a great place to start (I have only learned, at best, 3/6 of his suggested language categories, and I am on the 4th).

DanWaterworth2• 13 years ago

The idea that the world appears to mutable and therefore programming languages should encourage mutation in order to model it is one that doesn't make any sense.

To me, it makes much more sense to try to create programming languages that are able to express human thought. People think in terms of things that are, to a first approximation immutable, memories are a good example.

nailer2• 13 years ago

The thing about "Class based Programming" - or Object Orientated Programming

You can have OOP without classes - prototypal inheritance for example. In JS, you just clone an exemplar with Object.create() for example.

That said, the article author does the same thing.

collyw2• 13 years ago

Having used Angular for a month or so in summer, I find prototypal inheritance horrible and unpredictable. I am never 100% sure if the data is coming from or updating the parent object or the current object. Class based inheritance seems a lot more predicable to me.

zeteo• 13 years ago

The thing about [OOP] is that it allows you to model a problem domain in real-world terms.

That's only true on a superficial level. Sure, in CS 101 it's easy to explain how to make a Point object and add a Move() method to it. But dive into any real-world code base and you're more likely to meet RectangleCollectionColorPickerFactory instead. Let's face it, writing a large program is an exercise in abstract symbol manipulation. Trying to make it correspond to "real" objects is about as hopeless as basing literature on coloring books.

delinka• 13 years ago

"... RectangleCollectionColorPickerFactory ..." Sounds like you're blaming the OO world for Java's problems. But I digress...

Trying to make code correspond to real world objects is annoying because after you've modeled your Car with Wheels that support Tires, and an Engine with EngineParts attached ... you then have to write a adaptation layer to make all that fit into your storage engine, your user interface, your query engine, etc ad nauseam. Strings are not "real world" objects, but we use them in our code nonetheless. They're a great UI item that lets us interface with our users. "I need input from the user. Here, type some text in this field and I shall call it String." Now you can manipulate the String with operations (methods on the object) that make sense for Strings.

Point: OO is not about "modeling the real world," it's about code organization. Some people organize with OO. Some with other means.

gizzlon• 13 years ago

The thing about [OOP] is that it allows you to model a problem domain in real-world terms.
> That's only true on a superficial level.

Exactly. I had forgot that I learned OOP by modelling a CD collection. When thinking about it now, "mapping" a program into real-world models and terms seems totally backwards.

What's the point of thinking in real-world models unless you program actually manipulates real-world objects? Of course there are properties that are useful to carry over, but why limit your program to real-world models?

jonahx2• 13 years ago

OOP is not fundamentally about mapping your code to physical real-world objects, but about mapping it to natural, intuitive concepts. Those concepts can, and in many cases should, be as abstract as you like: eg, an "Algorithm" object.

Something like "RectangleCollectionColorPickerFactory" is obviously a confusing and ridiculous concept, and exemplifies a failed application of OOP, not a failure of OOP itself. One could invent equally absurd demonstrations of functional programming, or indeed of any other paradigm.

mcphilip• 13 years ago

The inability to comprehend why a mashup of nouns into a long class name might be useful is one of the most annoying memes on HN. Is it just that programmers are slow typist or something? Surely any competent programmer should be able to string together what the individual terms mean in your example (Rectangle, Collection, Color Picker, Factory), and easily grok what the class is intended to be used for.

jonahx2• 13 years ago

Yes. The article correctly points out potential pitfalls of OOP but glosses over its benefits:

See, mutable state makes shorter English sentences, and the agent concept helps make analogies with our fellow humans. In the end, this first impression trumps the fact that avoiding mutable state where possible ultimately yield simpler programs.

- But shorter English sentences are awesome.

- Good analogies are awesome.

- Effectively communicating with our fellow humans is awesome.

Indeed, all these things contribute to simplicity.

I find that often critiques of OOP are actually critiques of poorly implemented OOP. When it's done well, it can retain many benefits of immutability while still mapping more naturally to domain concepts. This talk by Gary Bernhardt is a great discussion of using functional concepts in OOP, and doing OOP well:

https://www.destroyallsoftware.com/talks/boundaries

The talk "Functional Core, Imperative Shell" is also a must see.

jeremyjh2• 13 years ago

- But shorter English sentences are awesome.

You missed the author's point here. He of course prefers shorter sentences as well. He is complaining that mainstream language syntax is biased in favor of mutability since you need to use an extra keyword to make a const expression. In F# for example it is just the opposite, you have to use the keyword "mutable" in your declaration.

thearn4• 13 years ago

pick what language and coding paradigms best suit your problem domain and you as a coder

An addendum: there is often no single obvious best way to do something. Though many approaches are obvious as being less wrong than others.

runarberg• 13 years ago

Note that Class based != Object Oriented.

Also note that theories that have tried to categories real world objects into classes have a tendency to fail (although they also have a tendency to become enormously popular [see Platon and Aristoteles fx.]).

So the claim that classes allows you to model a problem in real-world terms, is most likely false.

See for example http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.56.... for a review.

d23• 13 years ago

cognitive overhead is, perhaps, reduced when you can "ground" your understanding in real-life terms.

It absolutely reduces cognitive overload. Having "containers" of functionality that allow me to easily know at a glance what I'm working with is invaluable. I'm not knocking functional programming, since I haven't built a few projects in a purely functional language yet, but trying to do some things with the functional paradigm (or at least, my understanding of it) left me recognizing class-based programming as a powerful tool when used correctly.

Peaker• 13 years ago

In fp, those containers are known as modules.

evanspa2• 13 years ago

I love Hal Abelson's opening of this SICP lecture[1], in which he acknowledges that OO (with mutable state) is born from the idea of modeling computer programs the way we perceive the world. But then he goes on to say that the reason why OO can be so complicated (because of having to deal with the can-of-worms that is mutable state) is because maybe we have the wrong view of reality.

He then proceeds to launch his piece of chalk across the room! (good stuff). And proposes that instead of the chalk having changing state (position, velocity, etc), instead, its better to thing of the chalk as a collection of immutable values; each value existing at a moment in time. And this of course aligns more to functional programming; and you see the same notion (immutable values over time) with descriptions of Datomic.

[1] http://ocw.mit.edu/courses/electrical-engineering-and-comput...

davexunit3• 13 years ago

What a great lecture. Thank you for sharing. I own and have read a good portion of SICP and these lectures are a great supplement to that.

Nekorosu2• 13 years ago

The problem is it's not real-world most of the time.

auggierose• 13 years ago

In case you don't know ML, you should. Also note that though OCaml is the most popular ML dialect right now, Standard ML is where it all started (PolyML is a good Standard ML implementation: http://www.polyml.org/)

JackMorgan2• 13 years ago

Or even F#, which is basically OCaml on the CLR. Very fast, fully supported IDE, great if you're stuck in SLAs for CLR code, complete interop with C# or VB.NET, it's the current hidden treasure of the .NET world.

pjmlp6• 13 years ago

Pity that Microsoft pushes it more for library code and not so much for full applications.

But if it gets more use in the mainstream that way, then so be it.

masklinn• 13 years ago

Standard ML is where it all started

Technically, ML is where it all started. Standard ML and OCaml are to ML as Scheme and Common Lisp to Lisp.

rowanseymour• 13 years ago

Best (and most humorous) argument against Java's object oriented obession that I've ever read is: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

pjmlp6• 13 years ago

The funny thing is that many like to bash Java's OO model, and in the process forget that Smalltalk, Eiffel, C# and many others offer a similar model.

astrobe_• 13 years ago

What's really funny is to claim that the Java/C++ model is similar to the Smalltalk model.

enobrev• 13 years ago

I truly miss Steve Yegge's rants.

stopthemadness• 13 years ago

It's more that Java is hard because naming things is hard and Java forces developers to name lots of things.

rayiner2• 13 years ago

This is a very good article. The point about mutable state is key. Class based programming encourages you to treat objects as little bags of mutable state, instead of as values, and everything goes downhill from there. Its one thing to not go all the way to disallowing mutation. Its another to encourage it to be used pervasively.

jimmaswell• 13 years ago

Prorgramming without mutating state is honestly just bizarre to me. Mutating state is all a program does, literally.

toolslive3• 13 years ago

mutable state is not a problem per se. _Shared_ mutable state however, is a recipe for disaster.

There are other problems with Object-Orientation. For example, it tends to scatter allocation which has performance impact. ( see this nice presentation: http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal... )

If performance is not an issue, I'd guess the price you pay for OO is that you eschew parallelism and concurrency.

tomp3• 13 years ago

Functional paradigms scatter allocation even more (though maybe more predictably, so the Generational Hypothesis is of more value in a functional programming language).

Also, as soon as state escapes a function, it becomes shared, so should be immutable (except when explicitly made mutable).

toolslive3• 13 years ago

any evidence for the 'even more' statement ?

jeremyjh2• 13 years ago

Any code that operates upon your object with "private" state still has to account for the fact that its methods are not referentially transparent. E.g. I have to open a connection to the database before I can send commands through it, and so now I have to check if its already open everywhere I use it. So that is definitely shared state, but I guarantee you that a lot of people think a private variable means it is not shared.

arithma• 13 years ago

I find a mix between Object-Orientation to model the problem, and a lot of functional thinking in the 'solving' department to be the most comfortable. The modernisation (as in taking features from the old languages into the newer ones) of C++, C#, Java, Obj-C etc. are all liberal with this direction.

arethuza4• 13 years ago

I agree - in my experience object-orientation is at it's best at structuring a representation of the problem domain and functional thinking fits well with solutions. I've written a lot of code over the last few years that models large scale industrial systems and the general style is very much functional processes over immutable objects and this has worked pretty well.

barrkel2• 13 years ago

Class-based programming works great for GUI toolkits. In most other contexts, the suitability is variable. OO is a horrible match for compilers, for example.

The article is chasing down the wrong tree when he tries to build an Option type in C++, though. The normal OO way to handle the same class of functionality as ADT sum types is to use separate subclasses. What he's not acknowledging is that OO and functional+ADTs both only handle half the expression problem[1], in different ways. There's no absolute superiority for either model. It depends on the domain.

Less mutability is good almost everywhere though. The lack of persistent data types is a blight on almost all non-functional container libraries.

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

fhd2• 13 years ago

Class-based programming works great for GUI toolkits.

That and games (and I'd wager simulations in general). The only two domains I'm familiar with which I cannot imagine without OO.

From what I've seen, even UIs and games written in languages without support for OO still use something very close to OO. GTK for instance takes it quite far with GObject.

ocharles• 13 years ago

I spent some time writing Asteroids in netwire - a functional reactive programming library in Haskell - in my free time over a few evenings. I blogged about this at http://ocharles.org.uk/blog/posts/2013-08-18-asteroids-in-ne... - and I don't think it pretends to be OO. It was a radically different style, and I left feeling fairly convinced that FRP is a fantastic model for realtime interactions

bunderbunder• 13 years ago

That and enterprise software. As productive as I am with functional programming, I still find it works better to expose object-oriented interfaces to the world at large.

Some of that's admittedly just down to the window dressing. Object-oriented abstraction mechanisms such as interface tend to have a measure of self-documentation built in, to the extent that all the members are named, right down to method parameters. There's no reason you couldn't do something similar with FP, it's just that as far as I can tell nobody's ever made a point of doing so.

codygman• 13 years ago

I believe someone has solved the expression problem in Haskell and other languages.

pjmlp6• 13 years ago

OO is a horrible match for compilers, for example.

Actually it is a very good way to create ASTs if you need them to be extendable.

Which is exactly the use case where algebraic data types fail short.

emn134• 13 years ago

You want some way of specifying an interface - that doesn't necessarily imply classes. Also, class-based inheritance tends to be a poor fit for interfaces; note for example that C#/Java have their own special-purpose interface mechanics, and even C++ which allows multiple inheritance tends to use implicit template-based interface implementation instead.

Discriminated unions on the other hand are - the name says it - intended for cases where you want to discriminate between multiple possible values. They're by design not intended to hide differences behind an interface; they don't address the same problem at all.

All in all, I think that neither classes nor discriminated unions solve the interface problem (nor were they ever really designed to do so) - that's a different problem.

qznc• 13 years ago

What is so bad about OO for compilers? An AST can naturally be modeled as a class hierarchy. Visitor pattern for AST transformations.

rayiner2• 13 years ago

What is so bad about OO for compilers?

See my comment about the expression problem in another thread: https://news.ycombinator.com/item?id=6783075, as well as this response: https://news.ycombinator.com/item?id=6784057.

A compiler is a program that consists of lots of different algorithms (operations) that operates on a pretty well-defined set of data (an AST or an IR). Changes to the data representation are rare compared to changes to the operations on that data.

What OO does in a compiler is totally obscure the control flow of each algorithm by spreading the logic out over dozens of classes. You can look at an AST node and see at a glance how it participates in constant folding or code generation, but if you're trying to optimize the constant folding algorithm or the code generator, you've got to follow control flow across dozens of different classes.

Using visitor pattern mitigates this somewhat, because you can have ConstFolder::visitBinaryOperation, ConstFolder::visitFunctionCall, etc, all in one file, but note that visitor pattern is just a really verbose, roundabout way of writing a switch statement! If you add a new type of AST node, you have to add a visitNewAstNode call to the visitor interface, and then go update every class that implements the visitor interface. This is no easier, and a lot more verbose, than simply adding a new variant to an AST ADT then fixing up all the places where the compiler complains that your pattern match is no longer exhaustive.

For a good example, look at how LLVM does instruction simplification: http://llvm.org/docs/doxygen/html/InstructionSimplify_8cpp_s.... A good old switch statement, no "simplify" method in the "Instruction" class nor visitor pattern.

seanmcdirmid9• 13 years ago

PL designer here with extensive experience writing compilers in C#, Java, and Scala. Pattern matching is nice but OO will get you most of the way and filling the matching gap is simple.

The expression problem is much safer solved using virtual classes (using traits and type members) in scala than with case matching. There are so many OO solutions to this problem it's not funny; I think I had a small argument with Wadler over this back in 2001 or 2.

As for persistent collection types, observable collections with undoable operations are just as good, if not better because they can still support mutability while persistent collections cannot.

barrkel2• 13 years ago

I've written compilers in C, C++, C#, Delphi, Java, ML and Lisp; targeting x86, x64, JVM and MSIL. I was maintainer of the Delphi front end at Borland / Embarcadero. Pattern matching isn't just nice; you end up with substantially better typechecking, and doesn't need ugly patterns like visitors with their inverted callback control flow, if you want to decouple e.g. type checking or code generation from your AST classes. Visitors are implicitly closed to extension unless you create very abstract visitors (and I've gone down that path, it's not pleasant) - you lose a big chunk of the extensibility objects give you over ADTs. (I'd prefer to use multimethods, but they are rarely available.)

I think persistent collections, along with nice syntax for updating immutable objects (i.e. cloning with a subset of changed attributes) are more practical than having undo available. Immutable data types remove the burden of worrying about who's going to modify the data type from under you, so it lets you share subgraphs more freely. You don't need to worry as much about coupling, because the things you give your state to can't modify it. A possible alternative is mutable collections with snapshots or freezing, but I think persistent collections are a better approach.

smosher5• 13 years ago

I couldn't help but notice this phrase:

[X] is nice but [Y] will get you most of the way and [dealing with the difference] is simple.

reads a lot like the Blub conceit. I'm not accusing you of that, but I do disagree that OO can give you what pattern matching typically does.

runT1ME• 13 years ago

The expression problem is much safer solved using virtual classes (using traits and type members) in scala than with case matching.

Why do you think this? I prefer having an open trait that's only inherited by ADTs.

I can get non-exhaustive match warnings and I still 'solve' the expression problem by matching on a superset of my partial functions (that do the matching).

protomyth2• 13 years ago

"Class-based programming works great for GUI toolkits."

I've programmed with 3 approaches to UI: every things a subclass, instance of class, and prototype-based objects. I enjoyed programming UI on the Newton because of the prototype-based programming. It felt natural. NeXT / Apple's instance of a class works very well too.

Every time I see "every things a subclass", I wince and know its going to be a pain in the butt.

lmm• 13 years ago

Ever use Wicket? It's an utter joy to work with, and the only framework I've found that really shows the good side of Java.

wsc981• 13 years ago

That reminds me of a little quote by Aaron Hillegass in his book "Cocoa Programming for Mac OS X" (p. 73):

"Once upon a time, there was a company Taligent. Taligent was created by IBM and Apple to develop a set of tools and libraries like Cocoa. About the time Taligent reached about the peak of it's mindshare, I met one of its engineers at a trade show. I asked him to create a simple application for me: A window would appear with a button, and when the button was clicked, the words 'Hello World!' would appear in a text field. The engineer created a project and started subclassing madly: subclassing the window and the button and the event handler. The he started generating code: dozens of lines to get the button and text field on to the window. After 45 minutes, I had to leave. The app still did not work. That day, I knew that the company was doomed. A couple of years later, Taligent quietly closed its doors forever. "

swah• 13 years ago

Relevant recent tweet by the creator of the Io Language, Steve Dekorte: https://twitter.com/stevedekorte/status/411045428361056256

I suppose most folks here disagree?

rurban• 13 years ago

Of course I agree with Dekorte. Having written compilers written in perl, C and LISP - the ones in perl in pure OO, and the ones in C and LISP without, I conclude that I rather add classes and methods to my compilers than trying to improve it without. In the one written in C, classes are supported by the intermediate VM though (dynamically typed, very similar to Io), which is still better than having to write it in horrible C++.

pbsd• 13 years ago

You may even have to inherit a base class or implement an interface. Subtype polymorphism is a very poor substitute for closures. This is why C++ algorithm library is unusable.

Does anybody understand what the author means by this? STL's algorithm library does not use class hierarchies for anything. And they often take functions (be they free functions, lambdas, or functors) as arguments.

nly• 13 years ago

The author probably had (this was written 3 years ago) a bitter and rather narrow view of OOP capable languages.

In C++ a class is just a facility of the language with many different features. If you want immutable, value-semantic objects, then do it. If you want a closure... well objects can be closures too. C++ calls them functors, they can be immutable. In fact, C++11 lambdas are immutable by default.

His criticism of the STL is probably that they expose their mutation, rather than hiding it in the architecture like pure functional languages. In C++ you just have to hide the infrastructure yourself.

humanrebar• 13 years ago

The overhead that is assumed unimportant by most functional languages (copying is cheap, GC is fine, etc.) is intolerable in key situations and problem domains. In C++ all overhead must be optional.

That being said, nearly all C++ applications can benefit from immutable classes, algorithms that take closures, and so on. But C++, like C before it, is really just an abstraction of the hardware and OS below it. That hardware mutates. That pool of memory changes size and locality. The closer your problem domain is to the metal (especially drivers and highly-optimized code), the more you appreciate mutable state, at least given the current state of computing.

blt• 13 years ago

Before C++11, if you wanted to pass a function with closure-like behavior to an STL algorithm, you had to write a little class with operator() overloaded. It was a huge pain in the ass, lots of boilerplate code. Most programmers didn't bother and wrote plain loops.

Now with C++11 lambdas, std::algorithm is much nicer to use.

draegtun• 13 years ago

Also see: The problem with OOL is not the OO by Carl Sassenrath (from 2009) - http://www.rebol.com/article/0425.html

PS. Just submitted to HN - https://news.ycombinator.com/item?id=6900426

xcthulhu• 13 years ago

Okay, for one:

1. Dynamically Typed Languages (LISP, Erlang, Smalltalk, Python, Ruby, and Javascript) are all easier than Haskell, JAVA, C++ or any other typed language for working with ADTs. Whether the language is OO or not isn't really relevant. On the other hand, you loose type-safety/efficient representations. But life is filled with choices, different tools are good for different things at different times.

2. You can have closures in a class based language. Here's some rather exotic Python code that uses both for measuring the performance of iterators: https://github.com/wearpants/measure_it/blob/master/measure_...

Smalltalk and Scala also have closures. It's not an either/or for classes vs. closures in programming language land.

3. There's more to concurrency than shared memory, so immutability is again a weapon that is good for some battles. If you have an app which you've factored into workers, unless they are on the same machine they'll need to communicate. Having your data be serializable is more important than having things be immutable in this context. What a worker does with data while it is handling it can involve lots of mutation.

So everyone should take a big breath, and remember that there's no one way to think about software and there's no universal rules, other than probably P != NP and stuff like that.

platz• 13 years ago

At this point, it's probably easier to name the languages that don't have closures as opposed to those that do

EdwardDiego• 13 years ago

Java's anonymous classes can also act as a (large and bulky) closure, although as you have to declare local variables used by the anonymous class as final, the capacity to close over mutable state is limited to instance fields or mutable objects.

alkonaut• 13 years ago

I agree, mostly, with the conclusions. "Classes" as a method of code re-use is dead. However, his conclusion that ML would dominate C# and Java as a language, I highly contest.

The most important thing in my opinion is tools and platform support. Show me a fast, good looking IDE with good autocomplete/intellisense/integrated debugger and UI tools for ML. See?

Is there an abundance of libraries and api wrappers available (that doesn't require you to do straight C-interop)? See?

Also: the design of a language should be done with the tools in mind. While there is not much difference between norm(vec) and vec.norm() the latter is the form that supports autocomplete. So even for functional languages, being able to use member properties and member functions is an absolute reqirement to support the tooling that we expect.

You could say that F# dominates C#. It has almost the same tool and library support, while having the features you expect from an ML type language.

MichaelGG• 13 years ago

If your functions are inside a module you import, you can still navigate them by browsing autocomplete using the module name as an unnecesary qualifier. Then once you find/remember, delete the qualifier in cleanup. No need to force members just for discoverability. (Not to mention that tools could provide other ways of doing autocomplete.)

likeclockwork• 13 years ago

I'm noticing that whenever there is talk about any language that isn't Java or a CLR language several someones pop up to go on about the tooling "we" expect.

The difference between norm vec and vec.norm() is that the function can be used in a higher order function while the method would require wrapping it in a lambda to achieve the same thing and would probably still break your tool's ability to autocomplete if you used it that way.

You're basically insisting that an FP language needs to include an embedded OO language to be usable.

al2o3cr• 13 years ago

"The obvious conclusion is that ML simply dominates Java (and C#) as a language. Time to switch."

The obvious conclusion is that any statement that contains the phrase "the obvious conclusion is" is 100% BS, including this one.

mtdewcmu2• 13 years ago

A language can't suck just because it isn't Haskell or ML.

matjazmuhic2• 13 years ago

It's funny how people blame the language when they are the ones who made a mess. :)

On the other hand, there are languages that make it easier for you to screw it up and the ones that try to prevent that.

But there's no bullet proof language.

mtdewcmu2• 13 years ago

A bug-proof language is like an uncrashable car.

How Class-based Programming Sucks (2011)

Related Stories