daveliepmann

Isn't this the exact same number of keystrokes? 'Shift-3 p' versus 'Shift-9 p' on my keyboard.

It has to do with the fact that air pollution has massively decreased, but cars still kill a lot of people. That's a considered and substantive point, I reckon.

I wrote it because in my experience a "balance" between modes can mean something like Amsterdam, or it can mean the status quo in the USA-outside-NYC, which is to say extreme and punishing car dependence. Sorry if I had you wrongly pegged. My belief is that a good balance is radically fewer cars in city centers. What's your idea of a good balance?

Because rail infra scales really well, bus infra scales well, and bike infra scales well -- while car infra scales disastrously.

This looks like the other completely normal, idiomatic Clojure programs I've seen which manipulate a StringBuilder. And as Clojurians go I'm far to the succinctness/concision-preferring end of the spectrum.

I'm curious to see your core.async-based version :)

No: a Turkish keyboard has separate i/İ and ı/I keys, and Türkish-writing users with an American/international keyboard use a keyboard layout with modifier keys so that the i/I key can be altered to ı/İ. (I do the latter for idiosyncratic reasons.)

The person you're replying to is pointing out that differentiating English-i from Türkish-i requires some other unwieldy workaround. Would you expect manufacturers to add a third key for English i, or for people with Turkish keyboards to use a modifier key (or locale switching) to distinguish i from i? All workarounds seem extraordinarily unlikely.

He didn't mean he'd quit out of boredom, he meant he'd quit out of frustration with proglangs that bite you in the ass when writing e.g. concurrent programs

He wasn't writing corporate CRUD apps, he was working on systems like radio broadcasting, voting machines, and Datomic, which involve significant concurrency challenges.

>I suspect this is the real reason Clojure was created, I bet Rich was just really bored.

I notice too that a noticeable number of people pick up Clojure because it's new and shiny. As a longtime Clojurian I find that attitude can be disappointing to run into, like when you realize a growing friendship will die because they're not serious about living in your city.

I don't claim to know the man but the reasons Rich wanted Clojure are quite concrete, well documented, and rational. Java programs of the time were a particularly heinous form of OOP; we should not be surprised that a clever programmer would grow a preference for a dynamic, functional-first style. He found lisp superior (in interactivity, expressiveness, yadda yadda) and wanted to use it professionally.

To work in lisp required delivering something indistinguishable from a JAR (or other mainstream proglang executable). He had the realization that without immutable data structures baked into the language he'd always be subject to Other People's State.

If you think about these points logically they lead pretty straightforwardly to creating a (pragmatically) functional, dynamic, hosted lisp.

In what context is this terminology standardized?

>Exceptional circumstances, or exceptions for short, mean "things aren't working as expected due to programmer error".

Interesting. In Javaland this describes assertions, and the term exception is for operating errors, i.e. problems not necessarily attributable to programmer error, including your example of a network failure.

Datomic doesn't scale? Quick, tell the largest bank in South America, they must already be collapsing under the weight of all those transactions!

Interop to APL from Clojure is completely wild and masochistic indeed. Hadn't seen this, thanks

>should functions return (value, error), or (error, value)?

a benefit of using maps with error keys :D semantic rather than positional destructuring. also avoids that needlessly obfuscatory Left and Right terminology for Either monads

The "error maps" approach from the article doesn't have Go's compiler enforcement, but shares many attributes including the "being explicit about how to handle an error" aspect you mention.