In fact, it seems to me that 100 lines per day is high when you start talking about very high level languages.
Sure 100 lines of C or even C++ or maybe Java, but in Haskell or Lisp or Prolog, mercury, whatever, you're likely to write 50 or 60 lines per day.
Of course lines per day is an amortized quantity, what really happens is that you think and play for a few days, figure out what you're supposed to be doing, and then write 1000 lines at once, during debugging you rip out a few and replace others, but it took you 10 days total...
My belief (and it mirrors Brook's real take-home message) is that there is a narrow distribution of abilities to grasp a concept in a given time.
His whole point (which no-one seems to be getting on this thread) is that the hard part about software is NOT really the writing of the software.
Yes that's hard (ie. takes up 20% of the total time), but when you get a perfect oracular black box that spits out perfect code instantly as soon as you grasp the way things ought to work, it still doesn't make you 10 times faster (no silver bullet)!
Why? Because it takes time to figure out how things should work, and THAT's what's hard about software. Software is all about solving the hardest problem of all (the way things should work), with the most tractable tools available (words).
We write so much code, because we have to try things out before we know whether they're right or not. And we seem to do that at about the rate of 100 ideas per week with a standard deviation of say 10.
I was under the impression that it was the vendor specifications of the hardware module that were ambiguous. In other words, the rocket put out (let's say)q 15000 lbs of force and they entered it as 15000 newtons (or whatever).
Not so much a software error as an error in understanding.
In general a fuzzy expert system has a slew of if-then rules.
Each If-then rule has a condition that is expressed as a fuzzy membership function, and a consequent that is expressed as a fuzzy membership function.
All the if-then rules are applied "in parallel" to produce a set of fuzzy output sets. These fuzzy output sets are combined in a process called defuzzification (there are many algorithms for this) to produce a definite action (ie. move forward).
The very cool thing about fuzzy rules is that they are generally expressed in terms of linguistic statements that make sense, as in
"if attacked then fight_back" and "if attacked_heavily then retreat".
attacked, fight_back, attacked_heavily, and retreat are all "fuzzy sets" (usually represented as arrays).
Bogofilter is an out of the box C based implementation of naive Bayesian spam filtering that WORKS. I've had 0 false positives over the last several weeks and almost 0 false negatives (maybe 1 or 2) I get about 20 spams per day.
Where would it get the plasmid from? It'd have to be in contact with another (usually living) bacterium to get it. Since the plasmid would be lethal to the carrier, there won't be carriers for the staph infection to acquire it from.
Your idea has merit though, it is possible that a specially engineered plasmid might be made that was activated ONLY in staph aureus, and innoccuous in something like e. coli. or another staph spp.
The point is that people who have good ideas can EXPERIMENT with NEW drivers without crashing the OS.
How many times do you think Alan Cox or Linus Torvalds has experienced a kernel panic???
They DO run drivers that crash the kernel.
It's not about selling to corporate america, it's about letting developers develop OS level tools without lossage.
That being said, HURD still doesn't have user level drivers. They rolled Linux drivers into Mach. I don't know whether the switch to OSKit Mach will help, but this is its biggest problem.
Linux did in 7-8 years what the original Unix system had already done for 15 years before them.
Linux is a good kernel, but it is NOT a new way to design an operating system. HURD is at least somewhat experimental. Since they don't have a rock solid proven technique to copy, it takes them longer.
The HURD people DO have problems, not the least of which is that they're solving a problem people didn't know they had.
The HURD is a good idea, but in my opinion falls short because it doesn't have user land drivers.
Lets face it, drivers are the problem, and the solution is to let user-land programmers work on them, and provide methods for speedy shared memory to make them efficient. HURD still doesn't solve this problem.
But you have to give them credit for the fact that they're creating a system with a completely different underlying methodology than monolithic kernels.
How many terrorists would consider going into an airplane full of 100 armed, responsible, citizens of the US and try to take it over and crash it into a building?
Not many believe me, they'd be looking for much easier targets, like empty parking garages under big buildings or something.
In something like 35 states there are laws requiring concealed weapons permits to be issued to any law abiding citizen that asks for them (with varying levels of qualifications). It isn't given it's proper status as right, but it isn't hard to qualify either.
In other words, in many places in the US, there are no gun battles in the street, yet there already ARE armed citizens aboard buses in office buildings, and throughout cities and highways.
Not nearly enough of them...
Otherwise responsible armed citizens don't commit violent crimes. It's been proven by experience over and over. Without armed citizens around, irresponsible violent people DO successfully commit crimes.
After all, we are currently flying armed air marshals and potentially armed pilots on airplanes.
By the way unarmed people are far more belligerent and fight-prone than armed ones. When there is little consequence there is little restraint.
Gun confiscation is based on irrational fear.
In the wake of Sept 11 there was an incident when a concealed weapon holder boarded an airplane (accidentally) without checking his firearm. If he can do it, why can't terrorists?
Just a bit of trivia. FORTRAN is NOT turing complete.
For example, there is no way to write a Fortran program that computes the summation of two arbitrary numbers without using input and output primitives. (when I say arbitrary i DO MEAN ARBITRARY).
The main reason for this is that Fortran has no memory allocation method. You have to give it a finite initialized memory storage hard coded into the program.
Not only that but Fortran doesn't support recursive functions.
Basically every Fortran program is a huge finite automata.
This of course assumes you aren't using input and output parameters to get arbitrary storage...But that's really ugly.
Not that you can't do useful things with Fortran, but I'd suggest Common Lisp, an ML dialect, and C over Fortran any day.
Aegis development over the internet is PERFECTLY practical. It is in fact the way that Aegis itself is developed I believe.
The change set distribution mechanism is NOT built in to Aegis. This is probably what you're talking about. However it is trivial to distribute aegis changes through a web server and a simple cgi script. It's possible that Aegis already includes this functionality in the aegis web based tools.
Distributing aegis change sets is literally as easy as "aedist -send -p myproject -c 22 > myproject.22.aed"
If you're using CVS, strongly consider switching to Aegis. There's even a cvs user's howto for aegis, and a tool that automatically imports the CVS repository to Aegis.
I was an undergraduate math major (graduated 5 years ago). I was excellent at it, but unfortunately in the "real world" there is little opportunity to use abstract mathematics.
So of course it's easy to miss out on doing math unless you have the time and patience for doing it in your "spare time". Even then, there are certain hurdles that I'd like to overcome. Perhaps some of you can help.
I can also confidently say that it is nearly impossible to really learn advanced math (beyond 3rd year undergraduate) from books alone. The major problem is that math is a very highly compressed field. The notation is usually different from book to book, and the notation is extremely terse. There is rarely any reasonable prose describing why or what motivated a step along the way. Combine this with difficult ideas, and you find that having someone who can help explain why and how to go forward is infinitely more helpful than going alone.
with beginning undergraduate topics like calculus or differential equations, you have comparatively expansive textbooks to describe what and why and how the math was developed along with how it works. It's also usually very applied mathematics. There are plenty of example "real world" problems where you can see how they work. Try that with n-sphere packing or coding theory and it just doesn't work.
However getting access to teachers for advanced courses (beyond 2nd year undergrad) is usually very hard. First, they aren't taught except at universities, (even the small colleges rarely have more than 3 or 4 courses for post 3rd year undergrad) then second they have 1 section and sometimes only tought every other year or every 3rd semester or whatever.
So it's actually hard to even find a place and time to do things like knot theory, algebraic topology, or complex variable analysis.
Has anyone else who has an undergraduate math major been able to go on to do more math other than as a graduate student? I'd love to hear some suggestions as to how to do it.
I was going to take a number theory course at UC berkeley summer session, but it was too much time commitment (commute to berkeley and back, plus 2 hrs lecture 4 times a week)
Has anyone been successful at finding a mentor outside of these channels?
The south rim of the grand canyon is like 100 miles by road from anywhere. The north rim is like 200 miles by road from anywhere.
That being said. It doesn't sound like this guy takes care of his car very well (rev limiter on an automatic?)
There's nothing capitalist about the government mandating on board diagnostics and then letting the car manufacturers put proprietary codes in and refuse to document them.
That being said, this problem isn't as big a deal as you'd think. OBD-II computers exist, and the dealers know what the codes mean. A simple law that required manufacturers to document all software readable codes of OBD systems would be easy to write, and easy to comply with.
not that the government would do a good job of writing this law, just that they COULD.
Being submerged in water causes a hormonal change to reduce the quantity of ADH (anti diuretic hormone) this causes you to need to pee several minutes after being submurged. It's a phenomenon well known to SCUBA divers.
The question is "why don't people get out of the pool and do it?" Well for one thing when they get back in it starts all over again.
For another, most people can't really comprehend how much water is in a pool. it seems like nearly infinite, and therefore their pee is just too small a fraction to matter in their mind. (of course if there are hundreds of people....)
Also I think adults rarely pee in pools. It's usually children.
Plus there may in fact be some sort of built in instinct like response to being submerged. For example there's the "mammalian diving reflex" which causes mammals to hold their breath when submerged, even babys do it. Peeing may be a similar instinct.
As for P2P networks. I think it comes down to time, money, and understanding. Computers ARE difficult to use. There's just so many things you can do with them. Geeks spend a SIGNIFICANT fraction of their life learning these things. Others don't, they spend time doing other things.
So it comes down to people valuing their time more than valuing a clean hard disk. And since they don't know enough about computers to make cleaning their hard disk less time consuming they share broken files.
This is a problem that can be solved though. Technology and trust networks....
What Gupta and Kumar showed was that total capacity scales as sqrt(n) (repeating DOES increase TOTAL capacity! not just range). However per conversation capacity scales as n/sqrt(n) = 1/sqrt(n) -> 0 as n -> inf.
But Gupta and Kumar assume that when one station is transmitting, all others within its radius must be silent.
What Reed claims to be able to take advantage of is the technology of spatial and multi-path deconstruction using software radios that use multiple antennas to seperate multiple signals arriving at the same time on the same frequency. This technology is known as BLAST, and can be found at:
ATT bell labs site
He seems to claim that the combination of multi-path software signal processing, cooperative repeaters, motion of many stations, and a cellular type access to wire or fiber backbones mean that for every new user the total capacity increases enough to support that user without degrading everyone else.
He doesn't seem to have a mathematical proof, but I am thoroughly convinced that we can at least massively scale individual's access to radio based data transmission with better technologies, and it is already the case that the regulations are terrible. So many of his points are right even if hhis theoretical result isn't perfect.
Hopefully I can help clear up some of the extreme misunderstanding of this topic. I am not an expert but I think I understand what is going on better than average.
1) Data capacity is being measured in bit-meters/second because the important question is how quickly can I transfer data between point a and point b. His claim is that technology exists that can make this total capacity grow linearly with the number of participants (and hence essentially no interference occurs between unrelated connections).
The traditional technique to move data from point a to point b is to broadcast at point a with power enough to reach point b on a single fixed frequency slice. imagine point a and b on a map, draw a circle around point a with point b on the circumference. All of the area of the circle has been polluted with the signal. Instead we can use low powered repeaters and have a chain of small circles. Most of the area is unpolluted. Together with spread spectrum, and clever processing with multiple antennas we can pack a lot of information into the available physical and bandwidth space.
The claim is not that our current stupid allocation of radio broadcast stations can be used by everyone at the same time, but that there does exist a technology that will work.
The technology he is talking about is to use low powered high frequency software controlled radios. Each station would be a receiver and relaying transmitter.
Using some system like ipv6 or something cleverer, data is routed through a tight path from radio to radio until it reaches its destination. Because of the nature of radio (and the inverse square law) transmitting this way uses far less total power, and interferes with far less of the world (because the path is a series of tight little circles instead of one enormous circle of radius = distance between endpoints).
The addition of land based cable or optical routing repeaters could scale this even further.
By using radios that can be controlled by software we can continuously improve the bandwidth allocation and routing technology and better sharing of the overall spectrum without the problem of legacy hardware.
Together with intelligent processing of interference with multiple antennas and signal processing techniques, we can scale our wireless data carrying capacity (bit-meters/sec) several orders of magnitude over what we are currently able to use.
If we build the system in layers, we can add application layer protocols like voice over inter-radio, and video over inter-radio, and soforth. If the protocol is smart it can also be linked to land based fiber networks and improved further.
As it is with only a few people controlling fixed slices of bandwidth, I would guess that we might scale total wireless information capacity usable by individuals by 6 to 9 orders of magnitude using these techniques.
One fairly unique reason to learn functional languages is that there are no side effects.
Because there are no side effects debugging becomes easier and can be done more statically (ie. by reading instead of running the code).
With a functional language you can ask the question: Does this function, when fed the right input, produce correct output? And you never have to look outside the function to answer this question (ie. no global variables). This is a MAJOR boon to debugging, because you can debug a single function and you're done with considering that function forever.
Combine this with garbage collection, no pointers, no stack smashing, no "unsafe" data types, compilers that can do some wicked optimizations (like removing entire sections of code because it can prove they will never be called), and some of the other great things about functional languages, and you have a system where you never ever spend time running a debugger asking the question "why is this core dumping" etc.
Depending on who you are you'll get correct running code easily 2 times faster, sometimes 10 times faster, and if you have particularly hairy C/C++ code functional languages can be 100 times faster to write working code.
now as for runtime speed, for compiled functional languages vs well written hand optimized C code, you have a factor of 2 speed difference typically.
On the other hand, the compiled functional code vs TYPICAL C code is often a factor of 2 faster for the functional language, because C is actually hard to write.
functional languages are also easier to profile and remove hot spots from.
Almost no-one catches security intruders, when they do, there's no existing barrier to prosecution or lawsuits within the US. And I think it would be wrong to push for treaties or other measures to make extredition and trial more convenient. There are ligitimate differences of opinion on what constitutes computer intrusion, and being forced to send a 15 year old off to Germany to stand trial won't help.
In my opinion laws go too far already. Computer security breaches should fall under tort law, not criminal law. Anything that could directly harm a person by intrusion shouldn't be on a network. (like radiation beam-line control, or other physical control device).
Hiring programmers not willing to learn a new language is probably not a good idea, certainly not if you are a small(ish) company that needs every advantage you can get.
If you're a contract programmer looking to move from job to job at Fortune 500 companies every 6 months, then by all means stick with C++/Java.
Much of choosing a language (or a project, or even an industry) comes down to being willing to bet the farm on your success. Big companies rarely bet the farm on anything. Small companies have already done it just by starting up. It's not surprising that more and more start ups are choosing Python or Lisp. See Paul Graham's article on "beating the averages" for his take on this issue. Google will find it for you. There were even some slashdot articles about him.
Thanks again for your two part series. As someone who took to scheme immediately as soon as I saw it, and moved into Common Lisp with enthusiasm when I found it, I am familiar with these types of questions.
I especially think your description of a list of language types to learn is valuable to those who haven't had the experience of learning multiple languages.
I want to address a few questions I've heard frequently myself.
1) Why learn XYZ it won't help me get a job or won't be used on the job.
The fact of the matter is that the more you know about how computations CAN be described, the more you will know about what the right way to describe a *particular* computation is. This means when someone comes to you with 150 pages of code in straight C that implements a simple data format parser, or a preferences file reader, or a layout engine for a diagram editor or whatever, if you have seen 5 or 6 different styles of languages and techniques for programming, you will be able to decide how best to attack the problem that needs solving.
Often with the right point of view, a problem becomes an order of magnitude simpler. The beautiful thing about LISP is that it gives you the ability to take so many different points of view within a single language.
I still use flex/YACC, and M4, and sed, shell scripts, and will occasionally write some C/C++ (usually to link into lisp at a hotspot:-)) but when I approach a problem I always think to myself "what is the best way to look at this problem to make it simpler to solve". Often LISP lets me express that solution better than other systems.
This approach is basically the same approach a mathematician takes to proofs and problem solutions. Make the problem smaller, make it more like something we know how to solve...
Here's the other one I hear often:
2) We can't use XYZ there aren't enough people who know XYZ to support it. Go back to (or stick with) C/C++/Java/Perl!
This simply is a way to dodge having to rationally consider a different language or system. The fact of the matter is:
a) Just because you can hire someone who claims to know C/C++ or whatever, doesn't mean you can hire someone who can solve your problem! Programming involves a lot more than just knowing the syntax of a given langauge, and some of the features the library offers.
b) If by switching to something else you can make your problem several times easier, then the cost of training every good candidate vs. sticking to your old ways is essentially negative!
Most of the time, spending a few weeks of training your new candidate in how your system works will pay off big-time when it comes to debugging, quality assurance, adding new features, and even implementing the feature you initially hired them for. Why? Because understanding the PROBLEM and the solution method is much harder than understanding the language syntax, or even most language semantics.
I run my own business, it's just me. My ability to understand a problem, work with people to figure out good implementation strategies, and write code in LISP to rapidly create the products and services I want to provide are all advantages that I got by learning many languages, and especially LISP family languages.
>Well, "so what" is that, if we're not already
>there, we are quickly approaching an era when a
>single person can get off a plane at Chicago
>O'Hare Airport, walk out onto the sidewalk,
>release some kind of gas/germ/nanobot, or
>detonate some device, and kill ALL THE AMERICANS
>ON THE GLOBE, if not all the human beings. And
>there will be no one left to enjoy the freedom.
We are not. And if we were, then no amount of searching people's bags and cars will help. if such a thing existed you'd never get remotely close enough to search for it.
Now take a deep breath and stop spreading irrational fear.
On the other hand, if you're the FBI, or DEA you'd love to have the power to search all kinds of things, and whoops he wasn't a terrorist, but look at these marijuana plants he's got in his garage... or Communist Party slogans (remember McCarthy?) or what have you....
The fallacy is that searching people randomly will help. It won't. It will definitely harm us.
I'm tired of the "I'm tired of whiners mentality."
Yes, security is important, but so are rights. And the two go hand in hand, they are NOT opposed.
I am more afraid of the National Guard at airports than terrorists. I am more afraid of the police and surveillance cameras than I am of anthrax. Why? Not because I'm a criminal, but because I don't have to be if the police have too much power! By the time they have their way with you, it's too late. Look at Rodney King, or the people whose assets have been siezed under anti-drug laws.
No, lets get some REAL security, and REAL freedom at the same time.
1) Stop illegally restricting the Second Amendment. The recent US vs. Emerson case completely affirmed that the second amendment gives citizens a right to keep and bear arms without needing the government's consent. In the majority of states non-felons can already carry firearms, but there is a complex morass of "permit" systems however. Change that to a national one time background check and issue a permit on demand for nominal (read $20 fee) good forever, until revoked by act of law (such as conviction of felony etc).
Lets stop creating "designated target" zones by disarming our citizens at schools, government buildings, airports, on the streets and in their homes... Armed citizens and pilots would have prevented all the 9/11 attacks, at NO cost to liberty or government coffers. Search technology is expensive and considerably (orders of magnitude) less effective, it is almost always used to hassle petty criminals (simply because only 1 in a billion or more searches actually find terrorists).
As for biological agents delivered remotely (ie. the mail). Bio agents can be neutralized by heat, light, and chemicals.
Worried about the mail? Run it through rollers at 170 C. Cost to taxpayers? Minimal. Have a special class of heat sensitive mail (photos, packages, flammables etc) that is subject to different handling.
No searches required.
How about aerosol chemicals, food poisoning, water systems blablabla?
The fundamental question to ask is: does the government have a truly valid reason to suspect you? If yes, they will have no problem getting warrants. If not, they shouldn't be able to search you.
A "reasonable expectation of privacy?"
The reasonability of privacy expectations in a public place is directly related to the unreasonability of allowing free access to that place.
Is it reasonable to allow free access to nuclear weapons? NO. Is it reasonable to allow search free access to a football stadium? YES. You think terrorists will be stupid enough to try to sneak through searches with bombs anyway? Why bother. They'll find some better means to blow you up if they know about the searches.
When it comes to searching employees of NIH, what do they expect to find? Those tiny microbes you've carefully hidden by wiping a billion of them on your left pinky? It'd take several days to grow cultures and detect them. Guns. Not a problem if citizens could have their rights back. Bombs? Don't kid yourself. Who would bother going through the search. Just park the car out front like at Oklahoma city.
Lets get real people, the fact that a few terrorists attacked "designated victims" (read forceably disarmed citizens on an airplane) took control of an airline and smashed it into a building is NOT reason to give free reign to the government to probe our lives. It IS reason to stop creating "designated victims"
Anthrax through the mail? Don't make me laugh. This is a minor procedural problem easily handled by sterilizing mail.
It's impossible to prevent someone from turning common household bleach and ammonia into a chemical warfare agent. Get used to it. Searches won't help us be safe. Quite the opposite.
First off, one of the best spokespersons for Lisp is Paul Graham,
author of "On Lisp" and "ANSI Common Lisp". His web site is Here.
Reading through his articles will give
you a better sense of what lisp is about. One that I'd like to see
people comment on is: java's cover... It resonates with my experience as well. Also This response
to his java's cover article succinctly makes a good point that covers
most of the bickering found here...
I personally think that the argument that Lisp is not widely
known, and therefore not enough programmers exist to support corporate
projects is bogus. The fact that you can hire someone who claims to
know C++ does NOT in any way shape or form mean that you can hire
someone who will solve your C++ programming problem! See my own web
site for more on that.
I personally believe that if you have a large C++ program you're
working on and need to hire a new person or a replacement who already
claims to know C++, the start up cost for that person is the same as
if you have a Lisp program doing the same thing, and need to hire
someone AND train them to use Lisp. Why? the training more than pays
for itself because it gives the new person a formal introduction to
your project, and Lisp is a more productive system than C++ for most
tasks. Furthermore, it's quite likely that the person who claims to
know C++ doesn't know it as well as you would like, and therefore the
fact that you haven't formally trained them on your project is a cost
you aren't considering.
One of the points that the original article by the fellow at NASA
makes is that Lisp turned out to have a very low standard deviation of
run-time and development time. What this basically says is that the
lisp programs were more consistent. This is a very good thing as
anyone who has ever had deadlines knows.
Yes, the JVM version used in this study is old, but lets face it
that would affect the average, but wouldn't affect the standard
deviation much. Java programs are more likely to be slow, as are C++
programs!
The point about lisp being a memory hog that a few people have
made here is invalid as well. The NASA article states:
Memory consumption for Lisp was significantly higher than for C/C++
and roughly comparable to Java. However, this result is somewhat
misleading for two reasons. First, Lisp and Java both do internal
memory management using garbage collection, so it is often the case
that the Lisp and Java runtimes will allocate memory from the
operating system this is not actually being used by the application
program.
People here have interpreted this to mean that the system is a
memory hog anyway. In fact many lisp systems reserve a large chunk of
their address space, which makes it look like a large amount of memory
is in use. However the operating system has really just reserved it,
not allocated it. When you touch one of the pages it does get
allocated. So it LOOKS like you're using a LOT of memory, but in fact
because of the VM system, you are NOT using very much memory at
all.
The biggest reasons people don't use Lisp are they either don't
understand Lisp, or have been forced by clients or supervisors to use
something else.
Slashdot Mirror
In fact, it seems to me that 100 lines per day is high when you start talking about very high level languages.
Sure 100 lines of C or even C++ or maybe Java, but in Haskell or Lisp or Prolog, mercury, whatever, you're likely to write 50 or 60 lines per day.
Of course lines per day is an amortized quantity, what really happens is that you think and play for a few days, figure out what you're supposed to be doing, and then write 1000 lines at once, during debugging you rip out a few and replace others, but it took you 10 days total...
My belief (and it mirrors Brook's real take-home message) is that there is a narrow distribution of abilities to grasp a concept in a given time.
His whole point (which no-one seems to be getting on this thread) is that the hard part about software is NOT really the writing of the software.
Yes that's hard (ie. takes up 20% of the total time), but when you get a perfect oracular black box that spits out perfect code instantly as soon as you grasp the way things ought to work, it still doesn't make you 10 times faster (no silver bullet)!
Why? Because it takes time to figure out how things should work, and THAT's what's hard about software. Software is all about solving the hardest problem of all (the way things should work), with the most tractable tools available (words).
We write so much code, because we have to try things out before we know whether they're right or not. And we seem to do that at about the rate of 100 ideas per week with a standard deviation of say 10.
I was under the impression that it was the vendor specifications of the hardware module that were ambiguous. In other words, the rocket put out (let's say)q 15000 lbs of force and they entered it as 15000 newtons (or whatever).
Not so much a software error as an error in understanding.
Look up info on Fuzzy expert systems.
In general a fuzzy expert system has a slew of if-then rules.
Each If-then rule has a condition that is expressed as a fuzzy membership function, and a consequent that is expressed as a fuzzy membership function.
All the if-then rules are applied "in parallel" to produce a set of fuzzy output sets. These fuzzy output sets are combined in a process called defuzzification (there are many algorithms for this) to produce a definite action (ie. move forward).
The very cool thing about fuzzy rules is that they are generally expressed in terms of linguistic statements that make sense, as in
"if attacked then fight_back" and
"if attacked_heavily then retreat".
attacked, fight_back, attacked_heavily, and retreat are all "fuzzy sets" (usually represented as arrays).
Bogofilter is an out of the box C based implementation of naive Bayesian spam filtering that WORKS. I've had 0 false positives over the last several weeks and almost 0 false negatives (maybe 1 or 2) I get about 20 spams per day.
Where would it get the plasmid from? It'd have to be in contact with another (usually living) bacterium to get it. Since the plasmid would be lethal to the carrier, there won't be carriers for the staph infection to acquire it from.
Your idea has merit though, it is possible that a specially engineered plasmid might be made that was activated ONLY in staph aureus, and innoccuous in something like e. coli. or another staph spp.
You didn't pay attention at all....
The point is that people who have good ideas can EXPERIMENT with NEW drivers without crashing the OS.
How many times do you think Alan Cox or Linus Torvalds has experienced a kernel panic???
They DO run drivers that crash the kernel.
It's not about selling to corporate america, it's about letting developers develop OS level tools without lossage.
That being said, HURD still doesn't have user level drivers. They rolled Linux drivers into Mach. I don't know whether the switch to OSKit Mach will help, but this is its biggest problem.
Linux did in 7-8 years what the original Unix system had already done for 15 years before them.
Linux is a good kernel, but it is NOT a new way to design an operating system. HURD is at least somewhat experimental. Since they don't have a rock solid proven technique to copy, it takes them longer.
The HURD people DO have problems, not the least of which is that they're solving a problem people didn't know they had.
The HURD is a good idea, but in my opinion falls short because it doesn't have user land drivers.
Lets face it, drivers are the problem, and the solution is to let user-land programmers work on them, and provide methods for speedy shared memory to make them efficient. HURD still doesn't solve this problem.
But you have to give them credit for the fact that they're creating a system with a completely different underlying methodology than monolithic kernels.
And your point would be?
How many terrorists would consider going into an airplane full of 100 armed, responsible, citizens of the US and try to take it over and crash it into a building?
Not many believe me, they'd be looking for much easier targets, like empty parking garages under big buildings or something.
In something like 35 states there are laws requiring concealed weapons permits to be issued to any law abiding citizen that asks for them (with varying levels of qualifications). It isn't given it's proper status as right, but it isn't hard to qualify either.
In other words, in many places in the US, there are no gun battles in the street, yet there already ARE armed citizens aboard buses in office buildings, and throughout cities and highways.
Not nearly enough of them...
Otherwise responsible armed citizens don't commit violent crimes. It's been proven by experience over and over. Without armed citizens around, irresponsible violent people DO successfully commit crimes.
After all, we are currently flying armed air marshals and potentially armed pilots on airplanes.
By the way unarmed people are far more belligerent and fight-prone than armed ones. When there is little consequence there is little restraint.
Gun confiscation is based on irrational fear.
In the wake of Sept 11 there was an incident when a concealed weapon holder boarded an airplane (accidentally) without checking his firearm. If he can do it, why can't terrorists?
Perhaps if you can't afford to hire 9 figure salaried actors to do pap, we'll get better movies like My Dinner with Andre
Just a bit of trivia. FORTRAN is NOT turing complete.
For example, there is no way to write a Fortran program that computes the summation of two arbitrary numbers without using input and output primitives. (when I say arbitrary i DO MEAN ARBITRARY).
The main reason for this is that Fortran has no memory allocation method. You have to give it a finite initialized memory storage hard coded into the program.
Not only that but Fortran doesn't support recursive functions.
Basically every Fortran program is a huge finite automata.
This of course assumes you aren't using input and output parameters to get arbitrary storage...But that's really ugly.
Not that you can't do useful things with Fortran, but I'd suggest Common Lisp, an ML dialect, and C over Fortran any day.
Not practical?
Aegis development over the internet is PERFECTLY practical. It is in fact the way that Aegis itself is developed I believe.
The change set distribution mechanism is NOT built in to Aegis. This is probably what you're talking about. However it is trivial to distribute aegis changes through a web server and a simple cgi script. It's possible that Aegis already includes this functionality in the aegis web based tools.
Distributing aegis change sets is literally as easy as "aedist -send -p myproject -c 22 > myproject.22.aed"
wget http://foobar/aegis-sets/myproject.22.aed; aedist -receive myproject.22.aed
If you're using CVS, strongly consider switching to Aegis. There's even a cvs user's howto for aegis, and a tool that automatically imports the CVS repository to Aegis.
I was an undergraduate math major (graduated 5 years ago). I was excellent at it, but unfortunately in the "real world" there is little opportunity to use abstract mathematics.
So of course it's easy to miss out on doing math unless you have the time and patience for doing it in your "spare time". Even then, there are certain hurdles that I'd like to overcome. Perhaps some of you can help.
I can also confidently say that it is nearly impossible to really learn advanced math (beyond 3rd year undergraduate) from books alone. The major problem is that math is a very highly compressed field. The notation is usually different from book to book, and the notation is extremely terse. There is rarely any reasonable prose describing why or what motivated a step along the way. Combine this with difficult ideas, and you find that having someone who can help explain why and how to go forward is infinitely more helpful than going alone.
with beginning undergraduate topics like calculus or differential equations, you have comparatively expansive textbooks to describe what and why and how the math was developed along with how it works. It's also usually very applied mathematics. There are plenty of example "real world" problems where you can see how they work. Try that with n-sphere packing or coding theory and it just doesn't work.
However getting access to teachers for advanced courses (beyond 2nd year undergrad) is usually very hard. First, they aren't taught except at universities, (even the small colleges rarely have more than 3 or 4 courses for post 3rd year undergrad) then second they have 1 section and sometimes only tought every other year or every 3rd semester or whatever.
So it's actually hard to even find a place and time to do things like knot theory, algebraic topology, or complex variable analysis.
Has anyone else who has an undergraduate math major been able to go on to do more math other than as a graduate student? I'd love to hear some suggestions as to how to do it.
I was going to take a number theory course at UC berkeley summer session, but it was too much time commitment (commute to berkeley and back, plus 2 hrs lecture 4 times a week)
Has anyone been successful at finding a mentor outside of these channels?
thanks if you can help
You've obviously never been to the grand canyon.
The south rim of the grand canyon is like 100 miles by road from anywhere. The north rim is like 200 miles by road from anywhere.
That being said. It doesn't sound like this guy takes care of his car very well (rev limiter on an automatic?)
There's nothing capitalist about the government mandating on board diagnostics and then letting the car manufacturers put proprietary codes in and refuse to document them.
That being said, this problem isn't as big a deal as you'd think. OBD-II computers exist, and the dealers know what the codes mean. A simple law that required manufacturers to document all software readable codes of OBD systems would be easy to write, and easy to comply with.
not that the government would do a good job of writing this law, just that they COULD.
Pissing in pools:
Being submerged in water causes a hormonal change to reduce the quantity of ADH (anti diuretic hormone) this causes you to need to pee several minutes after being submurged. It's a phenomenon well known to SCUBA divers.
The question is "why don't people get out of the pool and do it?" Well for one thing when they get back in it starts all over again.
For another, most people can't really comprehend how much water is in a pool. it seems like nearly infinite, and therefore their pee is just too small a fraction to matter in their mind. (of course if there are hundreds of people....)
Also I think adults rarely pee in pools. It's usually children.
Plus there may in fact be some sort of built in instinct like response to being submerged. For example there's the "mammalian diving reflex" which causes mammals to hold their breath when submerged, even babys do it. Peeing may be a similar instinct.
As for P2P networks. I think it comes down to time, money, and understanding. Computers ARE difficult to use. There's just so many things you can do with them. Geeks spend a SIGNIFICANT fraction of their life learning these things. Others don't, they spend time doing other things.
So it comes down to people valuing their time more than valuing a clean hard disk. And since they don't know enough about computers to make cleaning their hard disk less time consuming they share broken files.
This is a problem that can be solved though. Technology and trust networks....
What Gupta and Kumar showed was that total capacity scales as sqrt(n) (repeating DOES increase TOTAL capacity! not just range). However per conversation capacity scales as n/sqrt(n) = 1/sqrt(n) -> 0 as n -> inf.
But Gupta and Kumar assume that when one station is transmitting, all others within its radius must be silent.
What Reed claims to be able to take advantage of is the technology of spatial and multi-path deconstruction using software radios that use multiple antennas to seperate multiple signals arriving at the same time on the same frequency. This technology is known as BLAST, and can be found at: ATT bell labs site
He seems to claim that the combination of multi-path software signal processing, cooperative repeaters, motion of many stations, and a cellular type access to wire or fiber backbones mean that for every new user the total capacity increases enough to support that user without degrading everyone else.
He doesn't seem to have a mathematical proof, but I am thoroughly convinced that we can at least massively scale individual's access to radio based data transmission with better technologies, and it is already the case that the regulations are terrible. So many of his points are right even if hhis theoretical result isn't perfect.
Hopefully I can help clear up some of the extreme misunderstanding of this topic. I am not an expert but I think I understand what is going on better than average.
1) Data capacity is being measured in bit-meters/second because the important question is how quickly can I transfer data between point a and point b. His claim is that technology exists that can make this total capacity grow linearly with the number of participants (and hence essentially no interference occurs between unrelated connections).
The traditional technique to move data from point a to point b is to broadcast at point a with power enough to reach point b on a single fixed frequency slice. imagine point a and b on a map, draw a circle around point a with point b on the circumference. All of the area of the circle has been polluted with the signal. Instead we can use low powered repeaters and have a chain of small circles. Most of the area is unpolluted. Together with spread spectrum, and clever processing with multiple antennas we can pack a lot of information into the available physical and bandwidth space.
The claim is not that our current stupid allocation of radio broadcast stations can be used by everyone at the same time, but that there does exist a technology that will work.
The technology he is talking about is to use low powered high frequency software controlled radios. Each station would be a receiver and relaying transmitter.
Using some system like ipv6 or something cleverer, data is routed through a tight path from radio to radio until it reaches its destination. Because of the nature of radio (and the inverse square law) transmitting this way uses far less total power, and interferes with far less of the world (because the path is a series of tight little circles instead of one enormous circle of radius = distance between endpoints).
The addition of land based cable or optical routing repeaters could scale this even further.
By using radios that can be controlled by software we can continuously improve the bandwidth allocation and routing technology and better sharing of the overall spectrum without the problem of legacy hardware.
Together with intelligent processing of interference with multiple antennas and signal processing techniques, we can scale our wireless data carrying capacity (bit-meters/sec) several orders of magnitude over what we are currently able to use.
If we build the system in layers, we can add application layer protocols like voice over inter-radio, and video over inter-radio, and soforth. If the protocol is smart it can also be linked to land based fiber networks and improved further.
As it is with only a few people controlling fixed slices of bandwidth, I would guess that we might scale total wireless information capacity usable by individuals by 6 to 9 orders of magnitude using these techniques.
E = mC^2, mass is energy according to current theory. Therefore losing energy IS losing mass (albeit a small amount, because E/C^2 = m).
But I know what you meant...
Doesn't the "solar sail" concept essentially react to the momentum of photons?
Aegis does all of those.
The main thing about Aegis is that it enforces a process. I doubt Linus would conform to the Aegis process if he just now got version control.
One fairly unique reason to learn functional languages is that there are no side effects.
Because there are no side effects debugging becomes easier and can be done more statically (ie. by reading instead of running the code).
With a functional language you can ask the question: Does this function, when fed the right input, produce correct output? And you never have to look outside the function to answer this question (ie. no global variables). This is a MAJOR boon to debugging, because you can debug a single function and you're done with considering that function forever.
Combine this with garbage collection, no pointers, no stack smashing, no "unsafe" data types, compilers that can do some wicked optimizations (like removing entire sections of code because it can prove they will never be called), and some of the other great things about functional languages, and you have a system where you never ever spend time running a debugger asking the question "why is this core dumping" etc.
Depending on who you are you'll get correct running code easily 2 times faster, sometimes 10 times faster, and if you have particularly hairy C/C++ code functional languages can be 100 times faster to write working code.
now as for runtime speed, for compiled functional languages vs well written hand optimized C code, you have a factor of 2 speed difference typically.
On the other hand, the compiled functional code vs TYPICAL C code is often a factor of 2 faster for the functional language, because C is actually hard to write.
functional languages are also easier to profile and remove hot spots from.
I mean it.
The government can do nothing but damage.
Almost no-one catches security intruders, when they do, there's no existing barrier to prosecution or lawsuits within the US. And I think it would be wrong to push for treaties or other measures to make extredition and trial more convenient. There are ligitimate differences of opinion on what constitutes computer intrusion, and being forced to send a 15 year old off to Germany to stand trial won't help.
In my opinion laws go too far already. Computer security breaches should fall under tort law, not criminal law. Anything that could directly harm a person by intrusion shouldn't be on a network. (like radiation beam-line control, or other physical control device).
Hiring programmers not willing to learn a new language is probably not a good idea, certainly not if you are a small(ish) company that needs every advantage you can get.
If you're a contract programmer looking to move from job to job at Fortune 500 companies every 6 months, then by all means stick with C++/Java.
Much of choosing a language (or a project, or even an industry) comes down to being willing to bet the farm on your success. Big companies rarely bet the farm on anything. Small companies have already done it just by starting up. It's not surprising that more and more start ups are choosing Python or Lisp. See Paul Graham's article on "beating the averages" for his take on this issue. Google will find it for you. There were even some slashdot articles about him.
Thanks again for your two part series. As someone who took to scheme immediately as soon as I saw it, and moved into Common Lisp with enthusiasm when I found it, I am familiar with these types of questions.
:-)) but when I approach a problem I always think to myself "what is the best way to look at this problem to make it simpler to solve". Often LISP lets me express that solution better than other systems.
I especially think your description of a list of language types to learn is valuable to those who haven't had the experience of learning multiple languages.
I want to address a few questions I've heard frequently myself.
1) Why learn XYZ it won't help me get a job or won't be used on the job.
The fact of the matter is that the more you know about how computations CAN be described, the more you will know about what the right way to describe a *particular* computation is. This means when someone comes to you with 150 pages of code in straight C that implements a simple data format parser, or a preferences file reader, or a layout engine for a diagram editor or whatever, if you have seen 5 or 6 different styles of languages and techniques for programming, you will be able to decide how best to attack the problem that needs solving.
Often with the right point of view, a problem becomes an order of magnitude simpler. The beautiful thing about LISP is that it gives you the ability to take so many different points of view within a single language.
I still use flex/YACC, and M4, and sed, shell scripts, and will occasionally write some C/C++ (usually to link into lisp at a hotspot
This approach is basically the same approach a mathematician takes to proofs and problem solutions. Make the problem smaller, make it more like something we know how to solve...
Here's the other one I hear often:
2) We can't use XYZ there aren't enough people who know XYZ to support it. Go back to (or stick with) C/C++/Java/Perl!
This simply is a way to dodge having to rationally consider a different language or system. The fact of the matter is:
a) Just because you can hire someone who claims to know C/C++ or whatever, doesn't mean you can hire someone who can solve your problem! Programming involves a lot more than just knowing the syntax of a given langauge, and some of the features the library offers.
b) If by switching to something else you can make your problem several times easier, then the cost of training every good candidate vs. sticking to your old ways is essentially negative!
Most of the time, spending a few weeks of training your new candidate in how your system works will pay off big-time when it comes to debugging, quality assurance, adding new features, and even implementing the feature you initially hired them for. Why? Because understanding the PROBLEM and the solution method is much harder than understanding the language syntax, or even most language semantics.
I run my own business, it's just me. My ability to understand a problem, work with people to figure out good implementation strategies, and write code in LISP to rapidly create the products and services I want to provide are all advantages that I got by learning many languages, and especially LISP family languages.
thanks again Kent!
>Well, "so what" is that, if we're not already
>there, we are quickly approaching an era when a
>single person can get off a plane at Chicago
>O'Hare Airport, walk out onto the sidewalk,
>release some kind of gas/germ/nanobot, or
>detonate some device, and kill ALL THE AMERICANS
>ON THE GLOBE, if not all the human beings. And
>there will be no one left to enjoy the freedom.
We are not. And if we were, then no amount of searching people's bags and cars will help. if such a thing existed you'd never get remotely close enough to search for it.
Now take a deep breath and stop spreading irrational fear.
On the other hand, if you're the FBI, or DEA you'd love to have the power to search all kinds of things, and whoops he wasn't a terrorist, but look at these marijuana plants he's got in his garage... or Communist Party slogans (remember McCarthy?) or what have you....
The fallacy is that searching people randomly will help. It won't. It will definitely harm us.
I'm tired of the "I'm tired of whiners mentality."
Yes, security is important, but so are rights. And the two go hand in hand, they are NOT opposed.
I am more afraid of the National Guard at airports than terrorists. I am more afraid of the police and surveillance cameras than I am of anthrax. Why? Not because I'm a criminal, but because I don't have to be if the police have too much power! By the time they have their way with you, it's too late. Look at Rodney King, or the people whose assets have been siezed under anti-drug laws.
No, lets get some REAL security, and REAL freedom at the same time.
1) Stop illegally restricting the Second Amendment. The recent US vs. Emerson case completely affirmed that the second amendment gives citizens a right to keep and bear arms without needing the government's consent. In the majority of states non-felons can already carry firearms, but there is a complex morass of "permit" systems however. Change that to a national one time background check and issue a permit on demand for nominal (read $20 fee) good forever, until revoked by act of law (such as conviction of felony etc).
Lets stop creating "designated target" zones by disarming our citizens at schools, government buildings, airports, on the streets and in their homes... Armed citizens and pilots would have prevented all the 9/11 attacks, at NO cost to liberty or government coffers. Search technology is expensive and considerably (orders of magnitude) less effective, it is almost always used to hassle petty criminals (simply because only 1 in a billion or more searches actually find terrorists).
As for biological agents delivered remotely (ie. the mail). Bio agents can be neutralized by heat, light, and chemicals.
Worried about the mail? Run it through rollers at 170 C. Cost to taxpayers? Minimal. Have a special class of heat sensitive mail (photos, packages, flammables etc) that is subject to different handling.
No searches required.
How about aerosol chemicals, food poisoning, water systems blablabla?
The fundamental question to ask is: does the government have a truly valid reason to suspect you? If yes, they will have no problem getting warrants. If not, they shouldn't be able to search you.
A "reasonable expectation of privacy?"
The reasonability of privacy expectations in a public place is directly related to the unreasonability of allowing free access to that place.
Is it reasonable to allow free access to nuclear weapons? NO. Is it reasonable to allow search free access to a football stadium? YES. You think terrorists will be stupid enough to try to sneak through searches with bombs anyway? Why bother. They'll find some better means to blow you up if they know about the searches.
When it comes to searching employees of NIH, what do they expect to find? Those tiny microbes you've carefully hidden by wiping a billion of them on your left pinky? It'd take several days to grow cultures and detect them. Guns. Not a problem if citizens could have their rights back. Bombs? Don't kid yourself. Who would bother going through the search. Just park the car out front like at Oklahoma city.
Lets get real people, the fact that a few terrorists attacked "designated victims" (read forceably disarmed citizens on an airplane) took control of an airline and smashed it into a building is NOT reason to give free reign to the government to probe our lives. It IS reason to stop creating "designated victims"
Anthrax through the mail? Don't make me laugh. This is a minor procedural problem easily handled by sterilizing mail.
It's impossible to prevent someone from turning common household bleach and ammonia into a chemical warfare agent. Get used to it. Searches won't help us be safe. Quite the opposite.
First off, one of the best spokespersons for Lisp is Paul Graham, author of "On Lisp" and "ANSI Common Lisp". His web site is Here.
Reading through his articles will give you a better sense of what lisp is about. One that I'd like to see people comment on is: java's cover ... It resonates with my experience as well. Also This response
to his java's cover article succinctly makes a good point that covers
most of the bickering found here...
I personally think that the argument that Lisp is not widely known, and therefore not enough programmers exist to support corporate projects is bogus. The fact that you can hire someone who claims to know C++ does NOT in any way shape or form mean that you can hire someone who will solve your C++ programming problem! See my own web site for more on that.
I personally believe that if you have a large C++ program you're working on and need to hire a new person or a replacement who already claims to know C++, the start up cost for that person is the same as if you have a Lisp program doing the same thing, and need to hire someone AND train them to use Lisp. Why? the training more than pays for itself because it gives the new person a formal introduction to your project, and Lisp is a more productive system than C++ for most tasks. Furthermore, it's quite likely that the person who claims to know C++ doesn't know it as well as you would like, and therefore the fact that you haven't formally trained them on your project is a cost you aren't considering.
One of the points that the original article by the fellow at NASA makes is that Lisp turned out to have a very low standard deviation of run-time and development time. What this basically says is that the lisp programs were more consistent. This is a very good thing as anyone who has ever had deadlines knows.
Yes, the JVM version used in this study is old, but lets face it that would affect the average, but wouldn't affect the standard deviation much. Java programs are more likely to be slow, as are C++ programs!
The point about lisp being a memory hog that a few people have made here is invalid as well. The NASA article states:
Memory consumption for Lisp was significantly higher than for C/C++ and roughly comparable to Java. However, this result is somewhat misleading for two reasons. First, Lisp and Java both do internal memory management using garbage collection, so it is often the case that the Lisp and Java runtimes will allocate memory from the operating system this is not actually being used by the application program.
People here have interpreted this to mean that the system is a memory hog anyway. In fact many lisp systems reserve a large chunk of their address space, which makes it look like a large amount of memory is in use. However the operating system has really just reserved it, not allocated it. When you touch one of the pages it does get allocated. So it LOOKS like you're using a LOT of memory, but in fact because of the VM system, you are NOT using very much memory at all.
The biggest reasons people don't use Lisp are they either don't understand Lisp, or have been forced by clients or supervisors to use something else.