I think Armstrong might be discomfited by the well deserved online education in social etiquette and the priority of life (of poorer people) over money. He sorely needs it and he will be the better for it, though a complete cure for him seems impossible.
> Did he say that?
Did I call you an ignorant money peddler, who thinks he is very smart because he can micro analyze statements and completely ignore the context in which the statement was made, as per his convenience?
> Furthermore, insofar as you create competition to hold that position, you're creating a destructive work environment. Software development is a cooperative activity that can't be efficiently partitioned.
Seen way too many of these kinds of management structures. The management decides to appoint the crony as the lead, because picking the best developer is "wasteful" and creates a "destructive work environment". The amount of cringe inducing perversion of logic in the comment above is a tragedy because of its pervasiveness. On the flip side, these kinds of organizations are not too hard to avoid, doomed startups and successful behemoths - both fit these criteria. A smaller company with decent growth is probably the better bet.
I don't know how else to put it, but at least half of what you have written above is completely wrong.
> but they're less useful in other languages where you already have effects everywhere.
Scala has side effects everywhere, yet the Monad is extensively used in Scala programs. Monads have nothing to do with "effects".
Monads are not used to decide the kind of "effects" you are allowed. By calling every Monad a kind of "effect", you are just begging the question. Monads are merely objects that follow 3 monad laws, no more no less.
> This is why Haskell is pure despite having effects. Haskell programs don't do IO, they yield control to the runtime environment whenever IO needs to be done.
How is this different from a C program? Haskell is pure in the presence of IO, because the type system tracks IO calls and forces any function that even indirectly refers to a quantity obtained via IO to modify its type signature to reflect the IO action. This can be done with/without Monads. Haskell IO is a Monad, because it pretty much analogous to the State Monad and Haskell has special Monad syntax that lets you pass the World State implicitly and write imperative code in an imperative style.
> at least half of what you have written above is completely wrong.
That's quite an assertion.
> Scala has side effects everywhere, yet the Monad is extensively used in Scala programs. Monads have nothing to do with "effects".
I didn't say monads weren't used outside of Haskell, I say that they are less useful. I haven't programmed in Scala before, I assume monads are used for their notation. They aren't required.
> Monads are not used to decide the kind of "effects" you are allowed. By calling every Monad a kind of "effect", you are just begging the question. Monads are merely objects that follow 3 monad laws, no more no less.
I don't know if you're familiar with group theory, but in group theory, every finite group is a specialization of the group of permutations. Groups are defined abstractly by the operations that they allow in the same way that monads are, but this definition for finite groups is as general as saying that every group is a subgroup of the group of permutations.
It's the same for monads, they are defined abstractly, but the abstract definition is equivalent to saying monads are all of the things that you can create by a specific kind of specialization of the continuation monad.
Continuations are an effect. Specializations of continuations are also effects. Monads define effects. What's really interesting is thinking about monads in terms of the Curry-Howard Isomorphism, on one end of the scale, the identity monad, you have constructive logic and at the other end, continuations, you have classical logic, what's in the middle? Does the list monad instance have an interesting associated logic?
Which question am I begging?
> How is this different from a C program?
It's just a different way of looking at programs. The distinction is never drawn for C programs.
> Haskell is pure in the presence of IO, because the type system tracks IO calls and forces any function that even indirectly refers to a quantity obtained via IO to modify its type signature to reflect the IO action.
This is quite a shallow way of looking at it.
> This can be done with/without Monads.
Sure, you could use continuations or uniqueness types.
> Haskell IO is a Monad, because it pretty much analogous to the State Monad
AFAIK, that's not defined in the Haskell standard, but that is the way that GHC does it.
> Haskell has special Monad syntax that lets you pass the World State implicitly and write imperative code in an imperative style.
No, it's not syntax that's letting you pass the world state implicitly. In GHC:
IO x = State RealWorld x = (RealWorld -> (RealWorld, x))
You can't get at this function and RealWorld doesn't have any constructors, so you can't call an IO operation or do other weird things. Anyway, it doesn't really matter how IO is actually defined. What matters is it's interface.
Reading your response, I think I need to read more on the topic. I haven't read Moggi's paper and I need to look up on the continuation Monad. You are probably correct and I am probably wrong. However, I will let my original post remain as a matter of historical record :-)
Haskell IO is pure because an IO action is basically just an "instruction". For example, one way to make a pure thing out of a side-effecting procedure is to wrap it in a lambda; it won't do anything until you actually call it, so you can use it as a value. The reason why IO is "separated" by the type system is the same as why Strings are "separated" from Ints: They are different.
The monad operations happen to be a convenient interface for combining IO values to form a composite value that is then called "main", and when the program is actually run, the value of main is executed to produce all the effects.
It is referentially transparent. The lambda (or thunk) itself can be used freely as a value. For example
newtype PureIO a = PureIO (() -> a)
print :: String -> PureIO ()
print s = PureIO $ \_ -> unsafePrint s -- impure primitive
If the user only has access to the "print" variable, then they can only use it as a pure value. two applications of print "foo" would result in two thunks, either of which, when actually invoked, would cause the side-effect of printing "foo".
Invoking the pure IO values is something only the runtime can do, so referential transparency is not violated.
Quite correct. As I'm aware, when you call "main" in Haskell, you're actually building up a really gigantic curried function of type `IO x` (where x is your return type), and then the runtime system runs everything in the curried function all at once. The `RealWorld` symbol is more-or-less an existential type: we can't do anything with it, but it exists to make the type system acknowledge the monadic nature of IO so that we can use monadic combinators to order our curried I/O actions in preparation for their eventual run on real hardware.
He's not begging the question at all. In formal PL terms, a monad and a computational effect (which includes continuations, nondeterminism, and I/O, and loads more interesting stuff) are very strongly connected concepts. If I remember correctly, they may even be equivalent.
Monadic combinators are really just kind of type-sugar. Think: any ordering of computations can be expressed as a tree. However, the only ordering trees a pure-functional language must obey are call-trees (the parameters of a function must be computed before the results of a function, even after lazy-evaluation is taken into account). Monadic programming is a way to transform arbitrary ordering trees of possibly-dynamic depth and width into call trees while preserving the original ordering.
The really neat thing about monads is that they statically guarantee they'll preserve the original ordering, despite its being of dynamic width and depth.
They're very similar. I would say the only difference is that I intend on using function for a specific subset of nonsymbols, and also that I intend for it to be a code construct (nonsymbols are not code; in fact, it's impossible to capture most nonsymbols in code). Pathological nonsymbols do not really feel like functions. However, one could construe nonsymbols as being HOFs (the worst of which would be ill-typed in any sane type system, such as Haskell's).
Any one with work experience and common sense can tell that talking to boss^2 and HR is a recipe for disaster. You are also unwilling to challenge michael's claim that he was meeting expectations and in the midst of a transfer. You also think restricting transfers for 1.5 years is not a problem. Is there any problem within Google that you are willing to admit?
You sound like an HR drone tasked with attacking michael's record with false data. You haven't responded to his claim that his record met expectations. Unless you use a real identity, your claims will have no credibility.
I have work experience and common sense, and I've had success talking to boss^2 and HR.
You get out of life what you put into it. Also, at some point, you have to be willing to take the risk that things won't go well. What's the worst thing they can do? Fire you? Michael was already thinking about leaving anyway.
At some level, you just have to ACT like the company you work for is the company you WANT to work for - and if they don't see it the same way, no hard feelings.
If Google was the company he wanted to work for, and he and his manager didn't get along, what SHOULD he do? Stand up for yourself. Don't quit for the sake of your "permanent record." If there's more to it, then that's fine - but if that's your reason for quitting...?
It's a company, and you have a job. If your manager sucks, say something about it. If that doesn't work, vote with your feet.
Is anyone saying that "Talk to boss^2 and HR" will never work, or just that it's very unlikely to work?
I too have work experience, but perhaps not common sense when it comes to dealing with people, and I never got anything accomplished by talking to boss^2, who as Church noted was more invested in their choice of hiring your boss than in you the underling, and indeed then voted with my feet.
Yes, I think Michael is saying it will never work.
Michael: "If you go to HR, you get fired." "If you go to your boss^2, you are similarly fucked..."
I think that's terrible advice.
I'm sorry you had to vote with your feet, but I'm glad that you did. The only way boss^2 or HR have a chance to learn is if employees do what they're supposed to, and Michael is actively telling people to not do what they're supposed to.