I've loved all of the work I've read except Satantango, so if you bounce of that novel I would recommend the rest. That said, I started with the short story collection The World Goes On and thought it was brilliant.
I'm biased because I lived down the street from a bookstore connected to a translation publishing house, but I can't recommend translated fiction enough for opening one's eyes to the weird relationship between a person, their language, and the works they read.
There is a bookstore in Vancouver with a section of translations which is reliably fruitful when I visit. The last book I bought there was a translation of Yuri Herrera's Season of the Swamp. I devoured it, even though I agree that I wish it were more fleshed out. It made me think about reading some of his work in Spanish even though it would be a long process for me. I enjoyed the effort in spanish literature class, maybe I can do it again.
On the topic of the OP, I struggled with Satantango on more than one occasion over the last 12 years. For whatever reason I couldn't get through it, but I've carried the book around through several moves. Maybe I'll try again.
I commented elsewhere: Satantango is easily my least favorite LK so far. If you want to try something else, I would recommend The Melancholy of Resistance as a novel with similar concerns but better execution, War & War as a metafictional odyssey, or the short stories.
"Crashing is loud" below is a phrase to combine with "remote error recovery" from the link above. Erlang/OTP wants application structure that is peculiar to it, and makes that structure feel ergonomic.
> If I ship a feature that has a type error on some code path ... How is "let it crash" helpful to my customer?
The crash can be confined to the feature instead of taking down the entire app or corrupting its state. With a well-designed supervision structure, you can also provide feedback that makes the error report easier to solve.
However, while a type error in some feature path is a place that makes type annotations make sense, type annotations can only capture a limited set of invariants. Stronger type systems encode more complex invariants, but have a cost. "Let it crash" means bringing a supervisor with simple behavior (usually restart) or human into the loop when you leave the happy path.
> "Let it crash" means bringing a supervisor with simple behavior (usually restart) or human into the loop when you leave the happy path.
If a "human" has to enter the loop when a crash occurs, this limits the kind of system you can write.
I had to work on a system where a gen server was responding to requests from a machine, sent frequently (not high frequency, but a few times per second.)
If for some reason the client misbehaves, or behaves properly but happens to use a code path that has a type error, the only option given by "let it crash" was to, well... crash the actor, restart the actor, then receive the same message again, crash the actor, restart the actor, etc... and eventually you crash the supervisor, which restarts and receives the same message, etc...
Over the past several years I have slowly patched the .NET version of Shen to run on Linux and modern .NET releases. I also learned about Higher-Order Perl the other year and have a dream of going through the book and implementing the exercises in Shen while tuning the compiler.
But while I have had a broad interest in compilers for years and years, it feels difficult-to-impossible to actually complete any of it. Part of it's general depression and time management, part is looking at the long story of these projects and the lack of progression: Stuck in a rut of mediocrity.
No worries. One of my personal compiler projects took over ten years to complete. Still worth it, though. Sped up my programming by at least 20x. (Not kidding.)
Edit: Within confidence intervals that is a 22% per year improvement. Way ahead of Proebsting's law. Surprising.
Externs are the main user-facing hurdle, and there's plenty of JS that doesn't bother declaring its shape ahead of time or uses dynamic access patterns.
Hey, that's (close to) the traditional Smalltalk introduction-trick! And this has been available since 1.1? How does one concretely do that in Java and why is it not widely known?
1. There's no way to react to hot reload in the normal Java API, so you can't easily clear state.
2. The JDWP protocol lets debuggers redefine nearly anything, but HotSpot doesn't implement the full protocol. In practice many kinds of reload don't work.
3. To fix those issues app frameworks went with classloaders for partial app reloads instead, or reimplemented hotswap logic themselves (see JRebel).
There's no fundamental reason these can't be fixed, and in fact the Espresso JVM fixes both 1 and 2:
You can write JVM plugins that are invoked after redefinition occurs, allowing you (really your app framework) to do something sensible like partially reload state. And it implements the full protocol, so many more kinds of redefinition work.
Using it is easy. Just install Espresso as your JDK, point your build system at it, then debug your app. Recompiling what attached will cause hot reload.
Interesting, I've never heard of Espresso, I've always just used Jetbrains Runtime[1] instead which is the successor of DCEVM[2] in a way. As for plugins I used HotswapAgent[3] at times however I found it to be rather clunky, does Espresso improve on this aspect?
Well, it doesn't sit that well with mutable global/local state. There is a saying that hot reloading works better if you can replace at a smaller, atomic granularity. In the JVM, this kind of reload is at the method granularity, which may or may not be ideal.
But the JVM still has a few tricks up its sleeve, e.g. the class loader can dynamically re-load a newly compiled version of a class at runtime - jrebel is a proprietary extension that uses both tricks, but this latter can also be used by spring for hot swapping many parts of a running system.
Basically, in the JVM a class is unique within the class loader, so with a new class loader you can load as many class instances of the same, or slightly different class as you wish.
After browsing these comments, I would like to encourage fellow Dallasites to read László Krasznahorkai's short story "Nine Dragon Crossing", available in the collection The World Goes On. It's the most accurate thing I've read about being human amidst our freeways.
But I'll start with the simple version of the critique. Individual commuters make their decision about whether to make a trip based in part on the time that trip will take (a function of road congestion). Thus, adding road capacity will temporarily lower the cost of a trip, allowing more people to make it until congestion reaches the pre-expansion level. Housing does not have this problem because consumers make decisions about where to live much more infrequently.
As you can tell, "induced demand" is a bad if rather catchy name. To be fair to urban planners, the throughput of an expanded road does increase. However, the experience of using it stays the same or gets worse, and the cost (both $ and space) is disproportionate. Is the pro-transit argument, which I subscribe to.
Of course, the real world includes large real estate firms which are making frequent decisions on housing stock. So I agree that the build-more-housing-and-everything-will-improve crowd is wrong. But I don't think YIMBY/transit and anti-transit are the only choices. The former is a common archetype these days.
