The clear reason for the current rate of population growth in the United States is immigration.
The yearly US population growth rate is 0.97%. By my calculation that's very close to 3 million people per year. The annual increase in the population due to immigration is about 900,000 per year. So while immigration is indeed a large part of population growth, I don't think the way you characterise it is correct. Even if all immigration were curtailed, the population would grow by over 2 million a year.
Hiding behind "you're doing it wrong; the software is right, change your habits" may work sometimes
It works for SAP. To our present horror and eternal damnation.
But that's what you are buying with SAP. You've got companies with a lot of adhoc processes. They think they need to tighten up their ship. SAP comes in and says, "Do things the SAP way. They software will make it easy!" So they ditch all their old processes (good and bad) and follow SAP, because SAP is the "one true way". If they aren't doing it the SAP way, they are doing it wrong -- by definition. Development tools are usually a bit different (although the exception that proves the rule is the number of people who suffered (and maybe are still suffering?) with Source Safe).
I find it weird that you've been modded down... I'm a CS graduate and in a lot of jobs I've been asked to take the title "Engineer". I have always refused. I am not an Engineer. Engineering is a different discipline than programming. One of the most important issues that a professional Engineer has to take on is public safety. I'm sure most people have seen the videos of the Takoma narrows bridge. A PE takes on responsibility for the safety of the people who use a bridge. They have techniques which allow them to predict the load capacity for a bridge, how it will work in its environment, etc, etc.
Here's the most important thing about programming that makes it different from Engineering. We have no such techniques. If I'm writing embedded software for medical devices, I have no way to show that the software won't malfunction and kill you. I can limit the probability of it happening. I can test it to show that it doesn't happen in several scenarios, but it is theoretically impossible to show that it won't happen at all. Personally, I don't even know of anyone using any techniques to show the probability of failure, or under what situations failure is likely to occur.
I have never, in 20 years as a programmer, see anyone act as an Engineer when working on a software project. I've worked on medical software and I've worked on telecommunications software. I've worked with people who have CS degrees. I have worked with people who have engineering degrees. I've even worked with people who are PEs. Nobody knows who to do even the most rudimentary elements of what would be called "Engineering" in another field.
It really is time we stop calling ourselves Engineers. Especially, those with engineering degrees should know better.
What public offence makes a person removable from the Unites States (apart from being illegally in the US or some other serious crime - which I would hope would compel the person to produce documentation regardless of this law).
This is precisely the point. Isn't illegal entry to the United States a public offence which makes them removable from the United States? How do you know if they had illegally entered the United States, except that they don't have the proper paperwork? Is a citizen of the United States required to carry papers proving that they are a citizen? If a person of Mexican origin who doesn't speak English (or speaks it with an accent) is involved in a minor offence, will the fact of their racial origins and their language ability be enough to suspect them of illegal entry to the US? Will a person who is white with perfect English ever be subject to the same suspicion?
The potential for this law is to create two classes of citizens: one who does not normally have to carry or surrender ID on demand (except in limited situations like driving), and another who must carry their ID around with them at all times *just in case*. I believe this is specifically something that Americans pride themselves on not having. It is better to put up with some problems than to create a society of inequality. Or at least this is the PR us Canadians hear all the time;-)
So you have agreed it's reasonable for police to ask for a driver's license for some kind of traffic violation (wrongdoing), right? Given that they don't have one, is it reasonable to ask why they don't have it?
Not all wrong-doings require a driver's license. What about jay-walking? What about being at the scene of a crime (you might be a suspect even if you aren't involved)? What about a domestic dispute? You're in a fight with your wife and it all gets a bit loud. The police come and, "Hey are you a citizen?". What about a group of teenagers who are drinking beer behind the bleachers when a policeman stumbles on them? Nobody has ID. Everybody gets away with a warning except that the hispanics must prove they are citizens.
I'm not aware of the details of the law, but your characterisation of it being no problem at all bears a fair amount of scrutiny. There is serious potential for abuse.
Anyway how is this any different than anyone else getting stopped by the police and being asked for identification such as a drivers license?
Because US citizens are not required to carry *any* identification. I haven't read the law in question, but I live in a country which seems to have a similar law (Japan). In Japan, if the police have occasion to ask me for my ID and I'm not carrying any, then as a non-citizen I can be sent to jail until it all gets sorted out. As a non-citizen, it doesn't bother me much. I have to carry around my "gaijin card" with me everywhere I go. It's part of the price of coming here.
But if I were a citizen it would bother me plenty. Racial Japanese people will *never* be asked for proof of citizenship under any circumstances. If they look Japanese and speak Japanese fluently, then they are Japanese. But I know people here who have white skin, but are Japanese citizens (some for their entire lives). If a policeman has occasion to ask for ID and they don't produce it, then what? Especially if they speak Japanese with an accent, they risk going to jail. Thus, just like a non-citizen they have to carry proof that they belong everywhere they go.
Again, I'm only going by what I read here in Slashdot, but it seems like this law is going to have similar problems. How does a police officer determine if a person is in the US illegally if they carry no ID? That in itself might be construed as evidence. If you couple it with certain racial characteristics and the inability to speak English, you might have a problem. Does this mean that hispanics must carry ID at all times, when white, Engish speaking people don't? This creates a disparity amongst race, even if the person isn't singled out solely on racial profiling.
I guess the easier way to look at it is, you might not be profiling specifically on race/language, but if you are allowed to say, "He's obviously American because he's white and speaks English perfectly", even when they guy doesn't carry ID, they you have a huge problem. I suspect that this is the case.
This is even worse than the usual bad patents I've seen. They have 20 pages of a very detailed description of their "preferred configuration". However, they say that it shouldn't be taken as a literal description of the system and that their patent is intended to be very broad. The claims are ridiculously broad and don't even reference the description of the system (apparently they were serious when they said that the description wasn't intended to be illustrative of their claims). The claims don't even make up half a page of text.
Look, I don't know much about patents, but surely there's no way such a bad patent can stand up in court... Can it?
He said nothing more than what every major intelligence agency around the world had been saying for over a decade - that Saddam Hussein had WMDs and was actively developing more. We didn't find any WMDs in Iraq but we did find evidence of active development of them.
The head of the UN weapons inspection team went on record before the war saying the they had found no evidence of WMDs. He pleaded for more time. When you say "every major intelligence agency", who are you talking about? This Times article says that people are claiming that MI6 told Tony Blair that there were no WMD.
I have been unable to find evidence for the active development of WMD. In fact, the Duefler report specifically states that no such evidence was found. There are reports from certain people that Saddam Hussein *wanted* to resume building WMD, but that is no the same as active development. It's possible you know something that I missed.
Everyone who has worked in a large company (or even some small companies) will recognise this argument. It's the beginning of every conversation discussion why our current product sucks and why we need to rewrite it. The only difference between open source software and projects behind closed doors is that we don't notice when closed rewrite projects fail (as they will almost invariably do). The problem with open source projects is that the graveyards are public.
Would you like to live in a world where society sets the standards and cooperates with one another to ensure that everyone follows that standard, or would you like to live in a world where the government sets the standards and they are enforced by the police in opposition of society? Because your statement makes me think that you *prefer* a police state. For me, ideally police aren't necessary. People are respectful of each other and peer pressure is enough to dissuade people from stepping over the line (even if they are excited about something). Where you see people ratting on their peers, I see people taking a stand on what they will accept in their society. If you don't want to help the police, maybe you need *more* community involvement, not less.
Bitcoin is an interesting idea, in that it tries to provide a finite supply of coins (once the initial period of production is over) which will mean it cannot be devalued by issuing more - that would make it an ideal currency for a government and/or a public which valued fiscal responsibility. Unfortunately no-one does.
A constant money supply is not desirable for a variety of reason. You actually want the supply to grow and shrink depending on the amount of production you can accomplish.
In a utopia, people would work for the sheer joy of it and labour would be divided up as needed. Production would be abundant and everyone would take what they needed and leave the rest for others. Unfortunately, we don't live in a utopia. Left to their own devices, people usually require some sort of guarantee that their needs will be met before they agree to work. This is where money comes in.
Without the guarantee that their needs will be met by someone else, people will often only work for themselves. Some people won't work at all, figuring that it is all hopeless. This means that potential production is halted. We *could* make more stuff, grow more food, etc, etc, but we have a labour shortage. People refuse to work. Or you might have people who are willing to work, but they don't have the tools that they need. A fisherman might not have boat for instance.
So we invent money and "guarantee" that people can spend the money on the things they need. This gets them working. Or it allows them to buy the things they need to be productive.
Ideally, we want have the exact amount of money that allows people to produce what is needed. If we make too much money, people will try to buy stuff but there won't be enough product to cover the money we made. The way we deal with that is by reducing the value of the money. If we make too little money, then we limit the amount of production. We could have made more stuff, but not everyone could be paid and so didn't work. Or they couldn't buy the equipment they needed to do their work. This is what money is for.
The amount we can produce at a given time changes based on how many people are available to work, what technology we can use, how many natural resources we have at our disposal, etc. If we set the amount of money at a constant, then we will not be able to adjust it based on how much production we want. We can compensate that by adjusting the value of the money, but the problem is that people might start hording the money. If the money supply is low, the value goes up. People with more money in their pocket have proportionally more power (they can lend money for instance). A feedback loop is created where people with the most money are the ones who receive the most money. Since it is a fixed resource, eventually only a few people control most of that resource. Contention for that resource drives the value up beyond reasonable limits and it ceases to be useful as a currency.
"Agile" is a virtually meaningless phrase: People over Processes, etc, etc. What *exactly* does that mean? I've worked on some extremely good "Agile" teams. All of them have had well documented processes and extremely disciplined practitioners.
The number of groups who prefer ad hoc development far and away outnumber the number of groups who prefer disciplined development. Ad hoc isn't even necessarily "bad". It's just "as you go". If you've got a team composed of great people, it can work. But, this is very, very rare.
Let's say you were a manager of a software group. You prefer ad hoc development. You may not even know that you prefer ad hoc development because you don't really know enough about software development processes to say anything on the topic at all. But you can't go to the people who are paying you the big bucks and say, "We just do whatever the fuck we want". You need something that has some credibility to call it. You read the agile manifesto and think, "Yes, I agree with all of that!". Voila! You're now "Agile".
The thing is, if I went into that team and said, "You aren't going to get to agile until you do X, Y, Z" they will literally laugh at me. They've done virtually no research. They've talked to nobody who has a proven track record using "Agile methods". But they have an ego the size of the Empire State Building. My way is best and if "Agile" isn't exactly what I'm doing, then "Agile" is broken, they will think.
Before Agile it was "Spiral" and "RAD" and about a million other things that had some benefit but were co-opted by the clueless idiots. Man, the number of times I saw teams who purported to follow the Rational process simply because they drew a UML diagram once makes my head spin. Like I said, "Agile" is meaningless. It was practically meaningless from the beginning, except that those who knew what they were doing had some common ideas. But it's definition was vague enough that everyone who wanted a process to follow without following a process jumped on it. But if it weren't for Agile, it would have been something else.
As a programmer your goal should be to find good teams to work on. Don't obsess about whether they call themselves one thing or the other. Good teams create good practices to follow. At interviews, do enough questioning to make sure that they have good practices and are actually following them. Unfortunately, you won't find very many groups who are. Your other option is to build those teams yourself. But that takes a whole new set of skills.
There is an important distinction between refactoring and rewriting. Refactoring is the task of changing small parts of the code so that it operates exactly the same way that it did before. Your outward facing interfaces aren't going to change much in each refactoring (although after successive refactorings it might change dramatically). Your unit tests should still run (possibly with some updating) after you have refactored the code.
Rewriting is the task of taking a large piece of code and rewriting it so that the acceptance tests pass. You will be rewriting the unit tests pretty much from scratch (if you even had any).
Refactoring should always be done after your unit tests are passing. You shouldn't refactor before your code does something useful. Get the tests to pass first, then refactor. Otherwise you're going to be spinning your wheels a lot.
Refactoring after you have done many many changes is very, very difficult. You are changing the structure of the code. But poor design choices often ripple through the code -- the design of one thing affects the design of another. Once you start refactoring it's like pulling a loose thread on a sweater -- the whole thing unravels on you (anyone who has tried to put legacy code under test and then refactor it has experienced this). You get to a point where you think that you might as well rewrite the whole thing.
But as you point out, rewriting is not usually a viable option. You get a new code base with the same user features. It usually costs about the same as the original did. It is often missing requirements (because how many projects have *all* their requirements documented in such a way as you can make sense of them in a rewrite?). You can't sell it to the customer because at best it is the same as before. So you've just doubled the cost of your development (and more). I've seen many rewrite projects in my years as a programmer. Very, very few of them are released to the public. Of those that are, very, very few of them are commercially successful.
I get the feeling that the original poster sees continual refactoring as wasteful. I can't see what the final shape should be so I am repeatedly changing it (practically every time I touch it). It would seem that it would make sense to wait until it is stable and then rewrite it. The reason for constant refactoring is reduced risk. I keep all of my refactorings as small as possible by doing them as soon as possible. The constant work is mitigated by the reduced scope of all the changes. Keeping the code base well factored also decreases the complexity of new changes. So while it feels like a lot of work up front, overall throughput is increased.
I will tell you how to break this rule. Most people order 30 chairs and sit on 2 of them. They have all sorts of reasons why they need those 30 chairs: People might come over, some might break, somebody might break in a steal some of them. But in the end, they really only use 2 of them. So we spent 15 times more than we needed in both time and cost. And in the bargain, because we couldn't afford 30 *good* chairs, we made crappy ones. The crappy ones break over time and we have the added cost of dealing with disposing of the broken chairs (which we probably never budgeted for).
The false assumption in the Cheap, Fast, Good analogy is that they are opposed to each other. But the reality is that if you just do less, it is both cheaper and faster. This leaves you more time to work on being better. Even though the start up cost of better goods are higher, they often end up being cheaper in the long run due to less time spent fixing or replacing them.
Personally, I hate the word "Agile" because it has such a broad definition (bordering on no definition) that it can mean anything. But when I talk about "Agile", I mean something very specific. I ask stakeholders to give me only a minimum of requirements, but I invite them (maybe I should rephrase that as "make them") change their requirements over time. In fact my stakeholders often complain at the beginning that I allow *less* than the minimum requirements. But I assure them that they can add to the list later if they feel like it (which they won't). My goal is to abandon work that we realise we don't need as we discover more about the system.
In addition to simply doing less, I optimise for high throughput rather than interactivity in the process. This may sound like the opposite of "Agile", but it isn't. In a lot of shops you get requests like, "We need a build today to do a demo", or "QA found this bug and it takes priority over everything". I make a stable build every week or 2 weeks (depending on my iteration length). That is the only build available for demos -- ever. Hey, it comes out every week, if you need to demo a feature, you should be able to plan that far ahead. Bugs are treated exactly like features. Every week we evaluate the incoming work and prioritise it. Then we do it. If bugs are higher priority than features then that's what we do. But once we start and until we end, nobody is interrupted. Again, if you can't plan 1 or 2 weeks in advance, then you've got bigger problems than software issues.
Finally, we shoot for 100% test coverage. We've got continuous integration. We refactor code (including large architectural changes) whenever we think the design can be improved. These things take a fairly hefty start up cost, but overall throughput remains constant instead of dropping off over time. Actually, well written software should enable you to improve your speed marginally as the size goes up (you have more capabilities and don't have to write everything from scratch). The only reason it usually doesn't is because we don't spend the time to keep everything well factored and organised.
Coding issues aside, real productivity gains come from keeping the team small and allowing a very long time for requirements discovery (essentially the entire development time). Allowing people who are discovering requirements to *use* the software as it is being developed improves productivity even more. It gives people the opportunity to find out *exactly* what they need rather than what they think they will need. We go faster by *not* coding.
Yes, but which is it: "just gotta fix this and that" broken, or "this thing is a complete mess" broken?
I have been using it for the past month. It is definitely broken. Technically, it's not a complete mess. It *could* be fixed. The question is if they want to fix it. Here are my problems with it:
The absolute biggest problem is that focus follows mouse and sloppy focus are not supported. The biggest issue is that the menu is at the top, so when you move the mouse to get to the menu and cross over another window, you change to the menu in the other application. There are a few other minor issues as well. Many bugs have been logged and the upshot of it is that Canonical doesn't mind if someone fixes the problem, but they don't feel like doing it. It's their code, so they can do whatever they want, but IMHO Unity is fundamentally broken without focus follows mouse support.
There are also a fair number of bugs. Sometimes clicking on the items in the system tray doesn't work. Usually the one in the far right corner will work and after you get the menu dropping down from it, the others will start working again. Sometimes you have to kill your session from the console and re-log in. Similarly, remapping a window after you have iconified it sometimes doesn't work. If you switch to another desktop and try again, it will remap again. Finally, the menu and "Run Command" will sometimes just stop working. The only remedy seems to be restarting Compiz. These are serious show-stopper bugs IMHO. Unity is not ready until these things are fixed. But I suspect they will be fixed before too long.
There are a few more problems which I think should be fixed, but won't affect most people. Unity has been coded with assumptions that certain other Compiz plugins are in use. This means that other plugins that perform the same function can't be used in their place. For instance, it is not possible to use Cube Rotation with Unity. I would call this fundamentally broken, but it's arguably a low priority.
Unity should *not* have been released as the default desktop in its current state. It is usable if you are aware of its problems and know how to work around them. But that's not the point of Unity, is it? I think if they hadn't tried to force this down everyone's throats, they could have gotten a fair amount of buy-in from people who want to set up a Mac-like experience on their box. If they gave up a bit of control on determining what is important and what isn't and worked with other people, I think it could have be extremely good. It still has potential, but I'm not sure it will ever live up to that potential. We'll see.
I have one other issue with this version of Ubuntu. Compiz has slowed down dramatically. I usually use a lowly netbook with built in Intel graphics. KDE4 is too slow to run on my box, but Compiz has always been snappy. This version is just on the edge of usability. I don't know if this performance problem is related to Unity, but I suspect not (it's the same even if I disable Unity). On the plus side, Network Manager finally works properly (which is a minor miracle).
I've observed that at some point most developers go from "must always use the latest and greatest" mindset out of college to "if it ain't broke don't fix it" mindset that comes with a few gray hairs.
Yeah. You get to a point where you realise that eating different food doesn't necessarily result in making your shit any more appealing. One thing about using the bleeding edge is that it pretty much guarantees that you don't know how to use it properly. You don't have any experience to tell you what is appropriate and what isn't. You don't even have a lot of examples to show you how to avoid issues and how to write code the way everyone else does (because everyone else *doesn't* yet). The industry is littered with new projects that suck just as hard as the things they were supposed to replace.
If nerds had that much sway, the majority of people would be running Linux on the desktop, with all popular and important commercial apps and games available for it.
No offense, but Linux nerds don't want the popular commercial apps and games. They want the Gimp and nethack. Although free software desktops are increasingly being used by people who don't give two shits about free software, it has historically been designed for and by people who do. And those of us who give a shit about free software are by and large happy with what we've got (although we can make it better).
Not that I disagree with you on the main point. Nerds didn't make Apple successful. If it had, Apple would have been successful before Steve Jobs came back. Apple was successful because Steve Jobs was right all the way from the beginning. The average person doesn't want a computer (in the hobbyist sense). They don't want to tinker with it. They don't want to extend it. They don't want to invent new ways to solve problems that nobody has thought of before. They want an appliance that solves specific problems in specific ways. And they want it to be cool. And they want it to be pretty.
However as much as everyone jokes about the "Year of the Linux Desktop". There is one thing that Apple gets wrong consistently. There is virtually nothing about free software that the average person wouldn't trade for extra eye candy, except one thing. People want to share. If they learn of a way to do something, they want to share it with their friends immediately. They want to copy. If they have something new and shiny, they want to give it to their buddies right away. Apple doesn't know how to monetise this and it is possible that somebody who does will come and eat their lunch. We'll see.
But why should either of them have protection? Rudyard Kipling is long dead. It's unlikely either of his daughters are still alive as they would be over 115 years old. A copyright "protecting" this work would not be owned by anyone even remotely connected with its creation. It would simply be a money making instrument for anyone lucky enough to be in possession of it. Why should a person or organisation who had nothing to do with the creation of a work collect money for doing absolutely nothing?
The argument about things like Tai Chi Turtle is that someday, for some unknown reason it will come into popularity. For example, the song Soul Bossa Nova became popular beyond its probable merit when it became the theme song for the Austin Powers movie. The widow of the writer Quincy Jones received the royalties. Which is nice, but I personally I don't see why we should bend over backwards for these kinds of rare scenarios. Tai Chi Turtle (I'm suspecting this is not a real game;-) ) had its run and its authors were compensated reasonably. Soul Bossa Nova was written for another movie and the writer was compensated.
Why should we continue to offer a monopoly to something well beyond any reasonable expectation of profit? This is especially true when we deny people access to artistic works in the process. Let's give a monopoly for a period that covers a reasonable period and possibility of return, and that directly supports the author (without consideration to any entity who is not connected with the construction of the work).
Like a lot of other things with Facebook, Google and the like people are getting worried at the wrong thing. If you are a normal person on Facebook, there are hundreds of photos of you. Your friends are happily tagging them with your name. So now Facebook has this huge database of faces and names. And we can see that they can implement automatic facial recognition. But people are upset that the information is being shared with their friends without notice.
That really shouldn't be the issue. The issue is that Facebook now has a database of your pictures and can match new pictures and get your name if they want to (or are forced to by the state). Having an opt-in for sharing the information with your friends is not as big a problem as the fact that users have already opted in by giving Facebook this information in the first place.
But of course the average person can't see beyond the end of their nose. "What would they do with that information anyway? It's useless" they say. And yet they hit the roof when Facebook actually uses it in the most trivial of ways.
The same goes for people who use their gmail (or yahoo or whatever) accounts and mail bank details, personal addresses, telephone numbers, credit card numbers, etc, etc, etc. People need to stop opting in to this stuff if they are going to complain later that it's getting used.
The summery says: "Created the videos in his own time, off-campus."
The video says: "This was done up back in November of 2010, for an economics course project."
So I don't think its as independent from school as this summary wants to make you believe.
That doesn't mean the school owns them however, so they have no right to threaten him with calling the police over the videos if he didn't take them down, which the same article tells you they did
It's not just the summary that's inconsistent, but the article as well. What this points to for me is that the article is garbage with respect to actually getting facts on the issue. Nothing about this makes any sense. I watched the video linked in TFA. Personally, I don't see why a school would demand that it get taken down. I didn't see any mention of the school (but it's possible I missed it). But, some schools are staffed by jerks. It's possible they went overboard.
The really weird thing is that the police are involved. And the student is suspended while the police continue the investigation. What on earth would the police be investigating? The *only* thing I could possibly imagine is hate crimes. Again, there was absolutely nothing of the sort in the linked video. There appears to be copyright infringement, but that's not something that the police would get involved in.
There is something seriously fishy about this article. Unless there is some clarification of the facts, I'm going to conclude that the reporter just has it wrong (conveniently so given the number of hits they are likely to get...)
Telling the computer what to do is only half of what I am doing (and the easy half at that). Telling other programmers what is going on is the other half. If we were only interested in whether the computer understood what I was saying then "good code" would equate to "does it run". Nothing else would matter. But future productivity is dependent upon the ability of programmers to understand and modify the code without breaking it. I've worked on systems where the code was so bad that the average programmer managed to write only 500 lines of code a *year* (and even then they were breaking things right, left and center). The company needed 5000 programmers to meet its goals. Needless to say that this company is no longer around.
To me the mark of a good programmer is that the code that they write is virtually always easy to understand. You look at it and can see pretty quickly what it does, that it does it correctly, and how you could modify it if you wanted to. I'm not against comments, but if you need to rely on comments to explain your code it might be a sign that things are not as simple as they could be. It might also be that the problem is complex, but in my experience the vast majority of code is performing mundane tasks. The complexity is coming from having to work around problems with the current design/implementation.
Don't get me wrong! There is more to writing code than the ability to program fluently! I've waded through enough ad hoc parsers and file formats that were based on context free grammars to know that. Algorithmic complexity, automata and grammars, normal forms and a few other things are really important. I used to work for a company that had a hard on for mechanical engineers. Smart guys, but never once took a CS course in their life. It took them a while for them to learn what they needed.
But seriously, how much of your code requires that knowledge? How much of your code needs to be well written, comprehensible and simple to read from another programmer's perspective? CS teaches theory and I have absolutely no problem with that. But good theorists don't necessarily make good programmers. We don't teach programming well. A lot of schools don't even teach theory well, but that's a different rant.
Do we need both? In my opinion, yes.
With respect to the monitor hypothesis: Yes, you are correct. Is monitoring important in a professional writer? IMHO, yes. Should you worry about monitoring before you are fluent? IMHO, possibly no. Again, this comes from Krashen's hypotheses of language acquisition, but since fluent output is the result of the acquisition side, you can't create fluent output before you have acquired it. You have nothing to monitor.
Having said that, in my own English classes, I include grammar and vocabulary specifically for monitoring even before fluency has been acquired. While it may not be necessary, and may even increase the amount of time necessary to acquire the language, it has a major benefit: It decreases the dependency on a teacher. I'm only available for a small amount of time. The rest of the time the students need to find comprehensible input by themselves. This often comes from reading. Since there isn't a dialog, they need a way to find meaning in the input. This can come from rules. However, without the input, the rules are next to useless. If I were to teach programming, I would probably approach it the same way.
Finally with respect to immersion. Relying on the input hypothesis is different from immersion. I actually taught myself Japanese in an immersed environment as an adult, so I have some experience with this. I never took a class. The problem with immersion is that it is not *comprehensible* input. It's a hell of a lot of incomprehensible input, with a tiny bit of comprehensible input now and again. With all due respect to Chomsky, my personal opinion is that even babies wouldn't do well in an adult immersion experience. A baby has a set of parents who are spending their time turning things into comprehensible input. Adults are rarely treated like babies and even complain if they are lucky enough to receive such treatment. People spout some insanely complicated thing to you and if you ask for clarification they just say it again louder. There are other problems with adults as well, but it's kind of off topic.
I should have been more clear when I said that we should immerse people in good code. What I meant was that we should immerse them in comprehensible good code. I don't suggest forgoing formal education. I'm suggesting that a good teacher of programming would be either finding or generating large amounts good code and creating comprehensible input from it. Students would spend a very large amount of their time reading good code that they understand. Their fluency would be frequently checked to see what they had acquired.
It does seem very similar, doesn't it? Thanks for the link. The "input Hypothesis" is a little different in that it discusses only language acquisition and doesn't propose a model for how that acquisition happens. It makes a distinction between "learning" and "acquiring", where someone can "learn" something but not be able to use it fluently. "Acquisition" means being able to use it fluently.
The "input Theory" merely states that no matter what techniques you use to teach language, acquisition only happens as a result of input that the student understands. Output for example, while it may be helpful, is not necessary. Also, input that the student doesn't understand (i.e., listening to or repeating dialogs which aren't understood) does not aid in acquisition. Similarly, memorising facts about language (such as grammar or translations) does not aid in acquisition, unless that activity results in generating comprehensible input (which it often does).
This input theory is hotly debated amongst language acquisition theorists. I think most people generally accept it, but many people have a real problem with the "only" part of it.
Having said all that, constructivism would probably fit as a mechanism for the input theory, though I'm sure other mechanism would also be viable.
Some good stuff there. Some crap. Overall I give myself a C+. As you are an anonymous coward, I don't suppose you'll ever see this. I'm not even sure why I'm responding to such a ridiculous comment. But I've always been happy to have people read and critique my code. Feel free.
Slashdot Mirror
The clear reason for the current rate of population growth in the United States is immigration.
The yearly US population growth rate is 0.97%. By my calculation that's very close to 3 million people per year. The annual increase in the population due to immigration is about 900,000 per year. So while immigration is indeed a large part of population growth, I don't think the way you characterise it is correct. Even if all immigration were curtailed, the population would grow by over 2 million a year.
Hiding behind "you're doing it wrong; the software is right, change your habits" may work sometimes
It works for SAP. To our present horror and eternal damnation.
But that's what you are buying with SAP. You've got companies with a lot of adhoc processes. They think they need to tighten up their ship. SAP comes in and says, "Do things the SAP way. They software will make it easy!" So they ditch all their old processes (good and bad) and follow SAP, because SAP is the "one true way". If they aren't doing it the SAP way, they are doing it wrong -- by definition. Development tools are usually a bit different (although the exception that proves the rule is the number of people who suffered (and maybe are still suffering?) with Source Safe).
I find it weird that you've been modded down... I'm a CS graduate and in a lot of jobs I've been asked to take the title "Engineer". I have always refused. I am not an Engineer. Engineering is a different discipline than programming. One of the most important issues that a professional Engineer has to take on is public safety. I'm sure most people have seen the videos of the Takoma narrows bridge. A PE takes on responsibility for the safety of the people who use a bridge. They have techniques which allow them to predict the load capacity for a bridge, how it will work in its environment, etc, etc.
Here's the most important thing about programming that makes it different from Engineering. We have no such techniques. If I'm writing embedded software for medical devices, I have no way to show that the software won't malfunction and kill you. I can limit the probability of it happening. I can test it to show that it doesn't happen in several scenarios, but it is theoretically impossible to show that it won't happen at all. Personally, I don't even know of anyone using any techniques to show the probability of failure, or under what situations failure is likely to occur.
I have never, in 20 years as a programmer, see anyone act as an Engineer when working on a software project. I've worked on medical software and I've worked on telecommunications software. I've worked with people who have CS degrees. I have worked with people who have engineering degrees. I've even worked with people who are PEs. Nobody knows who to do even the most rudimentary elements of what would be called "Engineering" in another field.
It really is time we stop calling ourselves Engineers. Especially, those with engineering degrees should know better.
What public offence makes a person removable from the Unites States (apart from being illegally in the US or some other serious crime - which I would hope would compel the person to produce documentation regardless of this law).
This is precisely the point. Isn't illegal entry to the United States a public offence which makes them removable from the United States? How do you know if they had illegally entered the United States, except that they don't have the proper paperwork? Is a citizen of the United States required to carry papers proving that they are a citizen? If a person of Mexican origin who doesn't speak English (or speaks it with an accent) is involved in a minor offence, will the fact of their racial origins and their language ability be enough to suspect them of illegal entry to the US? Will a person who is white with perfect English ever be subject to the same suspicion?
The potential for this law is to create two classes of citizens: one who does not normally have to carry or surrender ID on demand (except in limited situations like driving), and another who must carry their ID around with them at all times *just in case*. I believe this is specifically something that Americans pride themselves on not having. It is better to put up with some problems than to create a society of inequality. Or at least this is the PR us Canadians hear all the time ;-)
So you have agreed it's reasonable for police to ask for a driver's license for some kind of traffic violation (wrongdoing), right? Given that they don't have one, is it reasonable to ask why they don't have it?
Not all wrong-doings require a driver's license. What about jay-walking? What about being at the scene of a crime (you might be a suspect even if you aren't involved)? What about a domestic dispute? You're in a fight with your wife and it all gets a bit loud. The police come and, "Hey are you a citizen?". What about a group of teenagers who are drinking beer behind the bleachers when a policeman stumbles on them? Nobody has ID. Everybody gets away with a warning except that the hispanics must prove they are citizens.
I'm not aware of the details of the law, but your characterisation of it being no problem at all bears a fair amount of scrutiny. There is serious potential for abuse.
Anyway how is this any different than anyone else getting stopped by the police and being asked for identification such as a drivers license?
Because US citizens are not required to carry *any* identification. I haven't read the law in question, but I live in a country which seems to have a similar law (Japan). In Japan, if the police have occasion to ask me for my ID and I'm not carrying any, then as a non-citizen I can be sent to jail until it all gets sorted out. As a non-citizen, it doesn't bother me much. I have to carry around my "gaijin card" with me everywhere I go. It's part of the price of coming here.
But if I were a citizen it would bother me plenty. Racial Japanese people will *never* be asked for proof of citizenship under any circumstances. If they look Japanese and speak Japanese fluently, then they are Japanese. But I know people here who have white skin, but are Japanese citizens (some for their entire lives). If a policeman has occasion to ask for ID and they don't produce it, then what? Especially if they speak Japanese with an accent, they risk going to jail. Thus, just like a non-citizen they have to carry proof that they belong everywhere they go.
Again, I'm only going by what I read here in Slashdot, but it seems like this law is going to have similar problems. How does a police officer determine if a person is in the US illegally if they carry no ID? That in itself might be construed as evidence. If you couple it with certain racial characteristics and the inability to speak English, you might have a problem. Does this mean that hispanics must carry ID at all times, when white, Engish speaking people don't? This creates a disparity amongst race, even if the person isn't singled out solely on racial profiling.
I guess the easier way to look at it is, you might not be profiling specifically on race/language, but if you are allowed to say, "He's obviously American because he's white and speaks English perfectly", even when they guy doesn't carry ID, they you have a huge problem. I suspect that this is the case.
This is even worse than the usual bad patents I've seen. They have 20 pages of a very detailed description of their "preferred configuration". However, they say that it shouldn't be taken as a literal description of the system and that their patent is intended to be very broad. The claims are ridiculously broad and don't even reference the description of the system (apparently they were serious when they said that the description wasn't intended to be illustrative of their claims). The claims don't even make up half a page of text.
Look, I don't know much about patents, but surely there's no way such a bad patent can stand up in court... Can it?
He said nothing more than what every major intelligence agency around the world had been saying for over a decade - that Saddam Hussein had WMDs and was actively developing more. We didn't find any WMDs in Iraq but we did find evidence of active development of them.
The head of the UN weapons inspection team went on record before the war saying the they had found no evidence of WMDs. He pleaded for more time. When you say "every major intelligence agency", who are you talking about? This Times article says that people are claiming that MI6 told Tony Blair that there were no WMD.
I have been unable to find evidence for the active development of WMD. In fact, the Duefler report specifically states that no such evidence was found. There are reports from certain people that Saddam Hussein *wanted* to resume building WMD, but that is no the same as active development. It's possible you know something that I missed.
Everyone who has worked in a large company (or even some small companies) will recognise this argument. It's the beginning of every conversation discussion why our current product sucks and why we need to rewrite it. The only difference between open source software and projects behind closed doors is that we don't notice when closed rewrite projects fail (as they will almost invariably do). The problem with open source projects is that the graveyards are public.
Would you like to live in a world where society sets the standards and cooperates with one another to ensure that everyone follows that standard, or would you like to live in a world where the government sets the standards and they are enforced by the police in opposition of society? Because your statement makes me think that you *prefer* a police state. For me, ideally police aren't necessary. People are respectful of each other and peer pressure is enough to dissuade people from stepping over the line (even if they are excited about something). Where you see people ratting on their peers, I see people taking a stand on what they will accept in their society. If you don't want to help the police, maybe you need *more* community involvement, not less.
Bitcoin is an interesting idea, in that it tries to provide a finite supply of coins (once the initial period of production is over) which will mean it cannot be devalued by issuing more - that would make it an ideal currency for a government and/or a public which valued fiscal responsibility. Unfortunately no-one does.
A constant money supply is not desirable for a variety of reason. You actually want the supply to grow and shrink depending on the amount of production you can accomplish.
In a utopia, people would work for the sheer joy of it and labour would be divided up as needed. Production would be abundant and everyone would take what they needed and leave the rest for others. Unfortunately, we don't live in a utopia. Left to their own devices, people usually require some sort of guarantee that their needs will be met before they agree to work. This is where money comes in.
Without the guarantee that their needs will be met by someone else, people will often only work for themselves. Some people won't work at all, figuring that it is all hopeless. This means that potential production is halted. We *could* make more stuff, grow more food, etc, etc, but we have a labour shortage. People refuse to work. Or you might have people who are willing to work, but they don't have the tools that they need. A fisherman might not have boat for instance.
So we invent money and "guarantee" that people can spend the money on the things they need. This gets them working. Or it allows them to buy the things they need to be productive.
Ideally, we want have the exact amount of money that allows people to produce what is needed. If we make too much money, people will try to buy stuff but there won't be enough product to cover the money we made. The way we deal with that is by reducing the value of the money. If we make too little money, then we limit the amount of production. We could have made more stuff, but not everyone could be paid and so didn't work. Or they couldn't buy the equipment they needed to do their work. This is what money is for.
The amount we can produce at a given time changes based on how many people are available to work, what technology we can use, how many natural resources we have at our disposal, etc. If we set the amount of money at a constant, then we will not be able to adjust it based on how much production we want. We can compensate that by adjusting the value of the money, but the problem is that people might start hording the money. If the money supply is low, the value goes up. People with more money in their pocket have proportionally more power (they can lend money for instance). A feedback loop is created where people with the most money are the ones who receive the most money. Since it is a fixed resource, eventually only a few people control most of that resource. Contention for that resource drives the value up beyond reasonable limits and it ceases to be useful as a currency.
"Agile" is a virtually meaningless phrase: People over Processes, etc, etc. What *exactly* does that mean? I've worked on some extremely good "Agile" teams. All of them have had well documented processes and extremely disciplined practitioners.
The number of groups who prefer ad hoc development far and away outnumber the number of groups who prefer disciplined development. Ad hoc isn't even necessarily "bad". It's just "as you go". If you've got a team composed of great people, it can work. But, this is very, very rare.
Let's say you were a manager of a software group. You prefer ad hoc development. You may not even know that you prefer ad hoc development because you don't really know enough about software development processes to say anything on the topic at all. But you can't go to the people who are paying you the big bucks and say, "We just do whatever the fuck we want". You need something that has some credibility to call it. You read the agile manifesto and think, "Yes, I agree with all of that!". Voila! You're now "Agile".
The thing is, if I went into that team and said, "You aren't going to get to agile until you do X, Y, Z" they will literally laugh at me. They've done virtually no research. They've talked to nobody who has a proven track record using "Agile methods". But they have an ego the size of the Empire State Building. My way is best and if "Agile" isn't exactly what I'm doing, then "Agile" is broken, they will think.
Before Agile it was "Spiral" and "RAD" and about a million other things that had some benefit but were co-opted by the clueless idiots. Man, the number of times I saw teams who purported to follow the Rational process simply because they drew a UML diagram once makes my head spin. Like I said, "Agile" is meaningless. It was practically meaningless from the beginning, except that those who knew what they were doing had some common ideas. But it's definition was vague enough that everyone who wanted a process to follow without following a process jumped on it. But if it weren't for Agile, it would have been something else.
As a programmer your goal should be to find good teams to work on. Don't obsess about whether they call themselves one thing or the other. Good teams create good practices to follow. At interviews, do enough questioning to make sure that they have good practices and are actually following them. Unfortunately, you won't find very many groups who are. Your other option is to build those teams yourself. But that takes a whole new set of skills.
There is an important distinction between refactoring and rewriting. Refactoring is the task of changing small parts of the code so that it operates exactly the same way that it did before. Your outward facing interfaces aren't going to change much in each refactoring (although after successive refactorings it might change dramatically). Your unit tests should still run (possibly with some updating) after you have refactored the code.
Rewriting is the task of taking a large piece of code and rewriting it so that the acceptance tests pass. You will be rewriting the unit tests pretty much from scratch (if you even had any).
Refactoring should always be done after your unit tests are passing. You shouldn't refactor before your code does something useful. Get the tests to pass first, then refactor. Otherwise you're going to be spinning your wheels a lot.
Refactoring after you have done many many changes is very, very difficult. You are changing the structure of the code. But poor design choices often ripple through the code -- the design of one thing affects the design of another. Once you start refactoring it's like pulling a loose thread on a sweater -- the whole thing unravels on you (anyone who has tried to put legacy code under test and then refactor it has experienced this). You get to a point where you think that you might as well rewrite the whole thing.
But as you point out, rewriting is not usually a viable option. You get a new code base with the same user features. It usually costs about the same as the original did. It is often missing requirements (because how many projects have *all* their requirements documented in such a way as you can make sense of them in a rewrite?). You can't sell it to the customer because at best it is the same as before. So you've just doubled the cost of your development (and more). I've seen many rewrite projects in my years as a programmer. Very, very few of them are released to the public. Of those that are, very, very few of them are commercially successful.
I get the feeling that the original poster sees continual refactoring as wasteful. I can't see what the final shape should be so I am repeatedly changing it (practically every time I touch it). It would seem that it would make sense to wait until it is stable and then rewrite it. The reason for constant refactoring is reduced risk. I keep all of my refactorings as small as possible by doing them as soon as possible. The constant work is mitigated by the reduced scope of all the changes. Keeping the code base well factored also decreases the complexity of new changes. So while it feels like a lot of work up front, overall throughput is increased.
I will tell you how to break this rule. Most people order 30 chairs and sit on 2 of them. They have all sorts of reasons why they need those 30 chairs: People might come over, some might break, somebody might break in a steal some of them. But in the end, they really only use 2 of them. So we spent 15 times more than we needed in both time and cost. And in the bargain, because we couldn't afford 30 *good* chairs, we made crappy ones. The crappy ones break over time and we have the added cost of dealing with disposing of the broken chairs (which we probably never budgeted for).
The false assumption in the Cheap, Fast, Good analogy is that they are opposed to each other. But the reality is that if you just do less, it is both cheaper and faster. This leaves you more time to work on being better. Even though the start up cost of better goods are higher, they often end up being cheaper in the long run due to less time spent fixing or replacing them.
Personally, I hate the word "Agile" because it has such a broad definition (bordering on no definition) that it can mean anything. But when I talk about "Agile", I mean something very specific. I ask stakeholders to give me only a minimum of requirements, but I invite them (maybe I should rephrase that as "make them") change their requirements over time. In fact my stakeholders often complain at the beginning that I allow *less* than the minimum requirements. But I assure them that they can add to the list later if they feel like it (which they won't). My goal is to abandon work that we realise we don't need as we discover more about the system.
In addition to simply doing less, I optimise for high throughput rather than interactivity in the process. This may sound like the opposite of "Agile", but it isn't. In a lot of shops you get requests like, "We need a build today to do a demo", or "QA found this bug and it takes priority over everything". I make a stable build every week or 2 weeks (depending on my iteration length). That is the only build available for demos -- ever. Hey, it comes out every week, if you need to demo a feature, you should be able to plan that far ahead. Bugs are treated exactly like features. Every week we evaluate the incoming work and prioritise it. Then we do it. If bugs are higher priority than features then that's what we do. But once we start and until we end, nobody is interrupted. Again, if you can't plan 1 or 2 weeks in advance, then you've got bigger problems than software issues.
Finally, we shoot for 100% test coverage. We've got continuous integration. We refactor code (including large architectural changes) whenever we think the design can be improved. These things take a fairly hefty start up cost, but overall throughput remains constant instead of dropping off over time. Actually, well written software should enable you to improve your speed marginally as the size goes up (you have more capabilities and don't have to write everything from scratch). The only reason it usually doesn't is because we don't spend the time to keep everything well factored and organised.
Coding issues aside, real productivity gains come from keeping the team small and allowing a very long time for requirements discovery (essentially the entire development time). Allowing people who are discovering requirements to *use* the software as it is being developed improves productivity even more. It gives people the opportunity to find out *exactly* what they need rather than what they think they will need. We go faster by *not* coding.
Yes, but which is it: "just gotta fix this and that" broken, or "this thing is a complete mess" broken?
I have been using it for the past month. It is definitely broken. Technically, it's not a complete mess. It *could* be fixed. The question is if they want to fix it. Here are my problems with it:
The absolute biggest problem is that focus follows mouse and sloppy focus are not supported. The biggest issue is that the menu is at the top, so when you move the mouse to get to the menu and cross over another window, you change to the menu in the other application. There are a few other minor issues as well. Many bugs have been logged and the upshot of it is that Canonical doesn't mind if someone fixes the problem, but they don't feel like doing it. It's their code, so they can do whatever they want, but IMHO Unity is fundamentally broken without focus follows mouse support.
There are also a fair number of bugs. Sometimes clicking on the items in the system tray doesn't work. Usually the one in the far right corner will work and after you get the menu dropping down from it, the others will start working again. Sometimes you have to kill your session from the console and re-log in. Similarly, remapping a window after you have iconified it sometimes doesn't work. If you switch to another desktop and try again, it will remap again. Finally, the menu and "Run Command" will sometimes just stop working. The only remedy seems to be restarting Compiz. These are serious show-stopper bugs IMHO. Unity is not ready until these things are fixed. But I suspect they will be fixed before too long.
There are a few more problems which I think should be fixed, but won't affect most people. Unity has been coded with assumptions that certain other Compiz plugins are in use. This means that other plugins that perform the same function can't be used in their place. For instance, it is not possible to use Cube Rotation with Unity. I would call this fundamentally broken, but it's arguably a low priority.
Unity should *not* have been released as the default desktop in its current state. It is usable if you are aware of its problems and know how to work around them. But that's not the point of Unity, is it? I think if they hadn't tried to force this down everyone's throats, they could have gotten a fair amount of buy-in from people who want to set up a Mac-like experience on their box. If they gave up a bit of control on determining what is important and what isn't and worked with other people, I think it could have be extremely good. It still has potential, but I'm not sure it will ever live up to that potential. We'll see.
I have one other issue with this version of Ubuntu. Compiz has slowed down dramatically. I usually use a lowly netbook with built in Intel graphics. KDE4 is too slow to run on my box, but Compiz has always been snappy. This version is just on the edge of usability. I don't know if this performance problem is related to Unity, but I suspect not (it's the same even if I disable Unity). On the plus side, Network Manager finally works properly (which is a minor miracle).
I've observed that at some point most developers go from "must always use the latest and greatest" mindset out of college to "if it ain't broke don't fix it" mindset that comes with a few gray hairs.
Yeah. You get to a point where you realise that eating different food doesn't necessarily result in making your shit any more appealing. One thing about using the bleeding edge is that it pretty much guarantees that you don't know how to use it properly. You don't have any experience to tell you what is appropriate and what isn't. You don't even have a lot of examples to show you how to avoid issues and how to write code the way everyone else does (because everyone else *doesn't* yet). The industry is littered with new projects that suck just as hard as the things they were supposed to replace.
If nerds had that much sway, the majority of people would be running Linux on the desktop, with all popular and important commercial apps and games available for it.
No offense, but Linux nerds don't want the popular commercial apps and games. They want the Gimp and nethack. Although free software desktops are increasingly being used by people who don't give two shits about free software, it has historically been designed for and by people who do. And those of us who give a shit about free software are by and large happy with what we've got (although we can make it better).
Not that I disagree with you on the main point. Nerds didn't make Apple successful. If it had, Apple would have been successful before Steve Jobs came back. Apple was successful because Steve Jobs was right all the way from the beginning. The average person doesn't want a computer (in the hobbyist sense). They don't want to tinker with it. They don't want to extend it. They don't want to invent new ways to solve problems that nobody has thought of before. They want an appliance that solves specific problems in specific ways. And they want it to be cool. And they want it to be pretty.
However as much as everyone jokes about the "Year of the Linux Desktop". There is one thing that Apple gets wrong consistently. There is virtually nothing about free software that the average person wouldn't trade for extra eye candy, except one thing. People want to share. If they learn of a way to do something, they want to share it with their friends immediately. They want to copy. If they have something new and shiny, they want to give it to their buddies right away. Apple doesn't know how to monetise this and it is possible that somebody who does will come and eat their lunch. We'll see.
But why should either of them have protection? Rudyard Kipling is long dead. It's unlikely either of his daughters are still alive as they would be over 115 years old. A copyright "protecting" this work would not be owned by anyone even remotely connected with its creation. It would simply be a money making instrument for anyone lucky enough to be in possession of it. Why should a person or organisation who had nothing to do with the creation of a work collect money for doing absolutely nothing?
The argument about things like Tai Chi Turtle is that someday, for some unknown reason it will come into popularity. For example, the song Soul Bossa Nova became popular beyond its probable merit when it became the theme song for the Austin Powers movie. The widow of the writer Quincy Jones received the royalties. Which is nice, but I personally I don't see why we should bend over backwards for these kinds of rare scenarios. Tai Chi Turtle (I'm suspecting this is not a real game ;-) ) had its run and its authors were compensated reasonably. Soul Bossa Nova was written for another movie and the writer was compensated.
Why should we continue to offer a monopoly to something well beyond any reasonable expectation of profit? This is especially true when we deny people access to artistic works in the process. Let's give a monopoly for a period that covers a reasonable period and possibility of return, and that directly supports the author (without consideration to any entity who is not connected with the construction of the work).
The buttons are:
{Submit}{Fail}{Retry}
Where {Fail} and {Retry} simply reload the same page...
Like a lot of other things with Facebook, Google and the like people are getting worried at the wrong thing. If you are a normal person on Facebook, there are hundreds of photos of you. Your friends are happily tagging them with your name. So now Facebook has this huge database of faces and names. And we can see that they can implement automatic facial recognition. But people are upset that the information is being shared with their friends without notice.
That really shouldn't be the issue. The issue is that Facebook now has a database of your pictures and can match new pictures and get your name if they want to (or are forced to by the state). Having an opt-in for sharing the information with your friends is not as big a problem as the fact that users have already opted in by giving Facebook this information in the first place.
But of course the average person can't see beyond the end of their nose. "What would they do with that information anyway? It's useless" they say. And yet they hit the roof when Facebook actually uses it in the most trivial of ways.
The same goes for people who use their gmail (or yahoo or whatever) accounts and mail bank details, personal addresses, telephone numbers, credit card numbers, etc, etc, etc. People need to stop opting in to this stuff if they are going to complain later that it's getting used.
The summery says: "Created the videos in his own time, off-campus."
The video says: "This was done up back in November of 2010, for an economics course project."
So I don't think its as independent from school as this summary wants to make you believe.
That doesn't mean the school owns them however, so they have no right to threaten him with calling the police over the videos if he didn't take them down, which the same article tells you they did
It's not just the summary that's inconsistent, but the article as well. What this points to for me is that the article is garbage with respect to actually getting facts on the issue. Nothing about this makes any sense. I watched the video linked in TFA. Personally, I don't see why a school would demand that it get taken down. I didn't see any mention of the school (but it's possible I missed it). But, some schools are staffed by jerks. It's possible they went overboard.
The really weird thing is that the police are involved. And the student is suspended while the police continue the investigation. What on earth would the police be investigating? The *only* thing I could possibly imagine is hate crimes. Again, there was absolutely nothing of the sort in the linked video. There appears to be copyright infringement, but that's not something that the police would get involved in.
There is something seriously fishy about this article. Unless there is some clarification of the facts, I'm going to conclude that the reporter just has it wrong (conveniently so given the number of hits they are likely to get...)
Telling the computer what to do is only half of what I am doing (and the easy half at that). Telling other programmers what is going on is the other half. If we were only interested in whether the computer understood what I was saying then "good code" would equate to "does it run". Nothing else would matter. But future productivity is dependent upon the ability of programmers to understand and modify the code without breaking it. I've worked on systems where the code was so bad that the average programmer managed to write only 500 lines of code a *year* (and even then they were breaking things right, left and center). The company needed 5000 programmers to meet its goals. Needless to say that this company is no longer around.
To me the mark of a good programmer is that the code that they write is virtually always easy to understand. You look at it and can see pretty quickly what it does, that it does it correctly, and how you could modify it if you wanted to. I'm not against comments, but if you need to rely on comments to explain your code it might be a sign that things are not as simple as they could be. It might also be that the problem is complex, but in my experience the vast majority of code is performing mundane tasks. The complexity is coming from having to work around problems with the current design/implementation.
Don't get me wrong! There is more to writing code than the ability to program fluently! I've waded through enough ad hoc parsers and file formats that were based on context free grammars to know that. Algorithmic complexity, automata and grammars, normal forms and a few other things are really important. I used to work for a company that had a hard on for mechanical engineers. Smart guys, but never once took a CS course in their life. It took them a while for them to learn what they needed.
But seriously, how much of your code requires that knowledge? How much of your code needs to be well written, comprehensible and simple to read from another programmer's perspective? CS teaches theory and I have absolutely no problem with that. But good theorists don't necessarily make good programmers. We don't teach programming well. A lot of schools don't even teach theory well, but that's a different rant.
Do we need both? In my opinion, yes.
With respect to the monitor hypothesis: Yes, you are correct. Is monitoring important in a professional writer? IMHO, yes. Should you worry about monitoring before you are fluent? IMHO, possibly no. Again, this comes from Krashen's hypotheses of language acquisition, but since fluent output is the result of the acquisition side, you can't create fluent output before you have acquired it. You have nothing to monitor.
Having said that, in my own English classes, I include grammar and vocabulary specifically for monitoring even before fluency has been acquired. While it may not be necessary, and may even increase the amount of time necessary to acquire the language, it has a major benefit: It decreases the dependency on a teacher. I'm only available for a small amount of time. The rest of the time the students need to find comprehensible input by themselves. This often comes from reading. Since there isn't a dialog, they need a way to find meaning in the input. This can come from rules. However, without the input, the rules are next to useless. If I were to teach programming, I would probably approach it the same way.
Finally with respect to immersion. Relying on the input hypothesis is different from immersion. I actually taught myself Japanese in an immersed environment as an adult, so I have some experience with this. I never took a class. The problem with immersion is that it is not *comprehensible* input. It's a hell of a lot of incomprehensible input, with a tiny bit of comprehensible input now and again. With all due respect to Chomsky, my personal opinion is that even babies wouldn't do well in an adult immersion experience. A baby has a set of parents who are spending their time turning things into comprehensible input. Adults are rarely treated like babies and even complain if they are lucky enough to receive such treatment. People spout some insanely complicated thing to you and if you ask for clarification they just say it again louder. There are other problems with adults as well, but it's kind of off topic.
I should have been more clear when I said that we should immerse people in good code. What I meant was that we should immerse them in comprehensible good code. I don't suggest forgoing formal education. I'm suggesting that a good teacher of programming would be either finding or generating large amounts good code and creating comprehensible input from it. Students would spend a very large amount of their time reading good code that they understand. Their fluency would be frequently checked to see what they had acquired.
It does seem very similar, doesn't it? Thanks for the link. The "input Hypothesis" is a little different in that it discusses only language acquisition and doesn't propose a model for how that acquisition happens. It makes a distinction between "learning" and "acquiring", where someone can "learn" something but not be able to use it fluently. "Acquisition" means being able to use it fluently.
The "input Theory" merely states that no matter what techniques you use to teach language, acquisition only happens as a result of input that the student understands. Output for example, while it may be helpful, is not necessary. Also, input that the student doesn't understand (i.e., listening to or repeating dialogs which aren't understood) does not aid in acquisition. Similarly, memorising facts about language (such as grammar or translations) does not aid in acquisition, unless that activity results in generating comprehensible input (which it often does).
This input theory is hotly debated amongst language acquisition theorists. I think most people generally accept it, but many people have a real problem with the "only" part of it.
Having said all that, constructivism would probably fit as a mechanism for the input theory, though I'm sure other mechanism would also be viable.
http://jldrill.rubyforge.org/
Some good stuff there. Some crap. Overall I give myself a C+. As you are an anonymous coward, I don't suppose you'll ever see this. I'm not even sure why I'm responding to such a ridiculous comment. But I've always been happy to have people read and critique my code. Feel free.