iman

"The correct naming of things [...] makes you attractive to women."

I'm curious about this kind of writing in a programming related article. Did any women who read this article feel discomfort when they read this sentence?

I am guessing no, but I would like for the women of this community to answer.

There are languages that have useful features that lisp lacks. For example, Haskell has lazy evaluation and automatic compiler generated program correctness proofs (a decent type system).

Then there are languages that try to be even more powerful than Haskell, for example Epigram, which has dependent types.

Lazy evaluation is probably the language feature that is most mainstream that lisp lacks. For those not familiar with the abstraction benefits of lazy evaluation, consider a library for dealing with prime numbers. In a language without lazy evaluation, you are going to need an API with a function for getting the n_th prime number, a function for testing if a number is a prime number, a function for getting the smallest prime number larger than the number x, and a bunch of other functions.

In Haskell, the API only needs a single variable, called "primes" that is simply the infinite list of all the prime numbers:

primes :: [Integer] -- primes is of type list of Integer

Thanks to lazy evaluation, this single variable is all that is needed to support all of the above operations in an efficient way. For example, to get the n_th prime number you simply write (primes !! n)

Now, this may look cool, but what does it have to do with abstraction? Since "primes" is a regular list, I can use it with any list function and build more complex things out of it. I can also have a list of all the catalan numbers in the same way, and all my functions that I've written that do cool things with the prime numbers can now be instantly used against catalan numbers.

You can manually do lazy evaluation in languages that don't natively have it, but unless you do it everywhere you won't get the abstraction benefits, and if you do do it everywhere then the compiler almost certainly will not be able to optimize it as well as a native implementation.

The user referenced in the article who complains and thinks that he deserves everything for free is not the kind of customer you want.

You can read the thesis that later became "Purely Functional Data Structures" for free online: http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf

It's a great read even for those who don't yet have experience with functional programming.

This looks very similar to the "Eye Drive"[1] mini robot developed by the Israelis, and already in use by the IDF (according to an article[2] in the Jerusalem Post). The company's promotional video[3] of the robot shows it in action.

[1] http://www.odfopt.com/eyedrive/Eye_Drive_home.htm [2] http://www.jpost.com/servlet/Satellite?pagename=JPost/JPArti... [3] http://www.odfopt.com/Movies/eyedrive_new_movie.wmv

4. Game consoles and games are very expensive and thus not very popular in Israel. So all the kids need a computer in order to get their video game fix.

5. There isn't much poverty in Israel.

It would probably be very difficult to find a household in Israel that doesn't have a computer. (Not counting old people who don't know what a computer is)

Are they still free? Or are they now paying renewal fees like the rest of us?

The genetic algorithm technique is often used to solve a problem just because it's cool, and not necessarily because it is the best way to solve the problem.

Is this the case with this "Mona Lisa" problem? Is there an alternative algorithm for finding the polygons that would be more efficient and give better results?

I disagree completely.

It is true that a few years ago, OCaml was more "practical" then haskell. It was faster and had more libraries.

But today haskell is superior to OCaml in nearly all aspects.

As a language, haskell has always been cleaner and more elegant. It has simpler syntax, a more powerful type system, lazy evaluation, and in general more features.

In terms of performance, haskell has caught up with OCaml and exceeded it. The leading haskell compiler(GHC) has been adding in optimizations one after another the past few years. Deforestation, pointer tagging, parallel garbage collection, and other techniques from various research papers. GHC is a top quality professional compiler built by a bunch of geniuses. Haskell also has several implementations and compilers(GHC, Hugs, yhc, nhc, jhc...) while OCaml has only a single implementation.

In terms of tool support, haskell has a debugger(ghci debugger), a profiler(ghc) an excellent documentation generation tool(haddock), and a standard build system(cabal). These are all superior to their OCaml equivalents(where they exist at all: OCaml build systems usually are a mess of makefiles or autohell)

Haskell is catching up to OCaml in the number of libraries available. Haskell now has a CPAN-like website called hackage with hundreds of libraries for all application domains (see the list: http://hackage.haskell.org/packages/archive/pkg-list.html ). Libraries can be downloaded and installed with haskell's build system using a single command, with dependencies also automatically taken care of. The haskell standard library is also a lot better then OCaml's. OCaml has two different incompatible list types(one lazy and one strict). OCaml's file handles can be either written to or read from, not both. (It's not possible to open a file for RW in OCaml). And OCaml infamously requires special syntax for doing arithmatic with floating point numbers(1 + 2 for integer, 3.0 +. 4.0 for floating point).

In terms of community I think that both languages are about equal. Haskell has active and beginner-helpful mailing lists and an IRC channel (one of freenode's most crowded).

Overall, I believe that Haskell is more "practical" then OCaml in nearly every domain. The only thing where OCaml might be preferable is high performance numeric stuff. But this might not be the case for much longer when the haskell GHC compiler will soon get it's new native code generator.

Haskell popularity has been exploding in the past few years, with tons of new libraries and books. There have always been myths about haskell that have caused it to have a perception of being impractical, kind of similar to lisp. But the truth is that haskell is a practical language, and depending on what you need to do, it can even compete with other practical languages like java and python.

The "pain of a monad" is pretty much the same any many other topics in programming that are tricky for beginners: pointers, recursive functions, linked lists, etc. In fact, monads aren't even a language feature, they are a data structure just like a linked list, defined just like any other data structure. There have even been several articles describing how to implement a monad in other popular languages(monads in ruby, monads in C++, monads in lisp).

As for your second question, it's funny that you ask it after mentioning haskell. The solution of course is that a collection of haskell features offer tools that are "better than Lisp macros" and support side effects. Lazy evaluation and monads cover most cases where you would use a macro in lisp. There are also more complex things like comonads and arrows. These solve the problems that lisp macros solve in a different way. And if you really need the ultimate power that lisp macros provide, then the haskell equivalent is template haskell.

But nevertheless, browsers still maintain their own internal cache. Firefox: http://jelmer.jteam.nl/2006/11/04/disabling-the-firefox-dns-...

yeah, chrome tabs are not "shared-nothing".

They have a common document cache, a common cookie store, a common history store, probably a common dns lookup result cache, and maybe some other things. These all need to be carefully synchronized between multiple tabs.

In fact, I would argue that multi threaded would be better than multi process so that even more things could be easily shared. For example, I imagine that css stylesheets are parsed into some big fat data structure inside browsers. If I open two tabs from a website that share a stylesheet it would be optimal if they share this same internal representation (no locking would be required for the sharing since it's read-only). This has the obvious savings of memory, but it also increases speed since the css file only has to be parsed and processed once instead of multiple times. And things like sharing keep-alive connections between tabs are virtually impossible with multi process, while very possible with multiple threads.

Yep, there are many other languages that can be compiled to javascript:

Ocaml to javascript compiler: http://skydeck.com/blog/programming/ocamljs-ocaml-to-javascr...

Haskell to javascript compiler: http://www.haskell.org/haskellwiki/Yhc/Javascript

Haxe to javascript compiler: http://haxe.org/doc/start/js

ECMAScript4 to (classic) javascript compiler: http://ecmascript4.com/

Java to javascript compiler: http://code.google.com/webtoolkit/documentation/com.google.g...

I'm sure there are others as well.

What cpu architectures are supported?

"People ask me who I fear," says Wilbur. "Which of our competition - LucasArts, Microsoft, any of the big companies. They don't frighten me. What I'm afraid of is two guys in a garage, working in total obscurity. That's where the heart and soul of this business is at. Those are the guys who are going to come up with the stuff that blows us out of the water."

From the end of the article:

Advantages: * Despite the number of fans, it was quite a bit quieter than I expected.

So I can have a file evil_applet.jpg that is a valid jpg and also a valid java applet? The website where the file is uploaded will serve the file with a mimetype of jpg.

If I try to force it as an applet on a 3rd party site:

<embed type="java" src="http://facebook.com/profiles/12345/evil_applet.jpg">

The java plugin should refuse to load it since it doesn't have a java mimetype. I'm guessing from the article that the java plugin will load it anyway, which I believe is a bug in the java plugin.

I don't think the websites should have to try to filter beyond verifying that it's a valid image file. Besides the fact that re-encoding jpg images reduces their quality, it is conceivable that it won't even solve the problem.

In a perfect world, the java plugin would not have this bug, but in the real world it might not be a bad idea for websites to try to filter out this specific attack in order to pretect their users.