dpkp

Joined 11 years ago

Karma

Submissions

Member since

Jun 16

http://github.com/dpkp

View on Hacker News

Recent submissions

Comment · 4 months ago

amusing that the most rational take on HN is immediately down-voted.

Comment · 5 months ago

I see the same but only in browser / wasm. Also notice that the mobs dont move in browser mode. Local via lg in console works great though.

Comment · 7 years ago

I can understand your frustration about Rich's development process. But clojure is most definitely not closed source. The source is right here: https://github.com/clojure/clojure and the license that allows you to copy, modify, and redistribute that source is here: https://opensource.org/licenses/eclipse-1.0.php

Rich has a fairly strict development approach and wants to personally review and approve all changes to the core. There are complaints about that process, and that's fair. But as far as I have seen, most large, successful projects have similar personalities leading them (Stallman, Linus, Larry Wall, Guido...).

Finally, I should add -- if what you are looking for is software freedom... then you should absolutely consider using a Lisp like clojure. Lisp's give you the power to control your language through macros and non-core libraries. Unlike other languages, you do not need a core development team to make language changes for you. Perhaps this is why clojure is so powerful... because the core process issues you have heard about are not actually that important, and in fact the language itself enables substantially more software freedom than perhaps you are giving it credit for.

Comment · 7 years ago

have you written your own 2/3 compatibility layer? I can't imagine writing anything large without six...

fwiw, six can easily be vendored into a project to avoid the technical external dependency. that is how we manage it for kafka-python.

Comment · 8 years ago

Congrats + well done!

Comment · 8 years ago

Have you read Zen and the Art of Motorcycle Maintenance? You might enjoy it. A thoughtful book (semi-autobiographical) about a man searching for meaning, thinking-through-it-all while riding his motorcycle across the country with his son.

Comment · 9 years ago

*Or she.

But that's an interesting point re mining pools. Do you have any links to more information about how they drastically changed dynamics?

Comment · 9 years ago

I guess I just have never found support for that in the nakamoto paper. You obviously have strong feelings about it, and I'm not trying to provoke an argument. I just still don't understand where in the paper there is any discussion of non-mining nodes. The only place I can find mention of nodes that are not working on constructing new blocks on the network is in Section 8 re: the simplified verification protocol.

Comment · 9 years ago

That seems inconsistent with the paper. For example, from the conclusion:

  [Nodes] vote with their CPU power, expressing their acceptance of
  valid blocks by working on extending them and rejecting invalid blocks by refusing to work on
  them. Any needed rules and incentives can be enforced with this consensus mechanism.

I do see the separate section on "Simplified Payment Verification", which does seem distinct from mining. Is that what you are referring to?

Comment · 9 years ago

This seems incorrect. Isn't a node a process on the network that is mining blocks? It does not seem as if a process that simply reads blocks but does not add any hashrate is participating in the network as I understand it.

Comment · 9 years ago

fantastic project -- I've been waiting for someone to tackle this!

Comment · 10 years ago

> In FP you will end with garnishFingerFood and garnishCocktail because you need to encode somewhere a specifics of garnish action. In OOP you will have garnish methods on Coctail and FingerFood and specifics and related knowledge how you need to perform garnish will be on object itself.

You're complecting. In the real world of Clojure, you could simply define a protocol and provide different implementations of "garnish".

Comment · 10 years ago

Extremely negative review -- wow.

Comment · 10 years ago

No apology required. Though note that pykafka requires >=0.8.2 , and is only forwards compatible w/ newer brokers. This means that pykafka implements the 0.8.2 feature set. Newer brokers support that feature set, but you are not taking advantage of 0.9 or 0.10 features if you connect to them. kafka-python, on the other hand is both forwards and backwards compatible. It supports all feature sets: from no offsets in 0.8, to zk offests in 0.8.1, to kafka offsets in 0.8.2, to group management in 0.9, to message timestamps and relative-offset compressed messages in 0.10. The feature set to use is chosen based on the broker version we're connected to. As far as I know, no other client supports this approach -- not python, not java, etc. [Though KIP-35 should open this up to other clients for backwards compatibility starting at 0.10]

Comment · 10 years ago

I enjoyed your blog post, but I don't think this is a fair characterization: kafka-python is not "mostly 0.9+ focused..." kafka-python is the only driver that is both forward and backwards compatible w/ kafka 0.8 through 0.10. As I'm sure you remember, kafka-python was the original 0.8 driver, written to support the 0.8 protocol b/c Samsa (pykafka's previous incarnation) was only supporting 0.7 and did not have any plans to upgrade.