Hi Comrades,
I just realized I never updated this blogspot account to the new party: www.morepaul.com has moved! To a Jekyll-powered site!
It looks... homely. But if you're looking at this, you're missing all of 3-4 posts I've written since January.
Onwards!
July 1, 2011
January 6, 2011
I'll be blogging again soon...
I just got back to work after a lovely, lovely break, and will get back to blogging Real Things soon. In the meantime, recording of a milestone:
I had what I like to think of my "first" "release" of ScrabbleCheat. In a match of Scrabble without it, Madly Brilliant beat me by 97 points. I used it successfully for the first time (with her knowledge and permission) and beat her the following game by about 83 points. There's still tons of work to be done, but its core is there, certainly.
I learned a ton from writing it, and hope to create a few animations/blog posts about it in the near future. This flowchart to writing Good Code, by xkcd, is relevant, mostly in relation to the quality differential between the hacktacular client code and less hackey server code.
I had what I like to think of my "first" "release" of ScrabbleCheat. In a match of Scrabble without it, Madly Brilliant beat me by 97 points. I used it successfully for the first time (with her knowledge and permission) and beat her the following game by about 83 points. There's still tons of work to be done, but its core is there, certainly.
I learned a ton from writing it, and hope to create a few animations/blog posts about it in the near future. This flowchart to writing Good Code, by xkcd, is relevant, mostly in relation to the quality differential between the hacktacular client code and less hackey server code.
December 13, 2010
How to tell someone their code sucks
Some days I just wish I were David Korn:
No, it's completely wrong-headed, insane and unreasonable. Your code is 100% bogus and should be taken out the back, lined up against a wall, and machine-gunned.
Then the bleeding corpse should be hung, drawn and quartered.
Then burnt.
Then the smouldering rubble should be jumped up and down on.
By a hippo.
December 10, 2010
Something nice about every language I've used
Inspired by this post (and more great answers on the reddit comment thread), here's one nice thing about each of the languages I can remember using in any meaningful capacity:
Java: I learned to program in this. It led to the creation of the JVM, and while Java isn't my favorite language, the JVM is a pretty sexy piece of technology that enabled a number of other languages (Scala and Clojure most notable) to flourish.
C: The closest thing imperative programming has to "sparse beauty," a la Scheme. Shows you really don't need many bells and whistles to do a job, and do it well.
C++: Back when everyone was using C, it's kind of a technical miracle that Bjarne could create a proper superset on top of C with the features it has. Further, it's still blazing fast; without it we wouldn't have all the video games we love today ^_^.
PHP: Incredibly easy to learn, and no-hassle to set up on a server. One of the matches that lit the web on fire.
Racket (and Scheme applies here too): The language that never lets up. The most delicious learning curve I've ever tasted. Like Wagner's music is jokingly said to be "better than it sounds," Racket is more fun and fulfilling than it deserves to be.
Erlang: Industry-proven functional programming with more concurrency love than 1000 suns. Also the top language for gaining hipster-programmer cred. When you drop this name, suddenly everyone looks at you like "that guy" (you can decide if this is what you want or not).
Haskell: A wolf in sheeps's clothing, the most modern, practical, and supported language with features I think we'll see as necessary in the future. Another candidate for learning curve that keeps on giving.*
SML: A really sick module system for programming in the large. While not my favorite for "programming in the small," an understanding of SML's module system makes you pity that it never really took off.
Ruby: One of the most beautifully designed, fully-realized languages I know. Shows you can make a language that is simple, with practical value for Herp Derp programmers without sacrificing power and flexibility for the craftsmen as well.
Objective-C: The real "C with objects." Message passing with named parameters (and the much more sensible #import rather than #include), this is one time where I'm highly in favor of Mr. Jobs' stubbornness.
Prolog: 10-second youtube video. I mean this in a good way.
Max/MSP: Probably the most fully-realized and pleasing graphical programming environment I know, as well as an example of a damn fine DSL.
Javascript: I don't have to worry about compiler errors! No seriously, prototypical objects for the masses.
Flapjax: Functional reactive programming! An excellent example of functional languages and concepts attacking problems from the language level. Very innovative workaround for the horrors of client-side programming of the time.
Actionscript: Adobe makes it! Like Java, but better (Flash Platform > Swing/most Java GUI's).
*= Small qualification on the learning curve lines: virtually any language takes years of work over dozens of programs to "master." But many times mastering a language means compensating for its weaknesses, not discovering new strengths. That's what Haskell and Racket have given me more than most other languages.
Java: I learned to program in this. It led to the creation of the JVM, and while Java isn't my favorite language, the JVM is a pretty sexy piece of technology that enabled a number of other languages (Scala and Clojure most notable) to flourish.
C: The closest thing imperative programming has to "sparse beauty," a la Scheme. Shows you really don't need many bells and whistles to do a job, and do it well.
C++: Back when everyone was using C, it's kind of a technical miracle that Bjarne could create a proper superset on top of C with the features it has. Further, it's still blazing fast; without it we wouldn't have all the video games we love today ^_^.
PHP: Incredibly easy to learn, and no-hassle to set up on a server. One of the matches that lit the web on fire.
Racket (and Scheme applies here too): The language that never lets up. The most delicious learning curve I've ever tasted. Like Wagner's music is jokingly said to be "better than it sounds," Racket is more fun and fulfilling than it deserves to be.
Erlang: Industry-proven functional programming with more concurrency love than 1000 suns. Also the top language for gaining hipster-programmer cred. When you drop this name, suddenly everyone looks at you like "that guy" (you can decide if this is what you want or not).
Haskell: A wolf in sheeps's clothing, the most modern, practical, and supported language with features I think we'll see as necessary in the future. Another candidate for learning curve that keeps on giving.*
SML: A really sick module system for programming in the large. While not my favorite for "programming in the small," an understanding of SML's module system makes you pity that it never really took off.
Ruby: One of the most beautifully designed, fully-realized languages I know. Shows you can make a language that is simple, with practical value for Herp Derp programmers without sacrificing power and flexibility for the craftsmen as well.
Objective-C: The real "C with objects." Message passing with named parameters (and the much more sensible #import rather than #include), this is one time where I'm highly in favor of Mr. Jobs' stubbornness.
Prolog: 10-second youtube video. I mean this in a good way.
Max/MSP: Probably the most fully-realized and pleasing graphical programming environment I know, as well as an example of a damn fine DSL.
Javascript: I don't have to worry about compiler errors! No seriously, prototypical objects for the masses.
Flapjax: Functional reactive programming! An excellent example of functional languages and concepts attacking problems from the language level. Very innovative workaround for the horrors of client-side programming of the time.
Actionscript: Adobe makes it! Like Java, but better (Flash Platform > Swing/most Java GUI's).
*= Small qualification on the learning curve lines: virtually any language takes years of work over dozens of programs to "master." But many times mastering a language means compensating for its weaknesses, not discovering new strengths. That's what Haskell and Racket have given me more than most other languages.
December 7, 2010
STOP IT WITH YOUR STATE
Alright forks, time for some smugness. I know, on this blog?!? But bear with me.
I'm just completely frakking pissed at a number of bugs I've been chasing down, at work and at home, and after looking for the more general problem, it's all about state. ALL OF IT.
Okay, not all of it. Most of it has to do with poor abstractions at the programming language level. But the primary one is state, and mostly, I think it's about time just done gone outgrown that shit.
Java was such a rousing success in part because it was so completely idiot-proof. When you remove memory management and pointers from C++, and sandpaper a few of its edges (no header files or need to declare methods, for example), virtually everyone can program in it and not make too big a mess. While I think Java is a completely neutered language (not to mention a liability issue), I think it really didn't go far enough. No, forks, let's learn from our friends in the 1970's and 80's and just flat out remove mutable state already, since most programs don't need it and most programmers can't handle the responsibility of it. The same goes for pointers, but you already knew that.
Despite it being un-rantey, let's qualify this for a second: I'm not saying all programs should be written statelessly, or that nobody should be using pointers. And Lord knows all programmers would ideally know more than just the basics on these topics. We'll always have a need for embedded systems, operating systems, very fast media processing, and scripts we'll use only once and not want to think too hard about.
The problem comes with all the rest of the programs, that don't need instruction-level efficiency; many are still written with mutable state as the default rather than a last resort. This is like solving your problems with beatings before you try reason. Most programmers use it willy nilly, thinking they're holding firecrackers when they're really holding grenades.
Here's ultimately the reason: in today's day and age, knowing what we know and writing the programs we want to write on the hardware we have, state is an abstraction that is too easily broken for the power it gives you, and it's about time we outgrew it. Let's look at the popular programming paradigms from the abstractions they rested on, and you notice a trend:
Structured programming: this was at first met with resistance: why would you eliminate gotos? The answer was the best noun-made-command I know: goto hell. As programs got larger and larger, there came a point where there was just too much complexity associated with being able to arbitrarily jump to any lexical location in your code. Since this was often in languages with file inclusion, this meant you could jump anywhere in any file you were including from anywhere else!
What was the solution? Was it moar gotos? IDE's to help with goto-related programming? No forks, they just cut that shit out and started structured programming. This led to a great bloom in software, where we got all our delicious *nix dinosaurs we know and love even today.
But what about GIANT programs, like Word? What made that possible? Because again, at a certain scale, this paradigm got unmanageable. Namely, keeping track of all the data associated with a function got to be way too complex. Structs of structs of structs would lead to 3-star programmers that made code a vile mess to work with and debug. It was only when we decided to encapsulate data with its related function in objects that we got to Object-Oriented programming.
And that led to its own bloom of awesomeness. But really forks, have we solved software? Is it too unreasonable to think that maybe objects* rely too much on state to be as scalable as the programs we want to write these days?
(Never mind the other, non-state objections to OOP, such as modeling programs that do things entirely with nouns, or the avoidable lame hoop-jumping called Design Patterns that objects make us use).
It sounds extreme, but you don't know the shackles you're programming with until you break free of them. Once the outputs of a function depend entirely on its inputs, it actually becomes reusable. You only have to test the outputs for every set of inputs, not the outputs for every set of inputs at every possible state the whole rest of your program can be in!
Further, once you eliminate the null value or null pointer, a function call must return "Whatever I promised," not "Whatever I promised or NULL lol go debug that."
And the sooner we do this, the sooner we don't have to sit at our debuggers stepping through reentrant code looking at register values for the exact moment the memory's head a splode.
Most of all, I'd have to find another way to be inflammatory, rantey, and use too much formatting markup.
*= Note that my beef isn't entirely with objects, per se. there are object-oriented languages that don't rely on state. Scala is the most popular that encourages functional programming, and Reia has immutable objects.
(for those curious, I'm mostly up to proverbial here with my last bug on a major ScrabbleCheat feature. I veered away from Erlang to write the UI in Ruby with an ncurses wrapper, and now that I've dabbled in a stateful solution I'm fighting memory corruption in a language without explicit memory management. Bleh.
Meanwhile, I'm hating on C++ because a) I use it at work, b) in the playtimes I've used it, I've only ever regretted it, and c) it's C++, what kind of language snob would I be if I treated it fairly?)
I'm just completely frakking pissed at a number of bugs I've been chasing down, at work and at home, and after looking for the more general problem, it's all about state. ALL OF IT.
Okay, not all of it. Most of it has to do with poor abstractions at the programming language level. But the primary one is state, and mostly, I think it's about time just done gone outgrown that shit.
Java was such a rousing success in part because it was so completely idiot-proof. When you remove memory management and pointers from C++, and sandpaper a few of its edges (no header files or need to declare methods, for example), virtually everyone can program in it and not make too big a mess. While I think Java is a completely neutered language (not to mention a liability issue), I think it really didn't go far enough. No, forks, let's learn from our friends in the 1970's and 80's and just flat out remove mutable state already, since most programs don't need it and most programmers can't handle the responsibility of it. The same goes for pointers, but you already knew that.
Despite it being un-rantey, let's qualify this for a second: I'm not saying all programs should be written statelessly, or that nobody should be using pointers. And Lord knows all programmers would ideally know more than just the basics on these topics. We'll always have a need for embedded systems, operating systems, very fast media processing, and scripts we'll use only once and not want to think too hard about.
The problem comes with all the rest of the programs, that don't need instruction-level efficiency; many are still written with mutable state as the default rather than a last resort. This is like solving your problems with beatings before you try reason. Most programmers use it willy nilly, thinking they're holding firecrackers when they're really holding grenades.
Here's ultimately the reason: in today's day and age, knowing what we know and writing the programs we want to write on the hardware we have, state is an abstraction that is too easily broken for the power it gives you, and it's about time we outgrew it. Let's look at the popular programming paradigms from the abstractions they rested on, and you notice a trend:
Structured programming: this was at first met with resistance: why would you eliminate gotos? The answer was the best noun-made-command I know: goto hell. As programs got larger and larger, there came a point where there was just too much complexity associated with being able to arbitrarily jump to any lexical location in your code. Since this was often in languages with file inclusion, this meant you could jump anywhere in any file you were including from anywhere else!
What was the solution? Was it moar gotos? IDE's to help with goto-related programming? No forks, they just cut that shit out and started structured programming. This led to a great bloom in software, where we got all our delicious *nix dinosaurs we know and love even today.
But what about GIANT programs, like Word? What made that possible? Because again, at a certain scale, this paradigm got unmanageable. Namely, keeping track of all the data associated with a function got to be way too complex. Structs of structs of structs would lead to 3-star programmers that made code a vile mess to work with and debug. It was only when we decided to encapsulate data with its related function in objects that we got to Object-Oriented programming.
And that led to its own bloom of awesomeness. But really forks, have we solved software? Is it too unreasonable to think that maybe objects* rely too much on state to be as scalable as the programs we want to write these days?
(Never mind the other, non-state objections to OOP, such as modeling programs that do things entirely with nouns, or the avoidable lame hoop-jumping called Design Patterns that objects make us use).
It sounds extreme, but you don't know the shackles you're programming with until you break free of them. Once the outputs of a function depend entirely on its inputs, it actually becomes reusable. You only have to test the outputs for every set of inputs, not the outputs for every set of inputs at every possible state the whole rest of your program can be in!
Further, once you eliminate the null value or null pointer, a function call must return "Whatever I promised," not "Whatever I promised or NULL lol go debug that."
And the sooner we do this, the sooner we don't have to sit at our debuggers stepping through reentrant code looking at register values for the exact moment the memory's head a splode.
Most of all, I'd have to find another way to be inflammatory, rantey, and use too much formatting markup.
*= Note that my beef isn't entirely with objects, per se. there are object-oriented languages that don't rely on state. Scala is the most popular that encourages functional programming, and Reia has immutable objects.
(for those curious, I'm mostly up to proverbial here with my last bug on a major ScrabbleCheat feature. I veered away from Erlang to write the UI in Ruby with an ncurses wrapper, and now that I've dabbled in a stateful solution I'm fighting memory corruption in a language without explicit memory management. Bleh.
Meanwhile, I'm hating on C++ because a) I use it at work, b) in the playtimes I've used it, I've only ever regretted it, and c) it's C++, what kind of language snob would I be if I treated it fairly?)
November 21, 2010
Another lazy video post
The weekends are when I get lazy. I got promoted to Diamond League in Starcraft. I'm still plugging away on ScrabbleCheat (see the branch 'feature-curses-ui'). Did me some laundry.
While folding/placing laundry and cleaning up my room, it's good to have some videos or music playing. If you have an hour to burn, there's a great 1 hour interview in 4 15-minute segments with Christopher Hitchens:
If you only have 7 minutes, in honor of our departing Governer:
While folding/placing laundry and cleaning up my room, it's good to have some videos or music playing. If you have an hour to burn, there's a great 1 hour interview in 4 15-minute segments with Christopher Hitchens:
If you only have 7 minutes, in honor of our departing Governer:
November 18, 2010
Every morning of my undergrad
I had a Serious post all lined up, made of words and things, but found an old video I forgot the name of, and decided to post it instead.
It's been a long, exciting week at work, kids. I'll post with words and write some long delayed emails when I have a wee bit more energy ^_^
It's been a long, exciting week at work, kids. I'll post with words and write some long delayed emails when I have a wee bit more energy ^_^
Subscribe to:
Posts (Atom)
Posts
