quelgar

Every Argument for Static Typing Applies to Typed Errors

Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.

An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.

Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty

ruanbekker

AddOn:

• https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/

1. Go to about:support in your address bar
2. Look for your profiles directory and open it:

3. Create a file named chrome/userChrome.css in your profile directory:

jdegoes

Applied Functional Programming with Scala - Notes

Copyright © 2016-2018 Fantasyland Institute of Learning. All rights reserved.

1. Mastering Functions

A function is a mapping from one set, called a domain, to another set, called the codomain. A function associates every element in the domain with exactly one element in the codomain. In Scala, both domain and codomain are types.

val square : Int => Int = x => x * x

SzymonPobiega

If you have two days to learn the very basics of modelling, Domain-Driven Design, CQRS and Event Sourcing, here's what you should do:

In the evenings read the [Domain-Driven Design Quickly Minibook]{http://www.infoq.com/minibooks/domain-driven-design-quickly}. During the day watch following great videos (in this order):

1. Eric Evans' [What I've learned about DDD since the book]{http://www.infoq.com/presentations/ddd-eric-evans}
2. Eric Evans' [Strategic Design - Responsibility Traps]{http://www.infoq.com/presentations/design-strategic-eric-evans}
3. Udi Dahan's [Avoid a Failed SOA: Business & Autonomous Components to the Rescue]{http://www.infoq.com/presentations/SOA-Business-Autonomous-Components}
4. Udi Dahan's [Command-Query Responsibility Segregation]{http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation}
5. Greg Young's [Unshackle Your Domain]{http://www.infoq.com/presentations/greg-young-unshackle-qcon08}
6. Eric Evans' [Acknowledging CAP at the Root -- in the Domain Model]{ht

joshwand

ganked from unreadable scribd doc here: http://cleancoder.posterous.com/what-killed-waterfall-could-kill-agile

What Killed Waterfall could Kill Agile.

Robert C. Martin
20 Nov, 2010

In 1970 a software engineer named Dr. Winston W. Royce wrote a seminal paper entitled Managing the Development of Large Software Systems. This paper described the software process that Royce felt was appropriate for large-scale systems. As a designer for the Aerospace industry, he was uniquely qualified.

He began the paper by setting up a straw-man process to knock down. He described this naïve process as “grandiose”. He depicted it with a simple diagram on an early page of his paper. Then the paper methodically tears this “grandiose” process apart. In the end, Royce proposed a far more nuanced and insightful approach, leaving the reader to giggle at the silliness of the “grandiose” model.