blog.zacbrown.org - just run away, now.

cheers

So I found out a couple evenings ago that I got the internship with Google. I would start sometime in mid-May and finish up sometime in mid-August. It would be good fun though it is mildly disappointing that my friend (Danny) that works for Google wouldn’t be there during the time I’d be there. He’s finishing up his last semester of college andwill be arriving there about the time that I would leave.

I’m excited and anxious all at the same time, dealing with getting myself a place to sleep will be interesting. Maybe I can just sleep under my desk and shower at the office?

jeers

I was less than pleased with my grades this semester. I ended up with a B+ in both Algorithms & Software Eng. This could change though for Algorithms as I emailed the professor and he said we could speak about possibly getting me an A- which would be great.

Software Engineering on the other hand, I apparently bombed the final. That puzzles me but I’m going to meet with the professor. Surely I didn’t do that poorly? I’m not a bad student…

notes

Anyway, back to programming on wine

So after many failed attempts I finally got a pair of patches committed to wine. You can see them here and here. I’m finding that the more and more I learn about wine, the more and more I get addicted to working on it.

The code, compared to many projects written in C that I’ve seen is very clean. The community is helpful and there’s always something to do since I’m pretty sure there’s a sizable 40-50% of the api thats not completely implemented yet.

Hears to exams and coding.

I was browsing my feeds in Google reader and came across this blog entitled “Signs You’re a Crappy Programmer (and don’t know it)”. For the most part I thought it was fairly accurate with the exception of not following the rule of trying to make your functions less than 20 (30/40/10/whatever) lines of code.

Now I’m not hardline on it, I think one should try to make all functions as short as they possibly can, but I do understand that some functions just can’t be made that way. I think preaching hard line either way is a bad plan but one as a general rule should try to keep functions short and sweet. Writing big long functions makes it hard for people besides yourself to follow the code quickly. I’ve dealt with my share of crappy functions that were a hundred lines long and totally unclear. Thats what you get when you work with people that aren’t programmers first though.

I saw a reddit question today that was something along the lines of “I’d like to learn 16 languages in a year, which ones should I learn?” This of course sounds ludicrous to me and I definitely advocate against that. I think a better goal for working in a year (and this is stretching it) is to learn a language from the four major language groups (in my opinion) well. This is by no means an authoritative list of languages, but rather a list of languages that just by learning them can teach you things that other languages wouldn’t and thus make you a better programmer.

Lisp - It seems that many ideas and features people look for, Lisp already has, so take some time to learn them here, it’ll definitely make you a better programmer.

Haskell - Everything is a function, and thus you have no side effects. This will teach you to right better code in that you will end up trying to reduce side effects in your Java/C++/Python etc. code.

Erlang/Smalltalk - The beauty of message passing comes out in both these languages, Erlang more in a truly distributed manner. I personally am learning Erlang and love it.

C/Assembly - Working in lower level languages like these two will teach a you a lot about thinking about how you write something will effect different architectures. I know C and haven’t had a chance to really play with Assembly yet.

I’m half way through that list, that is I’ve learned C & Erlang pretty well, next is Lisp. I think those are some of the best you learn. Learn a few things well, the others will come, languages are merely syntax, its the idioms, paradigms and skills that will make you a better programmer, not the language.

Wanna know what really chaps my ass? People like Louis Savain and his COSA project. In science and math I tend to take a fairly hard line when it comes to most things. That is: If you can’t show it, you don’t know it. Now thats not to say that theoretical physicists or mathematicians are wrong because they can’t show something, but at some level you have to have some sort of substantial product or outcome to what you purport.

Now the problem with Mr. Savain is he goes about calling all programming languages crap, blaming software models on the reason why “stuff isn’t as good as it could be” and saying that hardware models are the solution. Now this is all good and well, everyone’s entitled to their opinion; so long as they do not redefine words or invent bunk terms. My favorite word that he’s redefined is algorithm. The definition of algorithm from webster.com as follows: a step-by-step procedure for solving a problem or accomplishing some end especially by a computer. Now I don’t know about everyone else but I’m pretty sure that regardless of paradigm (functional, concurrent, imperative, procedural, object oriented etc.) at some level you must have a plan on how your program is going to accomplish its goal. I know in Prolog, thats a bit more blurry, but at some level you must describe a mechanism for which your program will solve the problem.

All in all, if you spend enough time reading his posts as well as his website, you start to see that he’s a complete crack pot. He has no substantial evidence for what he writes, no clearly defined product that he’s published or created. All in all, just a lot of fluff.

Can a brother get an amen?

I was browsing the net, as I usually do in between classes and ran across a blog by Colin Percival. Simply put he asserted the importance of “Think[ing] before you code.”

His point is more familiar to programmers working in complex modeling tasks or trying to write efficient database transactions than it is to those who have been writing large amounts of “get the job done” code; that is code that isn’t particularly burdensome to the system but is necessary to complete a job. I personally do a lot of programming the modeling area of things since I’m a research assistant for someone whose work revolves around computational models.

Often the programs I write are more complex than my knowledge can compensate for so I often spend days at a time in my office reading up on the models I’m trying to write. Thus, this practice of “thinking before I code” has become a habit. Even for simple class problems, I may spend more time with a pen and pad than I do at my keyboard writing code. The planning out and researching tends to lead toward a more clear and defined goal than I would have developed otherwise.

That said, I know more than a couple programmers who ought to look at that article and take it to heart, in fact everyone should really take it to heart if they want to learn to be a better programmer.

I was browsing reddit today and ran across a blog entry by Shannon Behrens. He was discussing odd hangups that different CS people that he knew had, specifically the bright ones. Now I’m not sure I consider myself any sort of beaming, radiant, CS luminary with profound ideas but I consider myself a pretty good programmer.

Shannon mentioned that his major hangup is that he’s an open source fanatic, that is he’ll use a lesser product if it means the difference between using proprietary software and open source software. Now this isn’t a terribly bad hang up in my opinion, though I can see how some might see it as out of hand if you get into the blurry zone of proprietary drivers for video cards and the like. Now Shannon’s hangup sounds a lot like my friend Andrew A.’s hangup. He too is obessesive about using open source software. He is an administrator for a free shell service for developers and with this shell service he uses Debian on the server. Now I offered up my Sun Enterprise 220r as another server for the service to use for users who wanted to play on some Sun hardware. Now it started out that I used Ubuntu on that and though Andrew A. never explicitly asked that I use Debian, he hinted at it because Debian has the “free, open source” philosophy. Long story short, I’m now running Debian on that server.

As for a weird CS hang up for me… I’m zealous about writing concurrent code only in functional or concurrent oriented languages. I refuse to write code that even attempts to be concurrent in anything like C/C++/Java. When I took a course last semester for C & UNIX programming, one of our assignments included fork()/pthreads. It took all my might to make myself write this program in order to fulfill the requirements for the labs. Even at my current job as a research assistant, in order to avoid writing multi-threaded code in Java I converted an ecology computer model into Erlang in order to work with the threading in Erlang instead of Java which turned out to be a fairly large project.

I don’t know what it is, maybe just the pure ugliness of multi-threaded/multi-proc code in imperative or object oriented languages that creates a mental block for me to write that kind of code in languages like Java or C/C++. Note that I’ll write in those languages, just not with concurrency.

Ah yes, its that time again, time to go back to classes and take courses and all those fun things. The best part though is taking classes you shouldn’t be taking the course because you already know the information because most of it is common sense for those headed into your field.

Thats me this semester. I’m taking CSC314, Computer Architecture & Organization. On this glorious first day of class we discussed the components needed to build a basic computer… why are we talking about this again?

Most kids will never use this information in their Computer Science careers, let alone most of them won’t become very good computer scientists. Their programming skills are marginal at best and their knowledge of how different operating systems, programming languages, and so on differ and work is lacking at best, if not abysmal.

Now I’m not a crazy-super-awesome-mega programmer, but I know my way around a computer and I’ve done my share of programming in the last 7 or 8 years. I’ve spent hours working in different languages and worked two different jobs in programming. Its really sad when these kids aren’t even aware that an operating system besides Windows & Mac OS X exist, let alone that Mac’s use a different OS than PC’s do (for consumers).

I feel like this call to have more computer scientists is going to need to be pushed harder in high school. The worthless (at best) knowledge that most kids bring to college with them is not enough (in my opinion) to start out in Computer Science. There should be more high school curriculum and so on and on and on…
.

Anyway, lets get back to learning about things I already know!

So currently Erlang is the flavor of the week. I pre-ordered the new Erlang book from Pragmatic Programmers, “Programming Erlang: Software for a Concurrent World” by Joe Armstrong. As it turns out Armstrong is also one of the original authors of the Erlang language. Now you ask: “Why would anyone want to use Erlang and whats it good for?” Guess what, you’re in luck, I’m here to tell you in fact.

Erlang is a beautiful mesh of concurrent and functional goodness that makes writing programs a succinct and (mostly) bug-free endeavor. Where Erlang exceeds though is in its concurrency abilities. It has very little overhead for creating new processes, just 300 bytes a piece compared to 1 Kb for other languages like C. These lightweight threads/processes combined with Erlang’s functional nature make it ideal for distributed systems (Oh goody! Exactly what I do in fact!).

After having had some time to play with the language, I have to say its one of the more fun languages I’ve worked in. I started out trying to write some stupid “idea” programs but quickly remembered ProjectEuler.net. I set out a day ago to rewrite some solutions to the Project Euler problems in Erlang and have had no problems. In fact I’ve gotten excellent results from Erlang and am learning a lot as I go.

Anyone who hasn’t looked into Erlang and is looking into getting into functional programming ought to have a look at it before any other language. Its a good way to ease yourself in so you don’t have to tackle the idea of Monads and such too early on which are found Haskell, Clean, and Ocaml, which are some fairly popular functional languages.