james-mcelwain

I feel like most successful generalists approach problems from a perspective of "never stop learning" that is contrary to a false sense of confidence.

In other words, my perspective as a generalist is not that I already know enough about a topic (enough to be dangerous), but rather that I don't know many things but know how to learn quickly.

I think there is some truth that being a generalist requires a degree of confidence and charisma to constantly wade into things out of your depth, but without a healthy dose of fear and respect for the unknown, you're likely to get burned before getting very far.

A Dunning-Kruger generalist just seems like someone who has always gotten lucky with projects and has never had to reckon with running up against their lack of knowledge.

Anyone who writes a ten page essentialist rant about how women are inherently bad at tech is throwing a tantrum.

This is absolutely the biggest wart in modern Java. We now wrap all methods that can throw checked exceptions to rethrow unchecked. This works well for web services that can just retry or rollback and report an error to the client on transient exceptions, but is insufficient for many applications.

Erasure is important in allowing interop from other JVM languages. Reified generics would be nice from the perspective of just writing Java, but the interop story on the JVM is one of its best selling points.

There's very little marginal cost to Google having more news sources.

To be fair, Splunk excels at dealing with unstructured logs, which is in many ways a harder problem. Obviously in a perfect world, all our data would be structured, which would make querying much simpler.

Really don't like the magic field access syntax.

Spring is really nice, but all the flexibility comes at a cost. Annotation meta-programming, runtime reflection, constructing proxies, classpath scanning... all contribute to a perception of slow JVM startup times that makes something like Spring Boot unsuitable for really small services or utilities.

I know there are other Java frameworks out there that are more optimized for smaller modular projects, but there's also the cost of operationalizing the JVM in something like Docker. Fat JAR deployments are relatively simple, but tuning the JVM isn't always straightforward. I'm definitely jealous of the simplicity of producing a single binary as your deployment artifact.

It's not "can run." ClojureScript is a fully supported and viable way to run Clojure in production.

I think they're suggesting that bad latency from a serverless architecture is mitigated by a SPA, since the application can render and appear functional while it's fetching data.

Still, not sure how damage control for poor performance is a "pro" of serverless design.

I'm not sure polymorphism is the best justification for OO. There are plenty of functional paradigms that can abstract over file implementations just as easily as OO. I think the better argument is that a file represents a resource and thus has a more "thingly" character than other "dumb" data.

Definitely don't disagree with anything you say, just don't think the characterization of JS as a strictly imperative language is fair -- especially when compared with C.

Please read more about the history of US involvement in Central and South America.

I think this might be a little unfair to JavaScript. No doubt it's a multi-paradigm language, but there's a huuuge FP community in JS, and loads of code bases (esp. in React) are written in a very functional style. Definitely not comparable to passing function pointers around in C.

Business logic is pure and stateless. Lifting to IO is a breaking change that may or may not require non-trivial refactoring. You shouldn't be putting business logic in your HTTP handlers.

Regardless, the point is not that it's impossible to make such a change in a Haskell code base, just that it may or may not require non-trivial breaking changes, while such a change in an OO enterprise code base will always be trivial.

There's lots and lots wrong with OO patterns, but being able to respond to changing and arbitrary whacky business requirements is a clear strength.

Elasticsearch can index documents dynamically, and doesn't require a schema to create an index. Dynamic data types for fields may not always produce what you want, but it's possible to define a partial schema for the fields that are important and let Elasticsearch handle the rest.

The query language is verbose but I would hesitate to call it a nightmare. You can always search using the Lucene query language, and SQL support is landing sometime soon.

I love Bari. In general, I've found the "deep cuts" in Italy to be way better than the tourist traps. I most recently spent two weeks in rural Sicily where there wasn't much to do and it was fantastic.

Right, I can think of many situations where a new business requirement is like "oh, and for this client, when we do X, we also need to send them an email." OOP, for all its faults, makes this kind of extensibility trivial, where I can't imagine easily making such a change in the context of a statically typed effects system. "This function was pure and now it's not" almost certainly leads to a refactor.

That's not to say that statically typed FP can't be written in such a way to allow this kind of arbitrary modification, but then you get into the realm of finding the perfect abstraction in the type system, which is exactly the same kind of maintenance problem that OO architecture astronauts bring to a code base.

This is all to say -- we should be writing Clojure, which allows a tight focus on actual business requirements while still being flexible enough to allow you to bail out of FP patterns when necessary. :)

One of my friends who is a graduate student complains about the difficulty of collaborating with other scientists who lack strong coding skills. They are so focused on the science that there's no time to learn or practice good code hygiene.

If often wondered why labs don't hire regular developers to increase research veliocity. I have no interest in research, but would happily work in the context of academia doing thing like handling merges, ensuring code modularity, maintaining infrastructure, writing unit tests, etc.

Absolutely. Personally, I like to spam commits while I'm developing, just to make sure I keep track of what I've done while I'm iterating, but none of this is relevant to the final merge. Any individual commit on my feature branch may not even compile, but when that feature is applied to master, I want it to be a clean atomic commit that can easily be reverted or applied to other branches.

bell hooks is not "telling men how to behave." It is a book that seeks to empower men by understanding the structural ways in which masculinity can be harmful to men. This is a positive, affirmative message, not one that seeks censure or exclusion.

Besides, plenty of men have written books about feminism and gender. The reception is fine.

All the normal strategies for dealing with distributed services still apply.

In most of these scenarios, you are still persisting data to stable storage. So, you would take the performance hit and load the data from the database.

The possibilities are kind of limitless. Redis implements a lot of data structures beyond a simple k/v map.

A simple non-caching example, but we use it for distributed locking, more specifically a distributed countdown latch. This is much cleaner and more performant (for us) than doing a similar operation in a traditional RDBMS.

Another very common example that is used in a lot of tutorials is maintaining a leaderboard using a sorted set.

You can slip `void` in after delete an indefinite number of times. You can also do an indefinite number of `new class extends class extends class extends class {} {} {} {} {}`.

I'm confused -- any static typing system is going to need a compilation step to check types. How is typescript any different than "javascript with types" would be? If your goal is live coding, a dynamically typed language will always be faster.

Red line going downtown, which might explain it. I've definitely seen some craziness, but overall I've been pretty happy with the LA metro.

There's tons of police on the metro -- I see them nearly every time I ride.

If you're using an ORM, it can be an easy way to ensure that no vendor specific stuff sneaks in. Also, until recently it was difficult to run, e.g., SQL Server in Docker, so Postgres might be easier to test with. Agreed SQLite is a weird choice, but not all integration tests are robust enough to test characteristics of the underlying db, i.e. focus on business logic not performance.

Émilie from Mutable Instruments (Eurorack) open sources all her modules and uses audio to update modules with new firmware. It's pretty cool! https://github.com/pichenettes/stm-audio-bootloader

Liberals have a tendency to focus on legal frameworks and equality before the law while ignoring the material conditions and the lived experiences of black people.

In some sense, it's trivially true that legal equality means things are "better", but there's plenty of empirical evidence that suggests that material gains won by the civil rights movement have regressed significantly.

For example, in many places, schools are more segregated than they've been since the 60s [1]. Further, the housing crisis erased gains in black wealth back to levels of the 80s and 90s [2].

This is too large a subject to get into in an HN comment, but if you're curious, I'd highly suggest reading Michelle Alexander's excellent book The New Jim Crow[3], which focuses particularly on incarceration.

[1]: https://www.vox.com/2018/3/5/17080218/school-segregation-get... [2]: https://www.peoplespolicyproject.org/wp-content/uploads/2017... [3]: https://www.vanderbilt.edu/ctp/The_New_Jim_Crow.pdf