As long as they're only targeting copyright violations and not attacking BitTorrent directly.
Pirated software, music, and films are an addiction we should all try to cure ourselves of. Spend the time and energy instead on creating and supporting free and open alternatives. It's a lot more fun to actively create than to passively consume anyway.
Haskell is most certainly not dynamically typed. Like ML, it is a statically typed language with a compiler that does type inference at compile type. You don't usually have to manually declare types but you still have to get them right at compile time. There are some differences between ML's type system and Haskell's but they're basically the same animal.
ML and Haskell differ mainly in that ML is an eager language, which evaluates all arguments to functions
before evaluating the function. Haskell is a lazy language which delays evalution of function arguments until their values are needed.
There are three big problems with the way genetic engineering is practiced today:
it's imprecise
Our tools for manipulating genes are still fairly crude. Techniques for
manipluating genes often inadvertently change other, unrelated genes in
unpredictable ways. What's worse, we don't understand genetics well enough yet
to predict what kinds of systemic effects the changes we do intend will produce.
It's considered irresponsible to make even a fairly small local change to a
commercial software system without doing regression testing, yet we're happy to
make large and imprecise changes to systems orders of magnitude more complex
with only superficial testing and validation.
mistakes can be impossible to fix
Once a new genotype is released into the global ecosystem, it's virtually
impossible to limit or contain it. Plans and animals reproduce and migrate at
will. Deadly or destructive genes can infect common species irretrievably.
Already organic farmers are struggling with contamination from pollen from gmo
strains borne by insects and wind. There are virtually no pure organic soybean
farms left in the U.S., for example.
it's under the control of self-interested corporations
Genetic research is expensive and consequently mostly the domain of large
corporations like Monsanto. These corporations act primarily to enrich their
shareholders. It's clear that Monsanto's single-yield seeds are good for
Monsanto, but it's not at all clear that they're good for poor third-world
farmers that can't afford to pay for them each year. We don't allow Du Pont to
sell nuclear bombs, but somehow it's unreasonable to ask for controls on a new
technology that could prove just as destructive.
Some critics of genetic engineering act out of ignorance and fear, but many more
of us simply feel that ge is an incredibly powerful technology that isn't
sufficiently well understood. We don't advocate absolute bans on ge research,
but we do feel it's a bit early to be releasing major variations of staple food
crops into the wild. ge, like all technologies, isn't inherently good or evil
and can be used wisely or unwisely.
Typically, the people who complain the loudest about enforcing spacing in syntax are the same people who write those tangled, dense, single-line statements in C and Perl that inspired their respected obfuscated code contests. You don't need the ability to cram 5 lines of Python in 1 line of Perl. It just hurts maintainability, and there's really no compelling argument for keeping source code dense and compact anymore if it doesn't add speed and remove bloat. (Forgive me if I have unfairly tarred you with this brush, but this has been my general experience.)
It's also a hassle if you're dynamically generating and evaluating code, which is a very, very handy technique in some situations. It's also a problem when you're cutting and pasting code from a newsgroup or email into an editor. It's ALSO a problem if you have several people editing the same source files with different tab settings in their editors. I can't tell you how many times I've broken a script because I've made a quick hotfix with a handy editor that didn't indent the code with the RIGHT whitespace.
I used to think that python's use of whitespace for syntactic grouping was one of it's strengths, but, over the last three years, I've slowly started to see it as one of it's greatest weaknesses. At least the weird scoping is going to be fixed soon!
This is one of the key advantages of FreeBSD's ports system. It installs everything from source, but first performs a checksum validation on the tarball. Expert users can inspect the code manually if they want, but novice users can rest assured they're using untainted code if the checksum test is passed.
Ruby is similar to perl and python in many ways, but brings its own interesting ideas to the table. I find it to be a happy middle ground between perl and python. It's a truly object-oriented language, unlike perl or python, and comes ready for real work with a debugger, profiler, interactive shell and bindings for ldap, snmp, and mysql and postgres. Have a look at the ruby website. Rumor has is that an O'Reilly book is in the works.
also check out the Cyberiad
on
Solaris
·
· Score: 2
Also highly recommended is The Cyberiad, subtitled Fables for the Cybernetic Age. Hilarious and also often profound, Lem's fables are the perfect bedtime stories for the thinking geek.
Teaching the human body to manufacture something like caffeine isn't as simple as just implanting genes from a caffeine-producing plant. You have to trick the body into manufacturing all the machinery for the whole metabolic pathway and somehow also make sure that the body presents a friendly evironment to that machinery. This sort of thing has been done in simple microorganisms and in mammals in a few cases, but it's tricky.
Your accusations of bias are completely unfounded. The paper discussing the
results
of the '99 contest clearly states the objective criteria used to determine the
winners. Entries were judged first on code correctness - each entry had to
correctly process all of the test samples. The prize then went to the entry
that produced the most highly optimized output. In other words, the prize went
to the the entry that objectively produced the most correct and efficient code.
The winners of the '98 contest were simply the best players of the game.
What could be more objective? As far as the Judges' Prize is concerned, the
contest announcement very clearly states:
Finally, the Judges' Prize is to be awarded, not on the basis of the
competition, but solely at the whim and discretion of the judges. Novel
algorithms, interesting languages, beautiful code, arresting user interfaces,
use of parallelism -- these things may well count for something in the judges'
eyes.
This is clearly a subjective decision, but the contest organizers make it very plain
that this is the case.
You could perhaps argue that the choice of problems that involve complex translation
or problem-solving show a bias towards functional languages, but the fact of the matter
is that you'd have a hard time coming up with a good high-level programming problem that
wasn't better attacked with a functional language. The winners give much more lucid
accounts of the advantage of functional languages for complex problem-solving than I
could hope to. They're worth reading.
Another interesting recent study
explored the productivity advantages of lisp over C/C++ or java. Their conclusions are
also very interesting.
The online documentation is admittedly a bit sparse, but there's also a b ook, which, although ambitious, works as an introduction. It uses an older dialect of OCaml, Caml Light (these guys have a sense of humor too), but is still useful for learning OCaml. What we really need is a Learning OCaml, although I'm not sure what the animal would be since the camel is already spoken for.
Believe it or not, there is an O'Reilly Book, but it's only in French right now. There's been a lot of discussion on the OCaml mailing list about an English translation, but you're out of luck for now if you can't read French.
I think the real reason Java and Perl have been successful is that they were all carefully designed to resemble established, popular languages. Stroustup's stated goal in designing C++ was compatibility with C. Java is basically a simplified C++ with garbage collection. Perl is based in awk, sed and unix shell. All of these languages have marginalized languages that are technically superior in many ways - C++ vs. Ada or Modula, Java vs. Smalltalk, and Perl vs. Python.
Unfortunately, most of the obstacles to the acceptance of a new language are social rather than technical. Backward compatibility and the support of a powerful company are key. A new language faces the same resistance that a new operating system does. Corporations and programmers have made substantial investments in their current toolsets and skills and are very reluctant to throw that time and money away. Something like Java, that looks and feels very familiar, is palatable, but something like Haskell causes panic.
Open source programmers are lucky, though, because there are far fewer constraints on the tools and languages they use. We pride ourselves on making design and implementation decisions on a strictly technical basis, and there's no reason we shouldn't make our choice of languages any other way. There are a number of high quality free implementations of functional languages out there.
I've spent the last few years studying functional programming in my spare time. While I'm not sure that I'll ever use a functional language professionally, there's no question that I'm a much better programmer than I would be otherwise. Libraries like the C++ STL and language extensions like Java's anonymous inner classes make a lot more sense if you've been exposed to closures and generic functions. Studying CLOS makes the limitations of single-dispatch OO systems like C++ and Java clear. But most importantly, functional languages help you see the larger picture - to focus on the architecture of a system without getting lost in implementation details. My experience with functional programming has taught me more about software design than the shelves of OO design pattern books and UML bibles I've waded through.
Any programmer that really loves the craft of programming owes it to themselves to take a walk on the wild side with a functional language or two. I'd recommend Ocaml, a mature, full-featured system that comes with a blazingly fast byte-code and native code compiler, a debugger and profiler, a first-class YACC-like compiler generation tool, a full-featured standard library, and a growing collection of contributed code. If you really want your mind blown, read SICP.
It's amusing that Bertrand thinks that the free software movement's dislike of Microsoft stems from some kind of deep-seated jealousy. If you read between the lines and you know something of Bertrand's history, it's easy to see that this attack, like his earlier attacks on C++ and Java, is itself motivated by jealousy. Eiffel has once again been overshadowed by another technology trend, and, once again, he's not taking it well.
Meyer's book is worth a read - he's got a lot of interesting things to say about object-oriented techniques. His political insight is considerably less reliable.
an important issue sensationalized
on
Silicon Hell
·
· Score: 1
While I'm glad they're raising the issue, this article is a bit sensationalistic. For example:
Likewise, other solvents, such as acetone and isopropyl alcohol, "appeared to increase spontaneous abortion risk,"
Acetone is the main ingredient in nail polish remover and isopropyl alcohol is also known as rubbing alcohol and is available at the drug store for about a dollar a pint. Of course, even common household chemicals like these can be dangerous with frequent and excessive exposure, but Cook & Thompson know that referring to them by their chemical names makes them sound exotic and scary.
In fact, all of the chemicals they mention in their article are in wide use in virtuall all other manufacturing industries. The high-tech industry is really no better or no worse than the automobile industry, the home-appliance industry, the toy industry, or the chemical industry on which all of these depend. The real lesson here is that we need to clean up the way we build and power everything from lawn mowers to compact discs.
When it was announced, the guile project was intended to provide the free software community with a truly high-level, general purpose scripting language. It was also supposed to be the main scripting language of GNOME. Since then, I've heard little about it and GNOME/GTK scripting seems to be done mostly in perl or python.
Is guile still a priority for the FSF? Whare are your plans to promote it? I know I'd rather use scheme than perl or python or tcl, but it doesn't seem to be ready.
Slashdot Mirror
Rails supports optimisting locking out of the box. Just add a lock_version column to your table and it will do the rest.
Hopefully the linux developers are skeptical, and not dubious.
As long as they're only targeting copyright violations and not attacking BitTorrent directly.
Pirated software, music, and films are an addiction we should all try to cure ourselves of. Spend the time and energy instead on creating and supporting free and open alternatives. It's a lot more fun to actively create than to passively consume anyway.
Haskell is most certainly not dynamically typed. Like ML, it is a statically typed language with a compiler that does type inference at compile type. You don't usually have to manually declare types but you still have to get them right at compile time. There are some differences between ML's type system and Haskell's but they're basically the same animal.
ML and Haskell differ mainly in that ML is an eager language, which evaluates all arguments to functions before evaluating the function. Haskell is a lazy language which delays evalution of function arguments until their values are needed.
Erlang, on the other hand is dynamically typed.
- it's imprecise
Our tools for manipulating genes are still fairly crude. Techniques for
manipluating genes often inadvertently change other, unrelated genes in
unpredictable ways. What's worse, we don't understand genetics well enough yet
to predict what kinds of systemic effects the changes we do intend will produce.
It's considered irresponsible to make even a fairly small local change to a
commercial software system without doing regression testing, yet we're happy to
make large and imprecise changes to systems orders of magnitude more complex
with only superficial testing and validation.
- mistakes can be impossible to fix
Once a new genotype is released into the global ecosystem, it's virtually
impossible to limit or contain it. Plans and animals reproduce and migrate at
will. Deadly or destructive genes can infect common species irretrievably.
Already organic farmers are struggling with contamination from pollen from gmo
strains borne by insects and wind. There are virtually no pure organic soybean
farms left in the U.S., for example.
- it's under the control of self-interested corporations
Genetic research is expensive and consequently mostly the domain of large
corporations like Monsanto. These corporations act primarily to enrich their
shareholders. It's clear that Monsanto's single-yield seeds are good for
Monsanto, but it's not at all clear that they're good for poor third-world
farmers that can't afford to pay for them each year. We don't allow Du Pont to
sell nuclear bombs, but somehow it's unreasonable to ask for controls on a new
technology that could prove just as destructive.
Some critics of genetic engineering act out of ignorance and fear, but many more of us simply feel that ge is an incredibly powerful technology that isn't sufficiently well understood. We don't advocate absolute bans on ge research, but we do feel it's a bit early to be releasing major variations of staple food crops into the wild. ge, like all technologies, isn't inherently good or evil and can be used wisely or unwisely.It's also a hassle if you're dynamically generating and evaluating code, which is a very, very handy technique in some situations. It's also a problem when you're cutting and pasting code from a newsgroup or email into an editor. It's ALSO a problem if you have several people editing the same source files with different tab settings in their editors. I can't tell you how many times I've broken a script because I've made a quick hotfix with a handy editor that didn't indent the code with the RIGHT whitespace.
I used to think that python's use of whitespace for syntactic grouping was one of it's strengths, but, over the last three years, I've slowly started to see it as one of it's greatest weaknesses. At least the weird scoping is going to be fixed soon!
This is one of the key advantages of FreeBSD's ports system. It installs everything from source, but first performs a checksum validation on the tarball. Expert users can inspect the code manually if they want, but novice users can rest assured they're using untainted code if the checksum test is passed.
Ruby is similar to perl and python in many ways, but brings its own interesting ideas to the table. I find it to be a happy middle ground between perl and python. It's a truly object-oriented language, unlike perl or python, and comes ready for real work with a debugger, profiler, interactive shell and bindings for ldap, snmp, and mysql and postgres. Have a look at the ruby website. Rumor has is that an O'Reilly book is in the works.
Also highly recommended is The Cyberiad, subtitled Fables for the Cybernetic Age. Hilarious and also often profound, Lem's fables are the perfect bedtime stories for the thinking geek.
miles
Teaching the human body to manufacture something like caffeine isn't as simple as just implanting genes from a caffeine-producing plant. You have to trick the body into manufacturing all the machinery for the whole metabolic pathway and somehow also make sure that the body presents a friendly evironment to that machinery. This sort of thing has been done in simple microorganisms and in mammals in a few cases, but it's tricky.
miles
Your accusations of bias are completely unfounded. The paper discussing the results of the '99 contest clearly states the objective criteria used to determine the winners. Entries were judged first on code correctness - each entry had to correctly process all of the test samples. The prize then went to the entry that produced the most highly optimized output. In other words, the prize went to the the entry that objectively produced the most correct and efficient code.
The winners of the '98 contest were simply the best players of the game. What could be more objective? As far as the Judges' Prize is concerned, the contest announcement very clearly states:
This is clearly a subjective decision, but the contest organizers make it very plain that this is the case.
You could perhaps argue that the choice of problems that involve complex translation or problem-solving show a bias towards functional languages, but the fact of the matter is that you'd have a hard time coming up with a good high-level programming problem that wasn't better attacked with a functional language. The winners give much more lucid accounts of the advantage of functional languages for complex problem-solving than I could hope to. They're worth reading.
Another interesting recent study explored the productivity advantages of lisp over C/C++ or java. Their conclusions are also very interesting.
The online documentation is admittedly a bit sparse, but there's also a b ook, which, although ambitious, works as an introduction. It uses an older dialect of OCaml, Caml Light (these guys have a sense of humor too), but is still useful for learning OCaml. What we really need is a Learning OCaml, although I'm not sure what the animal would be since the camel is already spoken for.
Believe it or not, there is an O'Reilly Book, but it's only in French right now. There's been a lot of discussion on the OCaml mailing list about an English translation, but you're out of luck for now if you can't read French.
I think the real reason Java and Perl have been successful is that they were all carefully designed to resemble established, popular languages. Stroustup's stated goal in designing C++ was compatibility with C. Java is basically a simplified C++ with garbage collection. Perl is based in awk, sed and unix shell. All of these languages have marginalized languages that are technically superior in many ways - C++ vs. Ada or Modula, Java vs. Smalltalk, and Perl vs. Python.
Unfortunately, most of the obstacles to the acceptance of a new language are social rather than technical. Backward compatibility and the support of a powerful company are key. A new language faces the same resistance that a new operating system does. Corporations and programmers have made substantial investments in their current toolsets and skills and are very reluctant to throw that time and money away. Something like Java, that looks and feels very familiar, is palatable, but something like Haskell causes panic.
Open source programmers are lucky, though, because there are far fewer constraints on the tools and languages they use. We pride ourselves on making design and implementation decisions on a strictly technical basis, and there's no reason we shouldn't make our choice of languages any other way. There are a number of high quality free implementations of functional languages out there.
I've spent the last few years studying functional programming in my spare time. While I'm not sure that I'll ever use a functional language professionally, there's no question that I'm a much better programmer than I would be otherwise. Libraries like the C++ STL and language extensions like Java's anonymous inner classes make a lot more sense if you've been exposed to closures and generic functions. Studying CLOS makes the limitations of single-dispatch OO systems like C++ and Java clear. But most importantly, functional languages help you see the larger picture - to focus on the architecture of a system without getting lost in implementation details. My experience with functional programming has taught me more about software design than the shelves of OO design pattern books and UML bibles I've waded through.
Any programmer that really loves the craft of programming owes it to themselves to take a walk on the wild side with a functional language or two. I'd recommend Ocaml, a mature, full-featured system that comes with a blazingly fast byte-code and native code compiler, a debugger and profiler, a first-class YACC-like compiler generation tool, a full-featured standard library, and a growing collection of contributed code. If you really want your mind blown, read SICP.
It's amusing that Bertrand thinks that the free software movement's dislike of Microsoft stems from some kind of deep-seated jealousy. If you read between the lines and you know something of Bertrand's history, it's easy to see that this attack, like his earlier attacks on C++ and Java, is itself motivated by jealousy. Eiffel has once again been overshadowed by another technology trend, and, once again, he's not taking it well.
Meyer's book is worth a read - he's got a lot of interesting things to say about object-oriented techniques. His political insight is considerably less reliable.
While I'm glad they're raising the issue, this article is a bit sensationalistic. For example:
Acetone is the main ingredient in nail polish remover and isopropyl alcohol is also known as rubbing alcohol and is available at the drug store for about a dollar a pint. Of course, even common household chemicals like these can be dangerous with frequent and excessive exposure, but Cook & Thompson know that referring to them by their chemical names makes them sound exotic and scary.
In fact, all of the chemicals they mention in their article are in wide use in virtuall all other manufacturing industries. The high-tech industry is really no better or no worse than the automobile industry, the home-appliance industry, the toy industry, or the chemical industry on which all of these depend. The real lesson here is that we need to clean up the way we build and power everything from lawn mowers to compact discs.
When it was announced, the guile project was intended to provide the free software community with a truly high-level, general purpose scripting language. It was also supposed to be the main scripting language of GNOME. Since then, I've heard little about it and GNOME/GTK scripting seems to be done mostly in perl or python.
Is guile still a priority for the FSF? Whare are your plans to promote it? I know I'd rather use scheme than perl or python or tcl, but it doesn't seem to be ready.
miles