424 karma · joined August 16, 2007
If this was meant to be tongue-in-check, then the writer really needs to do a better job of conveying sarcasm in his writing. However, if this line was meant to be taken seriously, then it displays a shocking level of ignorance regarding fundamental tools. Emacs and vi don't make editing harder, they make it significantly easier.
public class Z {
public interface Function<In,Out> {
public Out apply(In param);
}
public interface RecFunction<In,Out>
extends Function<Function<In,Out>,Function<In,Out>> {
}
private interface FixBody<In,Out>
extends Function<FixBody<In,Out>,Function<In,Out>> {
}
public static <In,Out> Function<In,Out> fix(final RecFunction<In,Out> r) {
return (new Function<FixBody<In,Out>,Function<In,Out>>() {
public Function<In,Out> apply(FixBody<In,Out> f) {
return f.apply(f);
}
}).apply(new FixBody<In,Out>() {
public Function<In,Out> apply(final FixBody<In,Out> f) {
return r.apply(
new Function<In,Out>() {
public Out apply(In x) {
return f.apply(f).apply(x);
}
});
}
});
}
public static final RecFunction<Integer,Integer> fact =
new RecFunction<Integer,Integer>() {
public Function<Integer,Integer> apply(
final Function<Integer,Integer> self) {
return new Function<Integer,Integer>() {
public Integer apply(Integer n) {
if (n == 0)
return 1;
else
return n * self.apply(n-1);
}
};
}
};
public static void main(String[] args) {
Function<Integer,Integer> factorial = fix(fact);
for (int i = 0; i < 10; i++) {
System.out.println("Factorial " + i + ": " + factorial.apply(i));
}
}
}No, you can still have side effect free programming in OO. All of the techniques for programming without using mutable state are language agnostic and should carry over to whatever OO language you are using. You might have problems in languages that lack tail-call optimization, but even that can usually be worked around by using folds.
Now, I'm not claiming that it's feasible to make an entire app in (for instance) Java purely functional, but you can definitely build the majority of your app/library/whatever without using mutable state.
The ones I've looked into whose design I preferred to the Kindle were the Iliad, the Sony Reader, the Hanlin Reader, and the OLPC XO (in e-book mode).
It's not the same category, but there are also dev kits available from e-Ink that are supposed to be suitable for building a prototype e-book reader.
Unfortunately, it does not compare with the e-Ink displays in terms of low power usage, but it is good enough for long reading sessions without straining your eyes.
When I'm reading an e-book, all I want in front of me is a large screen. However, the Kindle sacrifices screen size to make up for a built-in keyboard. 99% of the time that you are using the device you won't have any need for a keyboard, and the Iliad's 8 inch screen would serve you better at those times than the Kindle's 6 inch screen.
For me, the ideal form factor for an e-book reader would look like one of two things:
1) A larger iPod touch with something close to an 8 inch screen.
or
2) An EeePC with a swivel screen so you could use it in e-book mode, similar to the OLPC XO.
Right now I'm using an OLPC XO as an e-book reader, and although it doesn't have as nice a form factor as the Iliad or the Sony Reader, I do consider it significantly nicer than the Kindle. Of course, the low price doesn't hurt either.
According to the wikipedia page (http://en.wikipedia.org/wiki/Type_inference#Hindley.E2.80.93...), it dates back to 1978
http://www.bls.gov/cps/uiclaims.htm
Those numbers also probably understate the problem, but not for the reason you mentioned; the official unemployment numbers do not include people that are underemployed or those that have stopped actively looking for a job.
I've tried explaining the problem to both people who've seen the show and those who haven't. My experience is that if you've seen the show you'll never accept the question, let alone the answer. Meanwhile, those who never watched the show can be convinced.
This is not clear at all. The blog author is simply asserting it without providing any supporting evidence.
The way it does this is that the garbage is detected using the weizenbaum variant of reference counting instead of some form of mark-and-sweep. There are a couple reasons that people tend to prefer mark-and-sweep over reference counting:
1. The reference counts have to be maintained on every assignment operation.
2. Reference counting can break if the heap-allocated memory has cycles.
The first issue is basically what you described when you asked 'is it possible to make a garbage collector that can somehow run "continually"'. The answer is yes, and the way you do that is with reference counting. However, this extra work means that you have a performance hit when compared to mark-and-sweep GCs. It's an example of the classic tradeoff between low latency and high throughput; and most applications are better off with high throughput.
The second issue is the more fundamental one, because cycles in heap allocated memory mean that the reference counts on those memory cells will never drop to zero; hence they will never be reclaimed. Most GCs that use reference counting fix this problem by also using a mark-and-sweep pass to collect cyclic data structures. Of course, this would still not be a real-time collector, so it doesn't fit my needs. Instead I changed the language to not allow cyclic data structures to be created in the first place. The way I did this was to simply make my Lisp dialect purely functional.
In my experience the taste is nothing special, but the texture is notable (the skin is fairly rubbery). More than anything, though, they are hard to eat; not much meat and not really worth the effort.
Also there does appear to be a third-party SSH app (http://code.google.com/p/connectbot/), but I don't have any experience with it.
I think that right now the IPhone is more polished. However, the G-1 is more open, so you may be better off with that in the long term.
http://books.google.com/books?id=JLpYAAAAMAAJ&pg=PA34...
And you actually got the quote pretty close to correct:
"No, sir. When God Almighty lays his hand upon a man, sir, I take mine off, sir."
Certainly the language is pretty powerful, and with Rhino it's fairly easy to integrate with existing libraries.
Obviously, the first step is to use as much existing open source code as possible, but a lot of companies will also need to do some custom infrastructure on top of that. These extensions can be a distraction, so if you can leverage the open source community to help develop/maintain them you will eliminate a huge time sink.
They would have had to make their compiler provide a batch compilation mode in addition to the incremental compilation mode, but that should not be a pain point. After all, batch compiling is easier to do than incremental compiling.