jwhitlark

There's a moral liability to do your due diligence when using upstream software, too. Otherwise it's just whining about "the untrustworthy system I built upon is untrustworthy".

How cool. I only know of him from these courses, but it was a fantastic intro and overview of distributed systems.

P2P isn't a single thing. But if you know more about what you want to do, you can usually find libraries to do it with.

I recommend Indy's courses for getting the map of the territory: https://www.coursera.org/instructor/indygupta

Yea, I saw several instances of people who milked it for all it was worth, then retired and left everyone else to clean up the mess.

There were people who were fucked, but there were also people that were explicitly taking advantage. I know of two cases were individuals bought lots of property, borrowed to the hilt, took the money out of the country, refused to pay the mortgage, collected rent from renters while the foreclosure process was going on, then rode off into the sunset, retiring on OPM.

It's not shady at all. He wasn't suggesting breaking the contract, just enforcing it. Good luck winning a court case, although you might be able scare some landlords off with court costs. Many would just fight it out on principle, though.

You've got to remember that the landlord's downside can be both large and happen quickly.

My gut feeling is the problem matters more than the language. I'm hopeful with the push to microservices we'll be able to mix and match these things where we think they'll work best.

There's a reason why we teach math in kindergarten and proofs in college. There's lots of things that are useful to do without the rigors of rigorous proof.

Well, there are certainly classes of problems that I'd use static typing for, but in my experience, static typing != software that gets the job done. That doesn't mean that it holds things back, though.

Many static typing arguments remind me of the Air Force's old "We'll bomb them so hard we won't have to send in ground troops." I just haven't seen it in practice, and the few studies that have looked at it empirically haven't seen a clear advantage either. If you know of such a study, please point it out!

In the end, all sorts of combinations have succeeded or failed, to the point where now when people start talking about "the right tool for the job", I add in "the right tool for the right people in the right environment for the right job..."

After my time with Scala, I think that if I need a heavy type system, I'd look to Haskell. And there are certainly classes of problems that I would choose a type system, but the general case isn't nearly as strong as I though it was before seeing them used in anger.

So, in the following, I'm not ranting at you, but I am saying I see lots of arguments for types that jump to QED without nearly enough evidence, with the "everybody knows" kinda explanation. And you happen to have put a handy list right in front of me when I had time to respond.

> ... difficulties with refactoring, runtime errors, needing lots of test coverage and not scaling well to large teams and codebases.

I was really impressed with Scala when learning or toy projects, but every time I saw it in production it was pretty horrid. Small, technical refactoring was taken care of by the IDE, but large scale refactoring takes the same amount of thought as before, but now there's 10x as much code to understand first.

There were less runtime errors, but not much less, and I saw a lot of code that didn't error, but didn't get done what it needed to.

When it comes to scaling to large teams, I saw lots of "The compiler says it's ok, and the tests pass, so commit!" where the code didn't make sense! The old thing about write code for programmers to understand first, and the machine to understand second...

Outside of certain specific situations, I just haven't seen the benefits outweigh the increased code weight and slower time to market.

At its core, spec lets you ask "Do I have what I need to do my job?", and if you have more, spec doesn't care. Type systems answer the question "Do I have exactly the machine primitives I expected, no less and no more".

It's about inspecting and verifying minimums at runtime.

I think of spec like seasoning; if you put lots on everything, you ruin the dish.

In my experience, static typing was somewhat helpful in monolithic projects, but when I saw it used in heterogeneous distributed systems, it seemed to lose much of its benefit and impose new costs.

I'm curious if we're going to see a big new synergy between Kubernetes (represent everything as data) and Clojure (great with data).

I think there needs to be something like the Apache foundation for Clojure libraries, not handling major dev work, but maintaining working libraries over time.

If you can, I'd suggest use spec to improve your understanding and verify behavior. I certainly do know that Clojure can get very dense if you're not careful.

http://blog.cognitect.com/blog/2017/6/19/improving-on-types-...

I think this is a valid point. We talk about the right tool for the job, but forget that the evaluation needs to include the people using the tool, the people paying for the job to be done, and other elements of the environment.

I think some of that is due to the nature of the people it attracts, namely, grumpy, older, I've been burned before, programmers. I use Clojure constantly and have for 10 years, but I've never felt a strong need to proselytize. I just make money and enjoy coding, day in and day out.

Well, I would assume the receiving node would verify that each entry was actually needed.

It's easy to roll back capital costs if you make a mistake. That is far harder to do with people.

Well, at least that's dangerous.

Encryption + lose the key policies seem to satisfy the GDPR. So you don't have to actually delete an event, you can just give up your ability to read its payload.

As a 40+, the first time someone mentioned "the tyranny of the random number generator" it had immediate resonance. It was in a gaming context, but is a useful life metaphor.

A thorough explanation for a 0.1 project seems a high bar. I'd like to see an example or two where it loses data in the manner he speaks of, though.

I wonder sometimes if legal = moral is just a labor saving device for most of the population.

I became much more forgiving about political structures since I started working with distributed system. The ways things go wrong in distributed systems even before you inject free will is staggering.

The link has worthwhile content, and was entertaining. Thanks!

Wasted perhaps in immediate strategic outcomes. But don't discount blooding troops, burning in systems and building institutional knowledge, which are strategic assets. One can certainly argue if it was worth it, though.

You might be right. I do think that by being intentionally hosted, it avoids a number of traditional lisp problems. If it was a stand alone implementation, I wouldn't be nearly as bullish on it.

As my brother likes to say, "good enough is, otherwise they wouldn't call it that."

I think part of the point of clojure is a hosted, small core, programmable programming language can't really die, it would just be dormant and could spring back whenever someone needed it.

It's weird to me when people claim clojure is dying, yet the ecosystem is evolving rapidly and people are making money with it. It's not a model that's easy to starve, it's too lightweight to collapse under it's own load, and there's no way to kill it, so how is it dying?

Mindshare ebbs and flows, but being THE programming language was never clojure's goal.

This is in line with what I was thinking. The constitution is not a suicide pact, and at some point we're going to say you can't distribute certain knowledge. (How to destroy the world in one easy step).

Give that, there's going to be lots of debate where to draw the line, and that's ok. But arguing that there can't ever be a line is the kind of thing which gets people into untenable positions.