briancarper.net (λ) (Tag: C)

C++, blech

Tue, 01 Apr 2008 22:15:36 -0700

I decided to try a GUI app. I decided to use QT4. I then quickly remembered why I don't ever use C++ for anything. The amount of bullcrap you have to go through just to get a simple program going isn't worth the bother for the kinds of programs I write. I spent an hour on this and I haven't even started writing any of the actual program yet. Just setting up boilerplate garbage, using qmake to make the project file used to make the Makefile used to compile my program someday if I ever actually progress far enough to write it. But no, the compiler couldn't find some of Qt's headers, so I get to hunt them down and pray. Nope, not worth my time. You know it's a bad sign when you can copy/paste a Qt tutorial right from the Qt docs and it won't compile.

I've always detested C++. I thought maybe I'd start liking it more as I learned more about how computers and compilers and interpreters work, but no, actually I like C++ less and less. I read some books on C++ a while back and it seemed nice at the time, but reading about a language and using it yourself are two very different things. I find myself disliking statically typed languages in general in ever-increasing amounts. And languages without garbage collectors seem archaic to me. And any language that requires you to learn multiple new languages just to be able to configure and use the tools used to build your program is ridiculous. I have a hard enough time getting my logic right, let alone having to hand-hold the computer while it laboriously and clumsily stumbles through my code. Ruby and Lisp have spoiled me.

And God help me if I ever want to run it on someone else's machine. Or a different OS. I started looking into how to compile Qt apps in Windows and now I shudder to think what I almost got myself into.

Interpreted languages are as close as anyone's going to get to "Write once, run anywhere". Step 1: Install Ruby. Step 2: Write Ruby code. Step 3: Run it. Short of places the OS leaks through like pathnames or system calls, your program will work. End. Underneath all of that, someone still had to figure out all the low-level crap. But someone smarter than me figured that out, and had to figure it out ONCE, and then it's done with and I can take advantage. Worst thing that can happen is I get some missing Ruby files and throw them in a directory somewhere Ruby can find them.

Programming after all is all about abstraction. Abstraction layers help us deal with complexity. Ruby is an abstraction layer over a mess of C code and compiled and linked binaries and libraries that I never have to look at. That's the way I likes it.

I was going to use Ruby's QT bindings for this app, but I want it to be multithreaded, which probably rules Ruby right out. Sad. Maybe Python has good Qt4 bindings. Horrifying though the thought of writing Python may be, at least the syntax is more stomach-able than C++.

PAIP, review one of probably many

Wed, 06 Feb 2008 01:12:18 -0800

I got through the first four chapters of PAIP yesterday and today. It's good so far. I had reservations about spending $80 on a book, but it's 950 pages and almost all of it is good stuff, from what I can see at a glance. Little space is wasted on introduction material or tutorials for people who know nothing about programming. He dives right into the good stuff in chapter four.

Already I've picked up a few nice bits of info, interesting standard functions / macros like TRACE which is good for debugging. And SUBLIS which takes a list of (key . value) sublists and replaces all the keys with all the values, in some other list. Common Lisp is such a freaking huge language, in terms of its standard library of functions. Good thing or bad thing? It may be a bad thing if not for the fact that you load Lisp once and it persists forever.

Norvig makes an interesting point about the REPL. What do most programs need to do? Take input from the user, do something with it, and give output back to the user.

To get input, your program can read from command-line args, or prompt to STDIN, or take it out of text fields in a QT app, or read it from a config file. But it's generally always strings. So you get some strings, and then what? You have to figure out what the strings say, and either turn the strings into something usable or use the strings to figure out what action to perform. So you may have a dedicated library to parse command-line args and a dispatch table to map them to function calls. Or you may match the strings against a regex and depending what the strings look like, turn them into your language's representation of an integer or float using some "parseInt" or "parseFloat" functions. Or if your strings are XML, you may parse them into some big funky XML structure, then access bits of that structure to figure out what to do.

In Lisp on the other hand, you happen already to have a powerful reader/parser at your disposal: the REPL itself. It already knows how to read string representations of lists, numbers, pathnames, and many other things, and it can turn them into Lisp objects for you with no effort on your part. If you were using Ruby or Perl, short of ~~evil~~ eval, you wouldn't get anything close to that capability in your program.

What's more, the REPL knows how to read string representations of Lisp code (new functions and function calls etc.), and evaluate the code and end up with Lisp objects. It would be like if you wrote a C program which prompted you for input, and the input you gave could be a string representing a new C program that when run would produce a string that contained your input (or produce in-memory C structures your C program could use). So the main program would call GCC and compile and run your input to get results and use those results as its final input. Except that still wouldn't be nearly as powerful as what Lisp is doing.

So if you can figure out how to shape your input into a form that the Lisp reader can read, you're set. And it so happens sexps are a great representation for a great many things. Maybe this is part of why Lispers seem to worship the REPL and shun compiling their apps into command-line, standalone executables? Maybe this is part of what's meant by the oft-quoted-to-death Greenspun's 10th Rule?

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Much more PAIP to follow. It should be enjoyable. There's nothing like a good book.

False

Thu, 13 Dec 2007 19:55:25 -0800

In Ruby, the only things that are false are nil and false. This is a nice change over other languages where other things evaluate to false in boolean tests. Like C and many others, which considers the integer 0 to be false. So is 0.0 false? How about 1e-999999? Or there's Perl, which also considers an empty string to be false, and auto-casts between numbers and strings, which can make things fun. And of course Perl has Perlish insanity like 0E0, "zero but true".

However all languages pale in comparison with PHP. They provide these handy charts to help you figure out what's true and what's false.

That really sums up PHP well. You have three standard functions (isset, is_null, empty) with completely inconsistent names. Two equality test operators whose meaning completely changes between PHP versions. And then a couple of 12x12 grids of crap necessary to figure out how they behave.

"0" == 0? True.

0 == ""? True.

"0" == ""? False...

null == array()? True....?

Really makes you appreaciate Ruby.

K&R

Wed, 12 Sep 2007 14:07:28 -0700

I got K&R (the ANSI C version) as one of the going-away presents from my current / last job, and I just finished reading it.

A lot of what's in the book is sort of review for me now but there were some things I'd never seen before. For example in the book they like to put function declarations inside other functions instead of globally at the top of the file. I never even thought to do that, for whatever reason. I also was unfamiliar with some of the more obscure corners of the C language, like register variables. Apparently the book was just written when ANSI was becoming / had become standard, so it's also fun to get a small glimpse at how things were before that. (They looked to be a mess.)

It's definitely the kind of book I wish I'd have had back in high school when I was just learning to program. For example the very straightforward explanation of how file handles work in Unix systems is nice and clear and is one of those things that I was wondering about for years in my youth: How is it that I can access stdout, stdin and stderr without doing anything? Where are those handles coming from? They seemed to be there like magic, and I never knew if it was always safe to assume that I'd have those available in every programming language I used on every OS I tried, or what. Likewise, I remember in the vast majority of programs I wrote in high school, I would trip up over I/O buffering. K&R explains that really well also.

Things that everyone "just knows" and assume that you also know are the biggest pitfall in learning computers, to me. Unix / Linux seems chock-full of that kind of crap. How do you know to try --help or man to figure out how to use a command? How do you know that ~ means "home directory"? How do you know that you start X via startx? If you don't know those things, short of asking someone else, it's very hard to discover how to do them. For people who know how to do it, it's such common knowledge that no one bothers to write it down. It's a huge leap that people have to make when first learning Linux or programming in general. A book like K&R is great because it gives you a starting point, and they explain pretty much everything. "Comprehensive" is probably the word I'm looking for.

In any case, as a rule, I detest low-level programming, of the "bit-twiddling" form. But there's obviously a need to know how to do it at times, and I think if I was more in the practice of falling back to C or other low-level languages when the problem at hand demanded it, I would probably be a better programmer. So I'm glad to try to learn more of it.