Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming without objects

falkoriemenschneider.de

Post reply on HN
Print view View original

41–50 of 133 posts

Re: Programming without objects

#41

Post by klodolph »

millstone wrote: post #12

This article, like many that cheer functional programming, falls into a certain cognitive bias, that prevents it from seeing what OO is good at. Alan Kay wrote "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." To start to see what this means, consider the annoying String / Data.Text split in Haskell. St…

> This proved to be so rigid that an entirely new string type had to be introduced, and we're still dealing with the fallout.

There are a lot of things wrong with, say, Haskell '98 from the perspective of a modern Haskell programmer. Strings are one, but monads aren't applicative functors, it took us a long time to figure out how we wanted to write monad transformers, lazy I/O is terrible and we should use conduits or whatever instead. But you picked strings. This example does not help your point for the following reasons:

1. You can't just change the implementation of the string type without messing up someone's program. For a fantastic example, look at the recent change to Oracle's string type in Java. In theory, the interface is the same. In practice, it made a bunch of people mad.

2. You can encapsulate data in Haskell. Look at the "Text" data type, and ignore Text.Unsafe which exposes the gory innards. This is module level encapsulation, which is just as good as class-level encapsulation (better, actually, since it's more flexible). You could replace Text with a UTF-8 implementation or a UTF-32 implementation or some magic implementation that switches between the types, and you wouldn't break consumers of the Text interface.

> For example, try modifying a Haskell program to print a log every time a string is made. You can't!

This is a really contrived example. First of all, there is the question of whether you will need to create a string whenever you log something to a file, and presumably you wouldn't want to log those strings. Second, this is something you'd do with a debugger, you wouldn't actually do this to a program.

Besides, if you had access to the string implementation (which I'm assuming here is Text, because that's what most people use), you could just put some kind of unsafePerformIO call in front of uses of the Text constructor, and since the Text constructor isn't exported from the Text module, you're done.

Re: Programming without objects

#42

Post by [deleted] »

millstone wrote: post #12

This article, like many that cheer functional programming, falls into a certain cognitive bias, that prevents it from seeing what OO is good at. Alan Kay wrote "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." To start to see what this means, consider the annoying String / Data.Text split in Haskell. St…

[deleted]

Re: Programming without objects

#43

Post by jimbokun »

Kiro wrote: post #36

I'm not a good programmer but I've never understood OOP. For me it feels much more logical to work with pure functions with consistent output based on input. At work I'm told to use more OO but it feels really enforced and not intuitive at all. The only time it makes sense for me is in game development where you have many entities of the same type that all have their own states. I feel I should learn OO properly and…

The secret about real world Java applications is they tend not to be very object oriented at all, in the way OOP is taught in textbooks.

Interfaces are very heavily used, along with dependency injection (boy, do Java programmers love their dependency injection).

Inheritance is now widely discouraged. "Java Beans" are everywhere, which are glorified structs breaking every single rule of encapsulation.

Java runs fast, is garbage collected, has great support for multithreading, great Unicode support, and many other advantages. But it's certainly not very object oriented, especially in the Alan Kay sense.

Re: Programming without objects

#44

Post by klodolph »

chton wrote: post #10

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on that state. Forget the exact way the type system works, or what extension methods are, or even what polymorphism is. The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. W…

> The big advantage of OO is that it acts as a distillation of how humans think.

I would consider this a disadvantage, not an advantage. Human thoughts are imprecise and carry rich but ambiguous connotations. The major advances of mathematics in the 19th century (or thereabouts) onward are closely tied to the divorce of notation and natural language.

The ancient version of the Pythagorean theorem is something like, "The area of a square whose side is the length of a hypoteneuse of a right triangle is equal to the sum of the areas of squares whose sides are equal in length to the other two sides." A modern version is more like, "Let a, b, c be the lengths of sides of a right triangle, where c is the length of the hypoteneuse. Then a^2 + b^2 = c^2." You can see as time goes on, the text becomes simultaneously clearer, more concise, and more abstract.

This is why natural language programming is doomed to failure. Others have expressed the point better than I do (notably Dijkstra). But you can look at the examples of how inheritance in class-based OOP systems work and you will get sick just looking at them: examples of Dog inheriting from Animal, and Penguin from Bird (but penguins don't fly), et cetera. The real disadvantage here is that once people start thinking about taxonomy in general (which class-based OOP encourages), you're not thinking about programming any more.

The difficulty people have with even simple problems like "how do you describe squares and rectangles in a computer program" is another good illustration of how the class-based object-oriented system of thinking is unsuited for solving computational tasks, at least compared to the alternatives.

Re: Programming without objects

#45

Post by klodolph »

louthy wrote: post #40
AnimalMuppet wrote: post #7

Earlier quoted context omitted.

Agreed. The problem is, what you're asking him to do is really hard. Why was OOP considered a good idea? Before OOP, programs were just structs and functions that operated on them. But as programs got larger, that approach broke down. Someone on a team of programmers would create an instance of a struct, but would initialize it in a way that some function (written by a different programmer) would regard the struct as…

This is quite a good article on exactly that: http://simontcousins.azurewebsites.net/does-the-language-you... The same application written in C# and F# by the same programmers (the C# project took 5 years, the F# project 1). It in no way proves anything, but it's food for thought. Personally I've had huge wins moving from OO to functional (Haskell and F#).

I've seen similar studies. I wonder, however. Functional programming is somewhat esoteric, so a random selection of programmers who practice FP are likely to be more dedicated to the craft of programming in general. I think the truly interesting question to ask would be, "Can we make software better by having the same programmers use functional programming?"

Re: Programming without objects

#46

Post by klodolph »

millstone wrote: post #23
DanielBMarkham wrote: post #6

I've been taking a similar journey in my blog, where I talk about the difference in thinking in FP and OOP. ( http://tiny-giant-books.com/blog/real-world-f-programming-pa... ) I use C# and F#. I was at a Code Camp a few years back where one of the speakers was introducing F#. He was looking at a map function or some such on the screen and muttered something like "Well, you know, you can see the C# this compiles down…

I wonder how much of the "small, composable functions" nature of FP can be attributed to the types of programs you write in functional languages, and the types that you don't. Unix-like tools such as grep (or ghc) are very much like pure functions: programs that accept input, and produce an output data. It's not surprising that they lend themselves well to FP techniques. But other programs, like the web browser I'm u…

> I suspect these programs have a larger essential "hairiness." grep only has to search text. But Find in a text editor has to show a progress bar, cancel button, intermediate result count, etc. These features are intimately intertwined with the algorithm itself, and that's often hard in FP. Try writing a Haskell function that does text find/replace with live progress reporting. It's not easy, and it ends up looking a bit like Java.

Ah, I suspect you're not familiar with things like conduits/pipes/iteratees/etc. These allow you to express and compose those kinds of dirty things that you're looking for--incremental input/output, progress reporting, etc. So you could write a text search function, compose it with a progress reporter that reports how quickly it traverses input, and then report the output progressively, and dispose the whole thing at any time. Haskell's type system is fairly awesome at letting you do things like this, enough that people are still discovering neat tricks decades later.

Re: Programming without objects

#47

Post by chas »

tlarkworthy wrote: post #38
nbevans wrote: post #27

Every OOP developer is on a journey, they just don't know it. Some of them will never make it. But some will reach a point of realisation where writing well-designed software comes naturally to them because they've inadvertently stumbled upon the core concepts of functional programming. It then requires them to realise that what they've found is just FP and then requires a further minor step to actually learn a more…

I made the switch to FP. I first learnt Basic then Delphi then C then Java then C# then Python then JS and now Scala. Python is my still my favourite and I really like Scala too. Anyway, I could write big stuff in any typed language OO or otherwise. I don't get what the revelation about FP is. If you want bullet proof code, get the model checker out and work in state machines. That is far the biggest revelation I hav…

I'm not going to claim it solves concurrency, but Haskell's combination of STM, expressive types, and immutable data by default make it the nicest language I have used for concurrency. (I have heard similar praise of Clojure as well, but I don't have any experience with it.)

Re: Programming without objects

#48

Post by DEADB17 »

I think that contrasting OOP with FP brings too many implicit assumptions to the discussion. The value of immutability, for example, seems to be orthogonal to the technique used to structure a computation and is more closely related to the problem to be solved.

In my opinion OO languages popularized the idea of having separate internal and external representations by providing language constructs that made it practical. But they also promoted the coupling of data with the methods to manipulate it -- this is not a necessary characteristic of OO but it is common in popular implementations. This association of data and methods turned out to be a limiting factor in the face of changing (maybe unknown) requirements. The flexibility of more dynamic run-times that allow to mutate this relationship during execution (monkey patching) was not a satisfactory solution as it inhibits static analysis. In my experience this is generally the main motivation when looking into alternatives.

Modeling computations as dynamic data threaded through a series of statically defined transformation seems like a sensible solution to the issue. It also brings additional benefits (e.g.: easier unit testing) and makes some constructs unnecessary (e.g.: implementation inheritance). This approach is commonly used in FP languages and I think is the main reason why they are contrasted as alternatives.

Since it's not always possible or desirable to re-write a project, sometimes the technique is dismissed because it is confused with the languages that favor it. The relative lack of resources explaining how to use FP techniques in OO languages doesn't help either.

Separating the techniques from the implementations has practical value and it allows evolving existing bodies of work.

Re: Programming without objects

#49

Post by seanmcdirmid »

Dewie wrote: post #20
chton wrote: post #10

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on that state. Forget the exact way the type system works, or what extension methods are, or even what polymorphism is. The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. W…

> The big advantage of OO is that it acts as a distillation of how humans think. With how widespread OO is now and in the last decades, how much it is taught and how important it is in a fair share of popular programming languages (or even mandatory, for all practical purposes), this point might just be a self-fulfilling prophecy (if I'm using that expression correctly).

The way OOP is taught often doesn't bring up object thinking. But if you believe it is not natural, try thinking mathematically (without nouns or names as unique aliasable identifiers). Or without isa or hasa relationships. Our minds have 50,000+ years of language expertise, and only a couple thousand for formal non linguistic equational reasoning (where things only have structure and are unnameable).

Re: Programming without objects

#50

Post by tel »

eli_gottlieb wrote: post #28
mmiliauskas wrote: post #4

All this FP revolt kind of start to remind me Whitehead's and Russell's attempt to invent a formal system which would be paradox free...

Martin-Lof Type Theory doesn't actually have any paradoxes in it.

Well, it does—Girard found one. It also has lots of troubles with equality.
Post reply on HN