HN user

anttipoi

55 karma
Posts0
Comments18
View on HN
No posts found.

DrRacket? (https://racket-lang.org)

That is what I gave my mom when she asked what she could try programming on. It features a simple whole window editor/repl where you can get straight into business.

What failed was the supporting literature. I thought Realm of Racket would have been ideal for self-study but it did assume more background than she had...

https://www.amazon.com/Realm-Racket-Learn-Program-Game/dp/15...

I found the O'Reilly book Mastering Bitcoin excellent.

It's been a while since a tech book gave me such enjoyment. In an age when when word innovation typically is used to mean "I duck-taped these two turds together" it is great to encounter real novelty in tech.

The book makes the wonder of blockchain easily approachable if you have some background in CS and takes some nice excursions to topics like elliptic crypto.

Some breeds of dogs are very good listeners. I've heard of libraries where they occasionally have a dog around for children to read to: it apparently is a good experience to learn to read by reading out loud to a patient listener.

I've wanted to have a code dog for a long time. I'd invite the bug hound over and explain my code to it.

A friend entered a fake birthday when joining FB, thinking it was not really something FB needs to know about.

The amount of greetings and happy wishes on one random winter day greatly amused him.

Java's Comb-Over 15 years ago

Closures/lambdas in Java may affect how implementations of other JVM languages implement their corresponding features.

This may affect interoperability between languages positively. Currently JVM languages interoperate nicely with Java but advanced non-java-like features between other JVM-based languages do not match so well (can you pass a ruby block from JRuby to Scala?)

I think it was Neal Gafter who raised this as a good reason for closures in Java, but I could be mistaken.

I've now been involved in two projects where I would have needed a queue with following characteristics: - simple pub-sub, queue-like: m producers, n consumers - decent performance (order of hundreds of requests per second) - high availability for message persistence (I don't want to loose messages) - no strict FIFO needed, just some kind of lesser fairness (newer items should not block older ones from passing through)

ActiveMQ with active-backup setup over shared disk mount is the current choice, and the start-up is really slow if the queue has a lot of data.

RabbitMQ does not persist messages in HA fashion, so I've ignored it so far. Maybe HornetQ needs some attention.

I see a lot of flexibility and feature-richness in the queue landscape and it perplexes me that getting this simple combination of basics right is so difficult.