back
3 comments
Why is it all videos?

Text is so much better for evaluating arguments. When reading you can spend variable time on different parts to skim the obvious and go deep into the more difficult stuff, you can random access it later to refresh your memory, you can quote it.

Videos are probably only better in persuading people - but that requires that they watch them (and maybe get some stockholm syndrome after wasting so much time :).

It's not all videos. See Brian's article about OO here:

https://medium.com/@brianwill/object-oriented-programming-a-...

and the HN discussion here:

https://news.ycombinator.com/item?id=10933330

Thanks for the links.

Still apparently the whole argument is only in video:

>>> [Edit: I’ve greatly expanded on these ideas in a 45 min. video.]

Because this is how millennials convey developer information now that they have cellphones and GoPros. Instead of essays they have videos. Instead of rationales they have footage of their talks. Instead of introductory documentation they have screencasts.

Get used to it.

I doubt I will. There are cases where videos beat textual presentations (I think https://www.youtube.com/watch?v=a9xAKttWgP4, the video about programming Conway's game of life in APL is an example) but they are very rare, and even if a few more years or decades of AI research produce a search engine that can be used to find videos answering questions I have, watching a few of the top 10 videos to apply the final human filter will still be slower than opening the top 10 search results now is.

Visually scanning well-written prose that is laid out correctly (easily recognized headers with good content, good paragraph layout) IMHO is way faster than finding the meat in well-written presentations that are presented and recorded properly.

Going from 10 years of strictly procedural programming to oop I can say with certainty that for most applications oop is better hands down.
Don't you think this could just be attributed to you having gained experience?

I look at my code from 10 years ago and it is written with objects and late dispatch as main modeling tool and that code is terrible.

The other alternative is functional programming (which is usually not the same as procedural programming).
I think that FP is a valuable addition, but not strictly better than OOP (or procedural/imperative). I think that some problems are better expressed in FP, and some are better expressed in an imperative manner and a language should let you choose.

edit: s/think/BELIEVE/

That conflict between OOP and FP is the "Expression Problem". Choosing which side to use for a given problem is an important part of software design.

http://c2.com/cgi/wiki?ExpressionProblem

In my experience there is another kind of expression problem. It's usually something like this

    "a:b:c".split(":").first # Ruby
vs

    String.split("a:b:c", ":") |> List.first # Elixir
The length of the two statements is telling. Luckily Elixir has the |> and I don't have to write

    List.first(String.split("a:b:c", ":"))
OO is generally more convenient to read. It's also more convenient to think into, even when I was young and I looked at C and Lisp without much priming from previous experiences.

Functional has other advantages. I quote Joe Armstrong on that: [with OO] "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." That wasn't much different with plain C though, which could do structs and be somewhat object oriented too if you coded in the right way. And you could end up with a jungle of functions as soon as you write enough modules that need each other.

IMO, the difference in readability has little to do with the difference between OOP and FP. What's important is the expressiveness of the language.

So Ruby can be very easy to read because you can simply keep appending methods to the right.

In Haskell you can do the same, only you'll prepend functions on the left, so you end up reading expressions from right to left:

    (intercalate ", " . map show . Map.elems) myMap
What I find really hard to read, are expressions where the direction of the data flow changes, something that often happens to me in Java:

    Streams.takeWhile(list.stream().map(e -> f(e)), e -> e.isNeeded())
Three completely unrelated things I guess.

1. Expressiveness is important? Expressiveness is why I don't like Perl.

2. You can certainly implement patterns analogous to OO in functional programming with closures and first-class functions.

3. Reading in the order of execution via chaining is definitely a lot more intuitive than reading from the inside out or right to left.

What you say is sound but, IMO, not complete. There's something more to immutability vs. mutability. They both can, for instance, describe both data bases and mathematics. But there's no doubt in my mind that mutable state is better suited for the former, and immutability for the latter. It's "stuff" vs. "knowledge" that's modelled; stuff wants to change and knowledge wants to be shared.
The 'Bad' one is all about personal opinions, no real arguments beside a bunch of information already well-know about oop and that has been discussed by years. And honestly, it looks like a iluminatti conspirancy video, with the boring narration, the sensationalist tone, the black screen. ugh.
I think you're being dismissive. Where else can I read about the arguments Brian makes in the video? I've struggled to find supporting material.
You can read Peter Wegner's Concepts and Paradigms of Object-Oriented Programming (1990), to get a deep discussion of all the concepts he speaks about oop. He is not criticizing oop, but doing an analysis compared to procedural programming. (And defending why OOP can be useful, but with no sensationalism) And he even predicts that paradigms based in concurrency will be the next buzzword after oop. If you read most of the discussions that happened in those early years of OOP adoption, you'll see a lot of the things he's pointing out has being already argued. They just were done in texts, not videos, and weren't so incendiary.