51–60 of 150 posts
It's tasked with returning records from parsed zones and every single record is a class. I like it and I don't understand the first sentence of this blog post.
Try not to put too much weight on what others tell you, make up your own mind. It's a classic human issue.
Earlier 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?
It is perfectly acceptable to design a library with a simplified, restricted interface that covers the majority of use cases, but not all. e.g. requests vs urllib2 For me, that's a win for common sense. I have never even considered streaming JSON. The lack of streaming support should be a clue that the OP needs to look at whether what he's attempting is even sensible or could be better served by a different transport…
So he asks for using abstractions instead on no abstraction (block code) but if you have other ways of abstracting code, please go ahead. THis article is good for people with few / no tools, people who are still learning
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? If you need serialiser / deserialiser, why not just provide a map of types to callbacks / callback as a parameter? Do you really want to extend JSON format itself?
- 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).
I see his point of view, but he's arguing for one single "hammer" solution, rather than arguing against the monolithic design. His story seems to present some weird back-story really: "I needed to make my data easier to handle, so I started automatically serialising objects into JSON, then they became huge so I have to start streaming them otherwise just parsing of them takes way too long".
Can anyone explain the statement about simplejson for me please? Some libraries manage to skip the token part. (I'm looking at you simplejson, a library that even with the best intentions in mind is impossible to teach stream processing)
When you are trying to parse extremely large documents or you only care about a small subset of a document, needing to load the entire parsed file into memory is problematic. Simplejson doesn't provide an API that allows for any other option. This is in contrast to something like an XML sax parser, that allows you to register for events like "a foobar element was loaded". You get the foobar element while all the othe…
I read it exactly the other way around: simplejson skips an internal tokenization step, so even if you fork the library it is pretty much impossible to make it streaming, because there's no token stream to handle stream state.
Earlier 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)"…
Earlier quoted context omitted.
To be fair, they have mostly fixed the IO API with Java 7 (NIO2). This covers various Files# helpers as well as a proper Path abstraction.
15 (?) years late ;-)
Earlier 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)"…
This is a bad article. First, write nothing. If you can solve your problem without writing code (or even better, by deleting code), that is the best solution. Next, write code which fits your architecture. Sometimes functional composition is the best system for representing your computational structure. Tree operations, for example, are especially amenable to recursive function-based computation. Sometimes, when you…
From what you wrote, I'm not sure you read the article. It's not about objects vs functions; it's about hiding a lot of functionality behind an overly-simple interface, with particular attention paid to an example of a parser that takes a whole string rather than a streaming interface. What annoyed me most was his constant apparent conflation between bytes and characters. But I didn't really see much evidence of trea…
Write no classes! Joe Armstrong: "I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle . If you have referentially transparent code, if you have pure func…