chriskrycho + plt   12

It's Hard to Reason About Systems • Hillel Wayne
Too bad everything we like is nonlinear. By having good tests you can move faster. That’s nonlinear. Types support better refactoring tools? Nonlinear. Using Clojure will attract better developers? Nonlinear. Everything’s nonlinear. And, of course, they don’t have to be first-order. Changing the rate of impact on B can change the rate on C. We can also go deeper: Not only can we change the degree of impacts of actions, we can change how much we change the degree of impacts!

Hopefully you’re starting to see why we can’t reason our way to answers. Programming isn’t a set of isolated factors you can tackle separately. Everything impacts everything else. We can’t solve a complex system with thinking alone. If you disagree, consider physics: there’s no closed-form solution to the three body problem. Why would a 100-body problem be any different?

If software is so complicated, how do we get anything done? Humans are fantastic at rough heuristics. All these complexities soak into our brains and we build an intuition about how it all works. But heuristics are also intensely irrational. That’s not a bad thing! It just means that it depends as much on our experiences, emotions, and muscle memory as it does on our conscious thought. Good for getting stuff done. But the further we get from our narrow experiences, the less useful it becomes. That means it’s pretty bad for finding the objective truth. Just because TDD works for you doesn’t mean it’s the right choice for everyone else. Your intuition about your system may not apply to their system.

When we do communicate, we tend to simplify. This is necessary and practical. Second-order impacts tend to be smaller than first-order impacts, third-order smaller still. We can often disregard them as being small enough to be negligable. Adding tests takes up disk space, but you usually don’t care about that. Using up more disk space means pushing to remote takes slightly longer, but you care even less about that. On the other hand, you can’t always write off the second-order impacts: in fact, we often obsess over them.
agile-software-development  software-development  hillel-wayne  plt  type-theory  testing  systems-engineering  complexity 
october 2018 by chriskrycho
How is a Class like a Microservice? • Hillel Wayne
And without that notation, it’s hard to see that one of the major claimed benefits of a microservice architecture, separation of concerns, is us using devops to compensate for a flaw in our programming language. This doesn’t mean that microservices are bad. What it does mean is that we need to be clear of what we want out of microservices. If we want microservices to improve scalability or use multiple languages, then they may be the right choice. But if we want them primarily for the separation of concerns, I think that’s a bad idea.

Let’s tie this off with an exercise for the reader. Notation is really powerful. With just three components and a couple rules we were able to see symmetries between classes and services. By defining a specific subset of this abstraction we were able to show why Ruby’s module system encourages coupling. But there are all sorts of ways we can strengthen or weaken the model. Just a few examples:

- Arrows have to end at ports. What if we placed restrictions on where they start?
- For proper interfaces, arrows can’t cross into a box. What if arrows couldn’t cross out of a box?
- Can two boxes intersect? Can a box be inside two different boxes at once?
- What if we assigned boxes and ports different “colors” and used that to restrict arrows?
- Make some small tweaks to the model. What real-world programming structures does it represent now? What can we learn from it?
programming  hillel-wayne  plt  software-development  microservices  Ruby  Java  devops 
october 2018 by chriskrycho
Go: the Good, the Bad and the Ugly
Rust is climbing higher in the stack with great web frameworks and nice ORMs. It also gives you that warm feeling of "if it compiles, errors will come from the logic I wrote, not language quirks I forgot to pay attention to".
rust  plt  software-development  programming 
september 2018 by chriskrycho
Exception Handling Considered Harmful
In order to write exception-safe code, at every significant line of code the programmer must take the possibility of an exception and rollback happening into account, to be sure the code cleans up properly and leaves things in a suitable, stable state if an exception occurs – that it doesn't leave a data structure half-modified, or a file or network connection open, for example. That is decidedly non-trivial. It takes a great deal of time and effort, it requires a very high degree of discipline to get right, and it is just far too easy to forget or overlook something – even experts frequently get it wrong.
software-development  product-types  plt  exceptions  programming 
september 2018 by chriskrycho
Three Months of Go (from a Haskeller's perspective)
I will probably never choose to use Go for anything ever again, unless I’m being paid for it. Go is just too different to how I think: when I approach a programming problem, I first think about the types and abstractions that will be useful; I think about statically enforcing behaviour; and I don’t worry about the cost of intermediary data structures, because that price is almost never paid in full.
go  plt  haskell 
march 2017 by chriskrycho
We need better languages for introductory computing. A good introductory language makes good compromises between expressiveness and performance, and between simplicity and feature-richness. Pyret is our evolving experiment in this space.

Of course, even in that setting there are differences of opinion about what needs to be taught. Some believe inheritance is so important it should be taught early in the first semester. We utterly reject this belief (as someone once wisely said, “object-oriented programming does not scale down”: what is the point of teaching classes and inheritance when students have not yet done anything interesting enough to encapsulate or inherit from?). Some have gone so far as to start teaching with Turing Machines. Unsurprisingly, we reject this view as well.
pyret  programming  plt  pedagogy 
march 2017 by chriskrycho
Retrofitting Linear Types
Bernardy, Boespflug, Newton, Peyton Jones & Spiwack: Retrofitting Linear Types
plt  linear-types  haskell  from twitter_favs
march 2017 by chriskrycho
Typestate-oriented programming in F*
> Instead of classes, we declare states. A state is much like a class, but an object can change state during its lifetime; the state of the object is mirrored in the type-system. As you can see in the code above, it’s not possible to open an already opened file, and not possible to close a closed file - the methods do not exist in those states. This check is thought to be done during compile-time. With this technique, a whole new area of bugs are available for compile-time checking....
> Let’s head over to F* and use our new knowledge to mimic the behaviour of typestate-oriented programming.
f-star  refinement-types  effects  monads  typestate  type-theory  plt 
february 2017 by chriskrycho

Copy this bookmark: