I think this gets to the crux of the issue. My reading of the article is that they are focusing on the ability of a citizen to control his identity - adding a biometric component to our current means of authentication such as a drivers license is a way to guard against being impersonated by others. I believe that their point is that fear of losing anonymity has caused us to settle for a low level of authentication. A problem with RealID is that if this system gains an underserved trust then it will be harder to fix the damage when you are impersonated by someone with a fake RealID. So a RealID that uses biometrics would be preferable to one that is easier to forge.
Whether the government should mandate / control this biometric information is a good question. The government knows my height, weight, eyecolor, and has some old photos of me at the moment. But would I want them to have a fingerprint? A DNA sample? That would be problematical. The article manages to duck the real issues here - I think that makes their argument a lot less compelling.
Oh, and you can't blame our political ills on Yale profs - it's the students who are doing all the damage.:-)
As a Haskell bigot, I'd definitely go for Haskell over Scheme / Lisp. While the lisp family contains many good things, it's really not that different from the currently popular scripty languages (Python, Ruby, Javascript). With Haskell, you learn a completely new way to think about programming - the type system, laziness, and purity are all important things that you learn about when playing with Haskell. Knowledge of Haskell can make you a better programmer in any language - not just the functional stuff, but the type system (which has had so much influence on Java), the use of laziness (a design pattern in other languages!), and the functional style of thinking. Most current design patterns are just things that current languages are too weak to express as ordinary abstractions - the ability to build these patterns directly without resorting to the "cut/paste" style needed in other languages is well worth investigating. Haskell also has constructs analagous to design patterns (monads and arrows for example) but these are much more mathematical in their foundation.
Haskell has an incredibly active research community that is generating new ways of looking at software way faster than I can keep up - whatever the next big thing in mainstream languages will be it's probably something that the Haskell community is doing right now.
As an educator, I see the other side of this a lot. For everyone who complains about the lack of formal math in the curriculum, I see students who would never survive 2 years of calculus and yet get good jobs in the IT community. There are many students who can't handle intense data structures or low level programming but do fine as network administrators. Over the years, I've seen computer science broaden incredibly. When I was in school, it was obvious what you had to study: low level programming (assembler and Pascal), algorithms (Knuth!), graphics, theory, numerical methods, computer architecture (Bell and Newall), operating systems, some high level programming language like Lisp, and that was it for just about everyone. We always look back to the "good old days" when things were so clearly defined. I'd like to teach a more rigorous program - some catagory theory (just kidding!), some formal methods, Haskell, low level C programming, serious software engineering, whatever. But I'd lose most of my students for no good reason.
If I wanted to complain about something, I'd complain about lack of communication skills among CS graduates. That's something that we can address in higher ed that really impacts everyone with a CS degree, not just some narrow part of the field.
Employers should quit whining and do a better job of looking at the experience and capabilities of their applicants. You can't assume a CS degree means programming. Don't expect us to put all the things you need in the core curriculum - look hard at the advanced courses that an applicant has taken. It's not dumbing down - it's a natural expansion of the field that keeps reducing the common core in CS.
The purely functional approach has a lot of merit. But functional programming by itself probably won't solve the big problems. Erlang has a very specific approach to threads and parallelism that works very well when it's appropriate. A more general approach is taken in Concurrent Haskell (http://en.wikipedia.org/wiki/Concurrent_Haskell), in which a Software Transactional Memory (STM) replaces the lower level mechanisms such as locks that are so crucial to threaded programming. I expect the real breakthrough to occur when high level concurrency tools like STM come into use to replace the existing parallel programming framework of threads and locks. There was a time when everyone assumed that automatic memory management was "too high level / slow / buggy" to be practical in a real programming language but now most programmers are happy to build their programs without worrying about memory allocation. In the parallel world, threads and locks are the malloc / free of the past and something like STM could well be the basis for a higher level approach that will make concurrency a natural way to program.
Slashdot Mirror
Whether the government should mandate / control this biometric information is a good question. The government knows my height, weight, eyecolor, and has some old photos of me at the moment. But would I want them to have a fingerprint? A DNA sample? That would be problematical. The article manages to duck the real issues here - I think that makes their argument a lot less compelling.
Oh, and you can't blame our political ills on Yale profs - it's the students who are doing all the damage. :-)
Haskell has an incredibly active research community that is generating new ways of looking at software way faster than I can keep up - whatever the next big thing in mainstream languages will be it's probably something that the Haskell community is doing right now.
As an educator, I see the other side of this a lot. For everyone who complains about the lack of formal math in the curriculum, I see students who would never survive 2 years of calculus and yet get good jobs in the IT community. There are many students who can't handle intense data structures or low level programming but do fine as network administrators. Over the years, I've seen computer science broaden incredibly. When I was in school, it was obvious what you had to study: low level programming (assembler and Pascal), algorithms (Knuth!), graphics, theory, numerical methods, computer architecture (Bell and Newall), operating systems, some high level programming language like Lisp, and that was it for just about everyone. We always look back to the "good old days" when things were so clearly defined. I'd like to teach a more rigorous program - some catagory theory (just kidding!), some formal methods, Haskell, low level C programming, serious software engineering, whatever. But I'd lose most of my students for no good reason. If I wanted to complain about something, I'd complain about lack of communication skills among CS graduates. That's something that we can address in higher ed that really impacts everyone with a CS degree, not just some narrow part of the field. Employers should quit whining and do a better job of looking at the experience and capabilities of their applicants. You can't assume a CS degree means programming. Don't expect us to put all the things you need in the core curriculum - look hard at the advanced courses that an applicant has taken. It's not dumbing down - it's a natural expansion of the field that keeps reducing the common core in CS.
The purely functional approach has a lot of merit. But functional programming by itself probably won't solve the big problems. Erlang has a very specific approach to threads and parallelism that works very well when it's appropriate. A more general approach is taken in Concurrent Haskell (http://en.wikipedia.org/wiki/Concurrent_Haskell), in which a Software Transactional Memory (STM) replaces the lower level mechanisms such as locks that are so crucial to threaded programming. I expect the real breakthrough to occur when high level concurrency tools like STM come into use to replace the existing parallel programming framework of threads and locks. There was a time when everyone assumed that automatic memory management was "too high level / slow / buggy" to be practical in a real programming language but now most programmers are happy to build their programs without worrying about memory allocation. In the parallel world, threads and locks are the malloc / free of the past and something like STM could well be the basis for a higher level approach that will make concurrency a natural way to program.