The part where this analogy breaks down is getting the tools to work together; being able to write text munging in PERL, business logic in OO, and the really hairy bits in a functional language.
Doing it UNIX style works for simple architectures, but, as little as I'd like to admit it, the CLR and the JVM may be the only realistic ways to make there parts fit together.
This makes it easier to do proper role-based problem decomposition. Imagine that I have a person class, and that person can sometimes be married. So I make a subclass of person to represent that. oh. well, if they get divorced, I've got to make a new object of the person type and copy over my data, and also update a handle so that all references point to the person object.
And what if we also wanted to model the person's employment status? Well, now we need to somehow order the Married and Employed subclasses so that a person can be any combination of the lot.
Prototypes allow objects to be inherited from. Thus, if aPerson is the parent of both anEmployee and aMarriedPerson, then we get precisely the behavior we want.
Prototypes are like explicit delegation, but with the 'this' value kept at the original reciever. hrm. You could actually build this fairly easily in standard python, w/o even using metaclasses: just override the method lookup functionality to walk the inheritance chain.
How would they even know what the final document would look like?
xdvi? acroread? ghostview?
You need a WYSIWYG interface because the print drivers hooks into the GDI gui, to make sure it the result looks exactly like it does on the screen.
that's a tautology. Of course you need to get what you see if you want to get what you see. Latex isn't WYSIWYG, and I don't think this was ever stated as a requirement for publishing a book.
Would you have any idea what the document would even look like?
To get fancy, yes, you need to peek under the hood, and fsck is it messy under there. fugly, infact.
However, for 90% of tasks, you treat it like html, and you'll be fine. The idea is that you annotate the document with _meaning_ and some smart person (possibly also yourself, but NOT in-line with the text) describes how to typeset this.
Latex: \section{Foo}
some \emph{important} stuff.
html: <h1>Foo</h1>
some <it>important</it> stuff
Actually, it maybe should be <div class=emph>..</div> or somesuch.
mozilla 1.4: ok mozilla 1.6: affected (or whatever I have installed. I can't check as you can't run both mozilla and firefox simultaneously ?!) firebird/phoenix: unaffected. firefox 0.7: affected
I was running firefox (and had been for maybe 8-12 hours since last restart). All of a suddent (after I perhaps a little vigourously paged backwards through a couple of POST forms) it pegged the processor at 100%. Memory was ~50MB, and not swapping. I slowly and laboriously killed all non-vital windows (I had two comparison-shopping carts going that I didn't want to lose), and left it alone. Completly unresponsive. Eventually (after about 5 mins of 100% busyloop) it came back. Now, each click pegged the processor again, and each page load took at least 1 minute. Memory was not growing. Scrolling also very affected, but not nearly as bad as page loads. Eventually, I screendumped the carts and killed it in frustration.
Notice tho: 1) sometimes it can go days. This time not 12 hours. 2) processor is pegged, not memory, eventually dies down, but any activity will peg it again; even simple window-expose redraws.
Now, I'm running mozilla's contributed GTK2+XFT build, so it could well not be a core firefox fault, but as this is the state-of-the art OSS browser, the performance ain't too impressive.
I have never seen this performance with v/ 1.4 on linux or solaris (haven't tried newer versions on solaris, tho).
I was unable to find the orginal (~ feb 22) post on amdzone, so I was unable to judge how relevant or professional it was. Can anyone post a link to it?
Does anyone else see the same behavior I do; that while it starts out snappy, Mozilla gets slower and slower. This is most noticable when rendering tabs in the background; this goes from instantaneous to taking the better part of a minute.
The slowdown from snappy to slow takes a day or two of use, and requires a restart of the browser to fix.
This happens both in mozilla and fire-fox, so it must be some internal resource leak, I guessing.
I think the term block referring to [:args| statements] predates, or at least is contemporary with, the introduction of { } to describe blocks.
In a way, you can see {..} as a handicapped version of [..], in that they are not first class and do not take arguments. To think: C was *that* close to having a proper lambda construct.
Optimizing Haskell by choice unboxings and strictness annotations is against the whole point of the language (*). More imporatantly, it is close to impossible for anyone but the compiler-writer to get right.
Predicting how a lazy program will perform is hard, and figuring out where it hurts is even harder. This is in part due to the massive restructurings the compiler does. One small annotation may be sufficient for the compiler to infer a function's strictness. Knowing where to put the annontation, tho, is nigh guesswork. Then I refactor the function, and there goes my strictness again.
But, this _is_ preferable to writing in C, I'll agree with you there.
(*) However, I think the worker-wrapper transformation may be the most beautiful optimization I've ever seen.
The problem with this approach is that we have to be careful not to attempt to read from the response stream until we have generated a request. Inherent in how this is done is that it is impossible to revoke a request once it is in the request stream; so we can't rewind here either.
In a functional language, we realise that the return value of a function is its output stream, and the argument the input stream:
main:: [IOResponse] -> [IORequest]
Which looks completely screwy. The requests are the result?.
Both continuations and iostreams are purely functional AND a PITA to use. Luckily, both can be expressed as monads.
yes, this is a real problem. I've spoken w/ some of the implementors, and they really thought that strictness analysis would get them a whole lot more.
Lazyness sucks not so much for speed (but this is indeed an issue), but for interacting with foreign functions, and mostly because it breaks tail-recursion. You don't often notice, because haskellers tend to use programming idioms which don't rely solely on tail-recursion.
It also makes predicting the performace of your program almost impossible. Chris Okasaki mentions that most lazy programs are analysed as if they were strict.
A second, smaller problem is that haskellers are really smart. really really smart. This makes easily approachable texts pretty thin on the ground. Two sentences in, you're being bombarded by catamorphisms, anamorphisms, and monoids.
Bird and Wadler is a really nice introductory text.
I thought that the CLI security model was inherently incompatible with the sort of low-level stack and closure manipulation you need to either get tail-recursion of laziness.
Ask again in comp.lang.functiona;l the boffins there are pretty good at explaining this precise question (a VFAQ).
For now, think of monads as bathroom fixtures and monad combinators as plumbing.
You COULD implement variables with state by creating a purely-functional assoc-list and explicitly threading it through your code. The state monad does that for you automatically, by forcing you to write your code as higher order functions, and by linking up the plumbing for you behind the scenes.
As a much simpler example, consider exception handling, were instead of returning a value of type t, a function that can fail returns the type (Maybe t), indicating failure or a returned result.
datatype Maybe t = Fail | Ok t
you could write code like so:
case (funone...) of
Fail -> Fail
| Ok r -> case (funtwo.. r.. ) of
Fail -> Fail
| OK s ->....
All that fail handling gets old pretty quick. Instead, wouldn't it be nicer to write
(or also using do syntax, but I really don't like that)
bindM is a monad combinator, the (\x ->...) are monads. runM encapsulates the whole monad as a normal value.
unitM:: a -> Maybe a bindM:: Maybe a -> (a -> Maybe b) -> Maybe b runM:: Maybe a -> a
these are normal functions, no magic needed (written here using case rather than pattern matching to highlight similarity to above code)
unitM r = Ok a runM m = case m of
Fail = error "oops!"
| Ok r = a
bindM m f = case m of
Fail = Fail
| Ok r = (f r)
(./'s ecode tag is Borken, I think)
... anyway, so what? The cool thing here is that in the case of IO (where instead of doign exception pattern matching, the monad combinators pass a representation of the whole external world), we can prove that the code inside the monads cannot ever directly access the world representation. Thus, the world is single-threaded through the computation. This is good, because then we can skip passing a representation, and just do the IO operations directly on the real world. So we can actually do side-effecting operations in a pure language.
if this doesn't seem like magic, you are either much to smart, or have missed something.
Slashdot Mirror
The part where this analogy breaks down is getting the tools to work together; being able to write text munging in PERL, business logic in OO, and the really hairy bits in a functional language.
Doing it UNIX style works for simple architectures, but, as little as I'd like to admit it, the CLR and the JVM may be the only realistic ways to make there parts fit together.
python is class based, this is object based.
This makes it easier to do proper role-based problem decomposition. Imagine that I have a person class, and that person can sometimes be married. So I make a subclass of person to represent that. oh. well, if they get divorced, I've got to make a new object of the person type and copy over my data, and also update a handle so that all references point to the person object.
And what if we also wanted to model the person's employment status? Well, now we need to somehow order the Married and Employed subclasses so that a person can be any combination of the lot.
Prototypes allow objects to be inherited from. Thus, if aPerson is the parent of both anEmployee and aMarriedPerson, then we get precisely the behavior we want.
Prototypes are like explicit delegation, but with the 'this' value kept at the original reciever. hrm. You could actually build this fairly easily in standard python, w/o even using metaclasses: just override the method lookup functionality to walk the inheritance chain.
with is just a mis-nomer for let, but yes, in general nested lexical scoping for python would rock.
Of course, it's easy to roll your own first class scopes out of classes and the __get__ (or whatever they're called) accessors.
so anyways, back to the question; are those ligatures specific to opentype, or are they also avilible for t1?
oh, that was you! all 38 Mb's worth of eps...
I think by text-wrap, he means flowing text around figures.
but this is demonstrably possible (and also demonstrably not straight forward)
are those ligatures special to opentype? I used latex and bembo t1, and got ff ffi and think ffl. Maybe more, but I think that's it.
How would they even know what the final document would look like?
xdvi? acroread? ghostview?
You need a WYSIWYG interface because the print drivers hooks into the GDI gui, to make sure it the result looks exactly like it does on the screen.
that's a tautology. Of course you need to get what you see if you want to get what you see. Latex isn't WYSIWYG, and I don't think this was ever stated as a requirement for publishing a book.
Would you have any idea what the document would even look like?
stylish? consistent?
To get fancy, yes, you need to peek under the hood, and fsck is it messy under there. fugly, infact.
However, for 90% of tasks, you treat it like html, and you'll be fine. The idea is that you annotate the document with _meaning_ and some smart person (possibly also yourself, but NOT in-line with the text) describes how to typeset this.
Latex:
\section{Foo}
some \emph{important} stuff.
html:
<h1>Foo</h1>
some <it>important</it> stuff
Actually, it maybe should be <div class=emph>..</div> or somesuch.
slashfilter!
Metafilter had this a few days ago.
erm. to clarify
mozilla 1.4: ok
mozilla 1.6: affected (or whatever I have installed. I can't check as you can't run both mozilla and firefox simultaneously ?!)
firebird/phoenix: unaffected.
firefox 0.7: affected
It seems more of a stocastic bug:
I was running firefox (and had been for maybe 8-12 hours since last restart). All of a suddent (after I perhaps a little vigourously paged backwards through a couple of POST forms) it pegged the processor at 100%. Memory was ~50MB, and not swapping. I slowly and laboriously killed all non-vital windows (I had two comparison-shopping carts going that I didn't want to lose), and left it alone. Completly unresponsive. Eventually (after about 5 mins of 100% busyloop) it came back. Now, each click pegged the processor again, and each page load took at least 1 minute. Memory was not growing. Scrolling also very affected, but not nearly as bad as page loads. Eventually, I screendumped the carts and killed it in frustration.
Notice tho:
1) sometimes it can go days. This time not 12 hours.
2) processor is pegged, not memory, eventually dies down, but any activity will peg it again; even simple window-expose redraws.
Now, I'm running mozilla's contributed GTK2+XFT build, so it could well not be a core firefox fault, but as this is the state-of-the art OSS browser, the performance ain't too impressive.
I have never seen this performance with v/ 1.4 on linux or solaris (haven't tried newer versions on solaris, tho).
I was unable to find the orginal (~ feb 22) post on amdzone, so I was unable to judge how relevant or professional it was. Can anyone post a link to it?
Does anyone else see the same behavior I do; that while it starts out snappy, Mozilla gets slower and slower. This is most noticable when rendering tabs in the background; this goes from instantaneous to taking the better part of a minute.
The slowdown from snappy to slow takes a day or two of use, and requires a restart of the browser to fix.
This happens both in mozilla and fire-fox, so it must be some internal resource leak, I guessing.
[NitPick]
I think the term block referring to [:args| statements] predates, or at least is contemporary with, the introduction of { } to describe blocks.
In a way, you can see {..} as a handicapped version of [..], in that they are not first class and do not take arguments. To think: C was *that* close to having a proper lambda construct.
Or you can use the excellent wmx theme for sawfish.
proper lambda abstractions
true, (I do, so I tend to forget); however, you always get the same speed, even though it may not be the one you thought you bought.
I wonder if not partially filled arrays fall into this category.
Bit of a stretch, tho, I agree.
Optimizing Haskell by choice unboxings and strictness annotations is against the whole point of the language (*). More imporatantly, it is close to impossible for anyone but the compiler-writer to get right.
Predicting how a lazy program will perform is hard, and figuring out where it hurts is even harder. This is in part due to the massive restructurings the compiler does. One small annotation may be sufficient for the compiler to infer a function's strictness. Knowing where to put the annontation, tho, is nigh guesswork. Then I refactor the function, and there goes my strictness again.
But, this _is_ preferable to writing in C, I'll agree with you there.
(*) However, I think the worker-wrapper transformation may be the most beautiful optimization I've ever seen.
appart from monads, IO can be done either by continuations: (read (\x->E) as anonymous function taking argument x, with body E)This works because each IO function takes an additional argument -- what to do next. That way, there is no way to 'rewind' the computation.
Another way is to write your program so that it emits a sequence of IO requests, and gets back a stream of IO responses.
An imperative program might look like so
void main(IORequest out, IOResponse in) {
out.add(new FileOpenRequest('foo'));
File fooF = ((FileResponse)in.next()).getFile();
The problem with this approach is that we have to be careful not to attempt to read from the response stream until we have generated a request. Inherent in how this is done is that it is impossible to revoke a request once it is in the request stream; so we can't rewind here either.
In a functional language, we realise that the return value of a function is its output stream, and the argument the input stream:
main
Which looks completely screwy. The requests are the result?.
Both continuations and iostreams are purely functional AND a PITA to use. Luckily, both can be expressed as monads.
Troll?
Anyways, ocaml is quite performant; when people compare its performace to that of C, people aren't really stretching the truth.
Compiling strict languages like scheme and ML to machine code is possible. Doing it well is harder, but several very good compilers exist.
Perhaps you meant _lazy_ functional languages? There are some bigger performance problems in that world, true; see a post above.
Lastly, is performance the only benchmark we use for selecting languages? Is it even the most important one? I surely hope not.
The problem is that haskell is lazy.
yes, this is a real problem. I've spoken w/ some of the implementors, and they really thought that strictness analysis would get them a whole lot more.
Lazyness sucks not so much for speed (but this is indeed an issue), but for interacting with foreign functions, and mostly because it breaks tail-recursion. You don't often notice, because haskellers tend to use programming idioms which don't rely solely on tail-recursion.
It also makes predicting the performace of your program almost impossible. Chris Okasaki mentions that most lazy programs are analysed as if they were strict.
A second, smaller problem is that haskellers are really smart. really really smart. This makes easily approachable texts pretty thin on the ground. Two sentences in, you're being bombarded by catamorphisms, anamorphisms, and monoids.
Bird and Wadler is a really nice introductory text.
I thought that the CLI security model was inherently incompatible with the sort of low-level stack and closure manipulation you need to either get tail-recursion of laziness.
For now, think of monads as bathroom fixtures and monad combinators as plumbing.
You COULD implement variables with state by creating a purely-functional assoc-list and explicitly threading it through your code. The state monad does that for you automatically, by forcing you to write your code as higher order functions, and by linking up the plumbing for you behind the scenes.
As a much simpler example, consider exception handling, were instead of returning a value of type t, a function that can fail returns the type (Maybe t), indicating failure or a returned result.you could write code like so:All that fail handling gets old pretty quick. Instead, wouldn't it be nicer to writeIn haskell, this can also be written:(or also using do syntax, but I really don't like that)
bindM is a monad combinator, the (\x ->
if this doesn't seem like magic, you are either much to smart, or have missed something.