Affluenza

But it won't be enough. Because this is not, fundamentally, a technological problem. Nor is it, fundamentally, a political problem. This is a problem of appetites, and of narcissism, and of self-deceit. The planet is breaking, and it is breaking under the weight of our hunger for more. To reform the world, we must first reform ourselves." -- Affluenza.org

This really resonated with me. It's so true and yet so few people know it. BTW I searched for this after reading Oliver James's articles in The Economic Times.

I like that

As found on IIT Bombay's Techfest

On a side note, I SO NEED to be at BarCamp. Too bad I've got exams. Seriously next year I'm going to every damn festival.

Pain, Horror and Redemption 1

Welcome to the first of many PHR incidents to come in my life.

---

I updated grub and rebooted.
What followed was 6 hours of endless bootloader overwriting, staying awake till 2am, wiping out the windows bootloader twice, installing Elive, Arch, Mandriva on spare partitions, hoping that somehow i could get the bootloader to boot into my system.

It kept complaining about not being able to find /dev/hdd2, the root filesystem.
Then i realized that in the error messages, it was just mounting all sd* drives.

So I change hdd to sdb and voila!

Today I find out that the IDE and SATA code was merged in the kernel, and the bootloader update probably rewrote the paths or something

Lesson Learned: Read errors properly before doing all sorts of crap.

---

PHR stories are stories about my own incompetence/stupidity. No product mentioned herein is being insulted unless I specifically say so.

KDE 4.0 out!

Well it isn't in the Arch Repos yet, but the release announcement and visual guide do make me drool :D.

And its good they made the panel go all the way to the edge of the screen.

Factor: Guess the number

My first useful factor program.


! A guessing game
USING: calendar random strings namespaces prettyprint math.parser io io.files math kernel combinators ;

IN: guess

! lets choose our number
SYMBOL: answer

! initialize the generator
now timestamp>unix-time init-random

! get a number [1..100] and put it in answer
100 random answer set

answer get .

! keep asking the user
: start-guessing ( -- )
"Enter number: " print
! get the number as a string
stdio get stream-readln
! convert to integer
string>number

! push on answer
answer get
! now stack top is : input, answer
{
{ [ 2dup < ] [ "try higher" print start-guessing ] }
{ [ 2dup > ] [ "try lower" print start-guessing ] }
{ [ 2dup = ] [ "Thats right!" print ] }
} cond

;


You might want to try it in the UI, the command line listener seems to have issues flushing the I/O streams. To run go:

"<path>/<filename>" run-file


Notice the lack of looping in Factor ( it's available but not recommended ) and using recursion in its place.

Programming: What they don't teach in school

This is my honest opinion, feel happy to flame or contradict me, but be polite.

Much has already been written about how much High School computer science teaching sucks ( High school computer science education ). As a student who has just left high school I just wanted to present my 2 cents on how bad the seperation between RealWorld programming and ClassRoom programming is. A common rebuttal is that there isn't enough time. I agree there isn't, but half-baked knowledge is dangerous. If you teach something, teach it qualitatively, not quantitatively.

The Problems

Tool Power

A programmer is only as good as his tools, and how well he can use them. But schools generally lock down students to a specific ( often crappy ) tool. For example, we've Turbo C++ 3.0 ( 1992 ) on all computers. That is a 16 year old environment, supporting 16 year old standards. That's bad! In the days of Linux and Wikipedia do you really want kids raised on old proprietary standards. The ICSE board is very good atleast in their terms. They say that any Operating System ( why are we still on Windows ) with a latest C++ compiler should be used. It seems our school isn't listening.

If you are on Java, you probably have BlueJ. Now I've nothing against the BlueJ folks, but hiding all the compilation details from the student is denying knowledge. Students ( especially the ones who got into CS just for fun ) are of course happy that they don't muck around with "hard" stuff. But thats not how things work in the RealWorld. You should know how to use the command line, invoke javac and java. And, fricking, you should know that Java files have a .java extension and .class is the compiled byte code.

Another issue is shortcuts, quick search and replace, commenting. Kids don't know any of these things. It's type, click, type. Click Save. Click Compile. And to change something there is always manual replace.

File Management

Typical high school level programs, if well written, are never longer than 2 pages. They are often crappy, in the fact that the logic is repetitive, their is no purpose to the program and that students still don't get it!

So when it's project time, what the instructor gets is a dump of humongous shit, often with all the code in main, bad indentation and no comments. That's because the instructor hasn't taught the kids anything about decoupling programs, and seperating classes in files, and using header files. Often the instructor himself has no idea about build systems.

Bad Core Concepts

One really bad thing I see among my fellow students, is the complete inability to realise that each statement is an individual component. It evaluates to something, and other statements can use that value to do their job. This causes repetitive coding. To illustrate see this code sample.

function isSpam(email) {
 if(email.contains('$$$'))
     return true;
 else
     return false;
}

Students aren't taught that email.contains is returning true or false, and all we care about is true and false. They are never taught to see function documentation, just use it the way the instructor tells them too. This code can be simplified to the following, because email.contains is already doing what we want it to do, why decorate it?


function isSpam(email) {
return email.contains('$$$');
}


Beautiful Code: Of Readability

Bad indenting. Student code is full of bad indenting. Instructor code is full of bad indenting.

Learn to appreciate code people. It's just as much art as painting or poetry. Encourage right indentation, make liberal use of whitespace, clean up your logic, don't nest too much. You should be able to go back to it after a few months and not have to spend time just cleaning it up.

Follow standard conventions for variable names, make sure your method names and parameter names make sense. Use camelCase or _underscores_. Make booleans start with 'is' or simply the condition you're representing. If any variable has more purpose than a loop counter or a position marker, it should have a meaningful name.

Name your files meaningfully, keep it lowercase, and keep all your fake 31337 ness to yourself.

Type for today, Think for tomorrow

It's a matter of thinking for 3 hours, writing 3 minutes worth of elegant code, versus thinking for 3 minutes, spending 3 hours typing up code.

-- Compsci.ca

The post above also mentions some of the crap I've mentioned here, like the 4600 line Sudoku.
Student code is littered with conditionals highly specific. The very reason you're using a high level language is to avoid this. I've seen quiz programs where each question and its answer is in an if clause, embedded in the program! Cardinal sin. Use a file and parse the file, if you can't do that, atleast put all the questions and answers in two arrays ( don't tell me about maps ). Then you can just use a loop to pick out the question and its right answer.

Make your code extensible. Just because this is some dumb program which you're writing in school, doesn't mean it should be a waste of muscle energy, disk space and time.

If you have to choose day's of the week, put them in an array. You want to find out the number of days in a month, use a 12 element array. Or better yet, use your brain a bit more and write this:


int daysInMonth(int month) {
if(month==2)
return 28;

else if((month%2 == 1 && month <= 7) || (month%2 == 0 && month >= 8))
return 31;

else return 30;
}


It might seem like more code, but you can write this code once and use it anywhere. And you are using your brain.

Solutions

Use better languages

Far too many schools have jumped on the Java bandwagon. If you are teaching kids who don't have much programming experience start with a higher level, small language. Use Python. You should be able to finish explaining most of the language within a week. Besides the interactive interpreter is great for messing around to know exactly how something works, how to make it go wrong and where it can fail. You will also spare them from the compile cycle ( I know, it kind of contradicts my first problem :p ), allowing them instant gratification. Spare them the brackets and let them develop the logic. Logic is far more important than syntax. Syntax changes, but logic is immortal.

Real World Knowledge

Once in a while just stop the programming, and discuss technology related issues, latest news, ethical considerations. Anything which expands their minds and gets them more interested in computers. There are more than enough anecdotes and quotes about programming, use them. Instructors should stay on top of news stories. You don't have to know what monads are, but at least know what Linux is. One of my instructors had never heard of Opera and Mozilla ?!? Whatever language you are teaching, make sure you know it well. The same instructor above didn't know that the Java GUI framework is called Swing. Make sure you are aware of atleast major upgrades and integrate them.

The Open Source ecosystem is set to flourish. Make sure your students are aware of what it is. Encourage them to try out FLOSS. If you can't convert to Linux, atleast use open source compilers, tools and languages on your Windows machines. Set aside a computer where you can mess with distros.

Encourage frequent group projects. Let the kids make plans. Tell them how to go about design. Make sure its extensible and adaptable. If the project will need something more than what is taught, tell them to read about it, while you do too.

Good Reading

I don't know about the rest of the world, but in India, Computer Science textbooks for high school are crap. They are full of errors, bad practices, incorrect language, and often old software. There are hundreds of better quality books available online, often royalty free. There is Wikipedia and Wikibooks. While using them, remember to tell your students how cool the Internet is, and teach them about sharing.

Mark for the big picture

There is this huge emphasis on theory at the high school level, mostly due to lack of time for practical assessment. Which means students have to often write programs and submit them without testing. In such situations, don't cut marks for syntax errors, unless they mess up the logic ( missing braces ). The compiler/interpreter is going to catch them anyway. As long as the program works correctly logically, missing semicolons are OK.

Rank readability above extensibility, extensibility above just-getting-it-done. If a student has used some cool logic, or exploited the specifications, give him some appreciation. After all programming is all about getting the best out of constraints, and pushing the limits. If he/she has looked to optimize, that's good too.

Don't hand hold

Far too many instructors help students fix their errors. Don't help them fix the errors, help them understand what the error is. Any decent language is quite verbose at error reporting, and in case of languages which support exceptions, the class name is often a very good indicator. Any decent compiler also reports line numbers. Let them fix the problem for themselves. Time well used now, is time saved later. Tell them it's called debugging.

Create some passion

Kate Masukomi sums it up nicely. Most programmers today are doing it to pay the bills. Don't let your students be one of them. If someone just doesn't seem to have any aptitude, maybe he should look into some other field. Encourage the good ones to expand out of the syllabus, mess with different languages and read sites like Proggit. Tell them to blog and learn HTML/CSS and create their own site. Don't create hundreds of typists, the world would prefer fifty real programmers ( thanks to lankythoughts for the link! ).

Conclusion

If something isn't done quickly, the IT world will be in a mess. Already the lack of real talent is leading to a shortage of employees. According to me, the only real coders are the people who are up breast with new developments and technologies. They don't have to know how everything works, but they should know that it exists. That's passion. They are the ones who read blogs, write them, comment on articles, are always hacking on side projects and have commits on some open source project. Make your students a part of that group.

P.S. Forgive my immodesty in certain areas :)

Information Overload

aseigo on KDE 4

Talking Bluntly

Refreshing.
That will shut up the pessimists.

Factor -ize

Its been a week since i discovered Factor. So first, it's stack based, it's small, it's almost tiny. I've never programmed in a stack based language before. But I liked it, really makes you think. Infact I haven't got any program written yet, just playing around in the interactive interpreter. It's got really good documentation by way of the API, what it could use is a quick start guide, ie. a list of some basic operations of the stack, using conditionals and looping and arrays and hashmap, because right now you've to look through the documentation for each concept, which means the unity is broken.

But great language, small community, even smaller existing code. What is bad is that most of the 'responders' give 404s. :(

1/1/2008

Welcome to the New Year!