anoctopus

If something may or may not be there, that should be a clear part of its type that the compiler checks you handled (even if it's just you deciding to panic, because sometimes that's the right thing to do). Then there can be a type for just the thing, no hidden possibility of it not being there that you have to check for, and almost all code can be written for the type that is guaranteed to be there, with only a little code dealing with only possibly-there values.

Completely agree, although I'm often put off by the comparatively worse ergonomics for the python emulation, to the point that I sometimes miss obvious-in-retrospect places I should be modeling the domain with more variants, even in code I'm already using unions of dataclasses. The ergonomics and clarity of `data Foo = Foo Int | Bar` are incredible.

Parametric polymorphism is great and undervalued by most languages, but ad hoc polymorphism is also valuable at times, mainly when the polymorphic function represents the same abstract operation on distinct types.

No statements means no locals, which is sometimes bad for clarity and/or performance. Functional langs without statements have let-bindings.

Python loses cred in FP circles for being rather opinionated against FP. Map/filter being second-class to list comprehensions, reduce and partial being in functools, and no multi-line lambdas are the obvious/well-known examples of this, but more generally python has first class functions but doesn't make creating and manipulating functions ergonomic.

Automatic, implicit currying is the Haskell feature that most surprised me with how much I like having it. It makes taking apart and composing functions so much nicer, by making a very common case for partial application syntactically and mentally cheap.

Trying to use currying in languages where it isn't built in makes no sense to me. It doesn't seem to compare well against doing the obvious partial application with a lambda. And it doesn't play well with variadic functions, default arguments, etc. (I have ideas for automatic currying of record types that I hope to explore in a toy language at some point, but that only does so much.)

It's another way that social anxiety manifests, as a lower level filter. It's how mine generally shows up, and used to be much worse before I did a bunch of therapy.

One thing that made this being anxiety based very clear was that one night I took phenibut for a party, and the following morning it was still in effect and I found myself thinking of way more jokes and doing little improv reactions to the people I was talking to. It's like my brain was completely filtering them out due to very low level anxiety. I got lucky and the effect partially persisted afterwards, because it taught me that saying these things was safe, so I didn't have anxiety about them afterwards.

It's standard (journalistic) practice to refer to trans people by their preferred pronouns even when referencing events before their transition.

Nostalgia is an odd word to use here when Guile is a Scheme, and so is part of the Lisp family.

Java is still taught in plenty of places and is entrenched enough to stick around for the foreseeable future. The JVM would still be fine even if Java the language declined. Clojure is is a much less vulnerable position than most languages in terms of VM risk, with Clojurescript and ClojureCLR.

The real benefit of native Clojure to me would be for reducing startup time and the JVM overhead in containers. The best option for this right now is CLJS, but it would be nice to just not have a runtime.

>Claim: With this setup, I can’t login easily with my LastPass, 1Password, etc browser extension. >Rebuttal: This is a legitimate claim but it’s equally plausible to use an email integrated browser extension.

You could do that, but since this isn't a very common login scheme, these might not exist/be popular yet. Also, some of us use password managers that aren't browser integrated, and that further reduces the chance of me having a decent workflow for logging in to the site.

For your use case, containers aren't overkill, but a full orchestration system probably is. Just letting some simple outside process just handle starting them up is fine, and Swarm seems to have improved enough that you can use that for single computer "keep my app running with x instances" stuff with no overhead.

Sure it's easy to fix, but it made a ton of scripts stop working despite being otherwise unaffected by the version change, all for the sake of a small syntax change. Unicode strings are a much bigger change and required some effort to fix, but it improved the language semantics while the print change rendered lots of scripts incompatible for no good reason. Just deprecating the old syntax and giving tons of warnings for a while before dropping it would have been much better.

I agree that it isn't the One True Lisp, because there will never be one. Clojure is just a nice, modern lisp with some ideas I really like at the core of it's design.

I don't really care about having conses the way CL has them, and seqs feel like a very nice abstraction over the concept, though I also tend to use the idiomatic map-heavy style anyway.

Clojurescript has the staged macro issue, but JVM Clojure doesn't.

I wouldn't even say that Clojure has an object system, and wouldn't want one. Lacking TCO is a shame.

Immutability was what I had in mind calling it opinionated, and it's an opinion I agree with. After learning Clojure, I now hate working in languages with mutability. It obviously isn't necessary to make working applications, but I like not having to think about where else I'm passing this particular data structure, and the language has enough escape hatches for places when it really would get in the way.

Could you explain what you think is wrong with Clojure? Maybe it's because I've spent far more time using it than CL, but I see Clojure as having a very consistent, well designed core. It's very opinionated in it's design, but it's a practical and pragmatic one. I don't see what's unlispish about it.

I have the 15 in. current gen MBP and had a fair few issues with the hardware. A few kernel patches fixed most of them, but that's more effort than should be needed, and there's still some lingering audio driver issues I haven't resolved.

I'm under the impression that the 13 in. model works without issue.

XNU (the macOS kernel) may have BSD origins, but it doesn't have features like cgroups and process namespacing that the Linux kernel provides and the Docker runtime relies on.

I went to App Academy, and it was definitely worthwhile. I could have gotten the same information elsewhere, but there's a lot of value in having a curated, focused curriculum and a large amount of time dedicated to learning.

It's not that these charges are average, it's that trafficking charges are a distinct group from prostitution; prostitution charges are the far more standard group, and hence are run-of-the-mill, even though the specific charges within that group are not typical of that group.

It isn't directly linked from the front page, but they have a getting started section [0] that covers non-GKE options. I run k8s on AWS using the Kops tool.

Kubernetes is definitely more to learn before getting started than swarm, but that's mostly because it has different and more powerful primitives and more features built in.

[0]: http://kubernetes.io/docs/getting-started-guides/

They could always use a platform that is pay-per-action, so that you aren't paying unless people actually buy things.

(I work on the ad systems team of an affiliate marketing company, where essentially all advertisement contracts are done on a PPA basis, rather than PPC)