Write More Classes
61–70 of 150 posts
Re: Write More Classes
#62Earlier quoted context omitted.
He mentions stop writing classes talk in the very beginning.
Which he doesn't really address, nor do the two opinions necessarily clash (at least not totally). Diederich's talk is mostly about avoiding to write superfluous classes. Quite often a simple module with one or two function suffices. His examples look quite different from those in the blog post. (Although I have to admit that I skimmed most of them, as I'm in serious eyeroll territory whenever I see the old Java IO A…
Re: Write More Classes
#63I think the real point the author is trying to make is: use modular, layered designs of composable components, instead of monolithic APIs that only have a single entry point. The single-entry-point model imposes costs and decisions onto the application that are hard to work around. I think this is a good point. I think that it's hard to get from there to "more classes are always better" though. More classes don't alw…
Quoting from the end of the article: "And our solution to monolithic code in Python are classes." So, I guess the question I ask as someone who doesn't write a ton of python code is: Is that true? And if so, why? Is it not possible to compose a layered API that doesn't rely on inheritance / classes in Python?
Re: Write More Classes
#64Earlier quoted context omitted.
15 (?) years late ;-)
Why does that matter? If version 1 is bad, we should never use any newer versions because version 1 was bad? The iPhone didn't support 3g in the first version, so we shouldn't use current iPhones?
Re: Write More Classes
#65Earlier quoted context omitted.
Are you saying Joe Armstrong doesn't know what he's talking about? He's a very googleable guy.
I'm not aware of Joe Armstrong having extensive OO experience - either as a programmer or a language designer. Could you fill me in? Perhaps the picture I have is completely wrong. Erlang is from 1986. Did he gather extensive OO experience before? In Smalltalk? Or on the side while developing Erlang?
" Is Erlang object oriented? Joe Armstrong: Smalltalk got a lot of the things right. So if your question is about what I think about object oriented programming, I sort of changed my mind over that. I wrote a an article, a blog thing, years ago - Why object oriented programming is silly. I mainly wanted to provoke people with it. They had a quite interesting response to that and I managed to annoy a lot of people, which was part of the intention actually. I started wondering about what object oriented programming was and I thought Erlang wasn't object oriented, it was a functional programming language.
Then, my thesis supervisor said "But you're wrong, Erlang is extremely object oriented". He said object oriented languages aren't object oriented. I might think, though I'm not quite sure if I believe this or not, but Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism.
Alan Kay himself wrote this famous thing and said "The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages". He wrote that and he said that the initial reaction to object oriented programming was to overemphasize the classes and methods and under emphasize the messages and if we talk much more about messages then it would be a lot nicer. The original Smalltalk was always talking about objects and you sent messages to them and they responded by sending messages back.
But you don't really do that and you don't really have isolation which is one of the problems. Dan Ingalls said yesterday (I thought it was very nice) about messaging that once you got messaging, you don't have to care where the message came from. You don't really have to care, the runtime system has to organize the delivery of the message, we don't have to care about how it's processed. It sort of decouples the sender and the receiver in this kind of mutual way. That's why I love messaging.
The 3 things that object oriented programming has it's messaging, which is possibly the most important thing. The next thing is isolation and that's what I talked about earlier, that my program shouldn't crash your program, if the 2 things are isolated, then any mistakes I make in my program will not crash your program. This is certainly not true with Java. You cannot take 2 Java applications, bung them in the JVM and one of them still halts the machine and the other one will halt as well. You can crash somebody else's application, so they are not isolated.
The third thing you want is polymorphism. Polymorphism is especially regarding messaging, that's just there for the programmer's convenience. It's very nice to have for all objects or all processes or whatever you call them, to have a printMe method - "Go print yourself" and then they print themselves. That's because the programmers, if they all got different names, the programmer is never going to remember this, so it's a polymorphism. It just means "OK, all objects have a printMe method. All objects have a what's your size method or introspection method."
Erlang has got all these things. It's got isolation, it's got polymorphism and it's got pure messaging. From that point of view, we might say it's the only object oriented language and perhaps I was a bit premature in saying that object oriented languages are about. You can try it and see it for yourself."
It depends a lot on how one defines OO, but in this regard he has -- or at least he has given some thought for it.
Re: Write More Classes
#66Earlier quoted context omitted.
Quoting from the end of the article: "And our solution to monolithic code in Python are classes." So, I guess the question I ask as someone who doesn't write a ton of python code is: Is that true? And if so, why? Is it not possible to compose a layered API that doesn't rely on inheritance / classes in Python?
One can write Python in a procedural manner, and even in a functional way, so one can use the same techniques as are used in those paradigms (OO is probably more natural for Python though).
At the end of the day there will always be different ways to build layered architectures using re-usable components, and classes are just one of them. I'm pretty sure the author of the article didn't intend it like that, but 'write more classes' doesn't sound like great advice for novice/inexperienced programmers.
Re: Write More Classes
#67Jesus, learn how to write before, you know, writing so much.
Re: Write More Classes
#68Earlier quoted context omitted.
According to a message he posted[0] on the erlang-questions mailing list, since 1967 he has written in Fortran, Lisp, Prolog, Smalltalk , Erlang, C, C++ , Java , Python , Ruby , Lua , Javascript , Haskell, ML and OCaml. I italicised all the object-oriented ones. Saying that Joe Armstrong doesn't have "extensive OO experience" is pretty comical! [0] http://erlang.org/pipermail/erlang-questions/2013-January/07...
Extensive experience? About Java: "I tried Java" About C++: "I saw C++ coming and read the book - or at least tried to read the book - there's a dent in the wall behind my piano, where the book hit the wall" About Smalltalk: "I learnt (with various degrees of proficiency) [...] smalltalk [...] and became proficient in Prolog (aggghhh - the beauty ....)" About the others: " I also (later) tried Python (ok), Ruby (ok)"…
If you read what he wrote (not just this quote), it is clear that he has a better grasp of OO than most OO practitioners and language designers.
And especially since OO is not well defined (see pg's quote of Jon Rees' characterization), most OO people can, and often do, claim everyone who uses a different OO definition than they do has no experience.
Re: Write More Classes
#69The programming industry walks around in circles and there is no beacon in this darkness of ignorance. There is no professional culture and new generations of developers successfully forget all the experience previous generations have accumulated. Also, some piece of advice from a seasoned programmer to the web-programming-children: if you are not really a serious developer, if you write your freaking websitee on Dja…
Don't take this the wrong way, I mostly agree with your points regarding the missing "professional culture" among us programmers, just yesterday I sent an email out to our internal list urging my coworkers not to use one-letter variables anymore and explaining to them why that is bad, but when it comes to web projects somehow not being "real" programming I'm afraid you're wrong.
It is true, some momentum was lost when the "open-data" mantra that was flying in the air around 2004-2005 gave way to today's walled gardens and one-page AJAXy apps, but there are still interesting things happening on the web.
Re: Write More Classes
#70I really don't like the way this was presented, even if I may agree with the idea underneath. It's not about classes at all. It's about better design, but even the examples are strange. Just from the JSON example: - Why do I need a class for streaming JSON - Python's got a perfectly good `yield` for returning tokens in such situations. - Why would I ever design the JSON library to be extendable at the tokenizer level…
See the msgpack-cli example at the bottom. Say you have a function that returns a generator for tokens in Python. You would need another function that builds objects out of them. How do you customize how objects are being built? A class makes that simpler because each of the methods are extension points you can override.
But yeah, a token stream would be much appreciated.
> - Why would I ever design the JSON library to be extendable at the tokenizer level?
For instance if you want to skip past objects. That's what we're doing for instance for unwanted input data. That implicitly also prevents hash collision DOS attacks because we never build hash tables for things that we don't want. It also gets rid of the suspension of execution when a garbage collector runs and cleans up a nested structure. I can make you tons of examples where the "build a tree, reject a tree" approach destroys an evented Python server.
> - The 2GB JSON example is just weird. If you care about such use cases, you a) most likely have a limit on data size at webserver level, b) use proper formats for handling that size of data (I really doubt there's no better data representation once you get to GB sizes).
Try using a streaming JSON API like Twitter's firehose. Most people just give up and use XML because there is SAX or if they go with JSON they newline delimit it because most libraries are horrible or useless for parsing streamed JSON.