Programming at the specification level with Haskell
fpcomplete.com
fpcomplete.com
I see a lot of higher-rank types, like this:
data Event = forall a. Event EvType a
data Event a = Event EvType a
Or is that what you want? Is there a reason why you use higher-rank types (which make my brain hurt, require a lot of language extensions, etc.) rather than parameterized types? If so, could you spell that out?
Another example is this:
data EventF = forall m b c. EventF (b → Transient m c)
Thanks!
In the case of events, it is because I later have to store different event types in a List
so I define the list as [Event] . That is the container that feed the monad with events.
If I define Event as you suggest, I would need a existential type anyway.
data Event a = Event EvType a
data ListEvents= forall a.[Event a]
x :: IO a
f :: a -> m b
Anyway this approach has some problems that I solved in the second part
Am I misusing fpcomplete, or does the code snippet not work?
I don't think this is a real quotation.
http://programmers.stackexchange.com/questions/99166/dijkstr...
Although, OOP is still a mess.
What is intuitive to one is not necessarily intuitive to all.
ideographic writing is more complex and less composable than phonetic writing and yet can express the same ideas.
Subjectively, a chinese can understand Chinese ideograms while maybe he find written English difficult to understand. But a Chinese would learn phonetic writing in less time than ideographic writing and would be capable to express complex ideas using the most composable writing system in less time, no doubt.
"Object" often means "thing of which I have incomplete knowledge". When you have an Object, you've given up on reasoning about it from axiomatic principles or deep knowledge, and you're looking at it holistically alone.
Sometimes, that's just fine. The Unix File concept is a well-designed object, because you can use the read and write system calls without having to know whether it's a regular file, a socket, a tape drive, a memfile, or something else.
While working under incomplete knowledge is sometimes necessary, it's never the ideal. You can use Alan Kay's original OOP principles when software reaches a certain level of complexity, but shouldn't orient your programming around incomplete knowledge or unmanageable complexity. The problem with corporate OOP is that it enables the imprecision-of-thought of technically incompetent software managers and "enterprise architects" who are better at managing up than at solving technical problems.
In fact, Dijkstra spells out the problem with corporate OOP in two words, as quoted in the OP: complexity sells. Complexity + imprecision-of-thought = disaster. And a major reason why top-5% programmers love Haskell is because it simply blocks the imprecision of thought that characterizes typical, business-as-usual, mediocre corporate software development.
This is just random thoughts and there is much more to say. Neither I pretend to tell that OOP is wrong. What I say in the article is that the deconstruction of the recipe that OOP naturally demand is very painful and has too many drawbacks, and can be avoided with the right tools.
The original idea was that, when a piece of software becomes complex, it should be factored out and given a simpler interface. Alan Kay used the cell as a metaphor: it's a complex machine that interacts with the rest of the body using a simpler language of chemical and electrical signals. And that turned out to be such a good idea that you see it even in non-OOP programming tools. Haskell's type classes are a comparable idea. FP picks the best noun (immutable data) and verb (referentially transparent function) for most purposes (of course, the world is stateful and there's some debate over how to manage that). At scale, we also have to deal with the "adjective problem" because we want to be able to code against abstractions rather than (less stable) implementations.
For example, it's a good thing that languages support a File object (an abstraction that Unix is built on) that allows application programmers to avoid having to know what kind of "file" they are dealing with. It's nice being able to use the same language (open/read/write/close) regardless of the physical machinery that the file lives on.
The problem is that corporate OOP has become complexity for it's own sake. Alan Kay wasn't saying, "Go out and design massive, complicated objects". He was only proposing strategies for when complexity became inevitable. Unfortunately, Business OOP (a bastardization of OOP, which had some good ideas at its core) rewards complexity, and you have "enterprise architects" who can't code but are paid to generate massive tangles of lines and boxes.
Thus, the blessing and curse of OOP, respectively, is that it’s ideal for building simulations (the actual point of computers), but also makes it really easy to simulate a worse computer on top of better ones. So, the real tragedy of “Enterprise” OOP is that it basically encourages programmers to first simulate lame computers (e.g. by building frameworks), and then write programs for them.
Ummm ... which combinators? At least provide a link to the prior article that I assume introduced them. As introductions go, this article's introduction doesn't do a very good job.
https://www.fpcomplete.com/user/agocorona/monad-reactive-pro...
https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-work...