Just some babblings by Jeff Sparkes

.

December 31, 2007

Why I like darcs

Filed under: Development

Darcs supports the checking in of individual patches, even if they’re in the same file.

Often when I’m fixing a bug, I find a few more too. Darcs lets me check in each of the fixes separately which give me a better change history.

I can do this with other SCMs, but it’s a lot of hoop jumping. I have to copy the fixed file somewhere, revert the working copy and then copy each of the fixes back into the working copy and check each change in. (I find ediff in valuable for this. It’s worth using emacs just for that one feature.)

Darcs just naturally fits my working style. I also have a tendency to make other changes while I’m editing, and sometimes work on more thing at a time.

Git users say that it operates on content, not files, but it appears that I can only commit a file. (I haven’t explored git very much). None of the other popular distributed SCM programs seem to have that kind of feature. Maybe “cherry picking” is close, but that seems to come after a commit.

Maybe darcs “theory of patches” is unique. And given the plethora of ways to get different SCM systems to interconnect, I can likely use darcs locally whatever the originating system is. This lets me work on various open source software using different repositories. The best of both worlds?

August 30, 2007

Hibernate3 + JPA + Eclipse = headache

Filed under: Software, Development

Until recently, I had never written Java 1.5 specific code. For technical and political reasons, it had to run on 1.4 jvms. I was also not familiar with web frameworks since maybe 2005.

I was making a web app to manage database information, and I decided to use a modern web framework to make myself “more productive”. Ha! They all seemed to use hibernate. I eventually decided to use Grails.

I also decided to use Annotations to handle the data descriptions. The JBoss Tools had hibernate support, and WST (I think) had JPA support. The first annoying part was that Eclipse expects you to create a new project to get JPA or hibernate support. I ended up merge .project files to get support for both.

The JPA tools are marked 1.0, but I don’t think they are ready for prime time. I got a lot of null pointer errors, but never got a backtrace in the error dialog to help me figure out what might be the problem. I got lots of “persistence.xml not found” errors. I move the persistence.xml file to various places in the project with no success. Eventually I edited the file with vi and discovered that it didn’t end with a newline. Adding one at least made it loadable. I never did get anything in my database.

Hibernate3 also supported use of annoations, but I never could put all of the pieces together correctly. The documentation was pretty patchy, odd things happened, and the error messages cryptic. I never found a single location for the hibernate.cfg.xml that made Eclipse, Maven and runtime happy.

I should have switched back to the older hibernate methods, but I was too stubborn. I wanted make it work the shiny new way at any cost, but it soon reached the point where it didn’t matter any more. Sometimes stubborness and persistence are good; sometimes it’s a character flaw.

The combination of a newbie and imperfect tools and documentation made me shoot myself in the foot. Next time, I’ll quit hitting my head against the brick wall earlier. I hope.

Do Haskell programmers hate variable names?

Filed under: Development

I’ve never programmed in Haskell, but have used Ocaml and SML and have had my programming style affected/improved by my exposure to functional programming.

This “Beautiful Code” example about a regex matcher in Haskell was very instructive, but I agree with one of the comments about variable name. Almost every example of Haskell I see uses mostly single character values a,b,n,m,x,y. Sometime they use two letters: xs ys. I know that Haskell comes from a mathematical background, but I believe that it’s widely accepted that good variable names make code easier to understand. head:tail instead of x:xs. Even car:cdr is slightly better. They do care about good function names, but don’t apply the same logic to variable names.

They apparently really program that way, look at the code in the standard prelude. Not all Haskell code is like this, the Hitchiker’s Guide for example. It’s almost like the old saying “it was hard to write, it should be hard to read”. I sort of believed that in the 80s when I was writing C code, and it took me a long time to get over it. Hey, *p++ = *s++ looked cool!

If you’re evangelizing, using good variable names make the code look better, and less scary. And maybe change a few more minds.

September 15, 2006

python has become my “native” language

Filed under: Software, Development

I’ve been programming for 25 years, a dozen different. In term of work done, I have to rank them as C, C++, Java, perl, lisp, python. However, when I start designing, the “pseudocode” turns out to be python. It allows me to start writing code immediately, because it seems to be at the same level of my thinking.

One of things I occasionally complain about it the slow progress of software versus hardware. Hardware speeds are about 5000 times faster (or more) since I’ve been using computers.

At the risk of being labelled a smug lisp weenie, I’m not sure if software has gotten even twice as easy. Java, which I’ve doing professionally for the last few years, really has just caught up with lisp and Smalltalk from the early 80’s. And it’s so much more wordy. I occasionally despair that I’m still telling computers exactly what to do, in detail.

Python seems to raise the interaction level up a bit. Maybe 3-4 times easier! And the syntax seems the most natural to me, the most like writing prose of any language. I’d always rationalized the parentheses in lisp, but there is definitely some distracting effort getting it right.

A little mental friction can really take you out of the zone.

April 13, 2005

What I think “Hackers and Painters” means

Filed under: Opinion, Development

Alan Knight points out a response to Paul Graham’s Hackers and Painters essay which corrects many facts from a painters point of view.

I’ve always understood that the point of the essay was that creative people will do what they love even if it doesn’t make them money. Many “famous painters” did their work even if offended their patrons, or if they weren’t getting paid. Does the fact that Van Gogh was a monetary failure devalue his art?

There are some people who will write code that doesn’t make them money. Witness many open source projects. Those who do this will mostly strive to do it better, just as its own reward. You can’t make bad programmers better by offering them more money. You need to find those who are doing it out of love, make sure their goals align with your, and let them go. Those who understand this will have a higher chance of success. Hackers don’t want to do the business side, but with compatible partners who love it can be a success.

It boils down to motivation. Do you love what you do? Why are you doing it? Would you do it anyway?

February 12, 2005

TDD: smalltalk comparsed with python

Filed under: Development

I was at
this meeting
, (I was sitting in the middle, literally and figuratively) and it prompted me to go back and look at python. I’ve been prototyping and playing with TDD in VisualWorks Smalltalk. I started to do the same thing with python as well to learn about python’s doctest module.

I’ve got the define a method in the debugger goodie loaded. You create the class, create the test case class, and start writing and running the tests.

The debugger pops up with a undefined method error. There’s a button to click that creates the method. You restart the method, and it immediately hits the breakpoint in the debugger created method. You can edit the method in the debugger, save it, and again restart the method. You keep going until the test passes. You write the next test case, and continue.

This is an incredibly smooth process. There are no mental mode switches to be made; it’s continuous programming mode. Wow!

Doctest in python is also very clever. Inside the comments of a class, or one of it’s methods, you add lines from a interactive python sesssion, showing input and expected output. See the documentation for more details.

You need to run the file with python to run all of the tests embedded in various comments. If all the tests pass, you don’t get any output. Running python requires a switch to a terminal window. Or a couple of keystrokes in emacs, which is much easier.

As long as the tests pass, everything is fine. If a test fails, you get a stack backtrace in the output. It took me a while to get used to it, but I soon got the knack of tracking the errors. It’s possible to get the errors to throw python into the debugger to make figuring out the problem easier. I hadn’t used the python debugger much, so I haven’t tried that yet.

Using python avoids the compile/link delay (which is long enough in C++ to let my mind completely away), which is good, but the thought process is interrupted enough to intrude on the smooth flow of smalltalk.

I’m still interested in using python, though. The pain of trying to convince management to use smalltalk is hard, and selling them on Cincom’s royalty pricing is damn near impossible. I enjoy the smalltalk language and environment very much. It’s made a great change to my thinking and programming styles. It’s a shame that circumstances make using smalltalk for "real work" just a fantasy for me.

If something useful comes out of my python code, it might be possible to ship it commercially.

February 2, 2005

trapped in a maze of twistly little license servers

Filed under: Development

One of the problems with shipping C++ libraries to a customer is the need to match compilers, even to the exact same version. We had been doing Solaris builds on an old Sparc-5. I’d been using using Solaris compiler 5.0 and other than the slowness, things were going fine. I’d been asking for a newer build machine, but it never came to top of the priority list . Then, it crashed. The disk was making a nice whining sound from the metal being scraped off.

As I was rebuilding on the new machine (hardware death is one way to get an upgrade), I found something odd. We had a license certificate from Sun for C++ 4.2. From 1999, I think. I couldn’t figure out how we were actually running 5.0. We had no certificate, and checking my download history at Sun (a very nice feature) , I couldn’t find anything. I did once download a demo license for Forte 6.0; maybe the license server got confused.

The older Sun licenses were bound to a specific host. I could move the 4.2 license to a new server via Sun’s license center, but I don’t think I can actually buy a 5..0 license. The oldest version of C++ that I can still dowload is Forte WS6U2, which is ironically too new to match the customer’s version. The actual compiler version number was 5.3.

I also downloaded Sun Studio 8, compiler version 5.5, which can be used for versions from now forward. However, it doesn’t want to be installed with any older version. Each compiler came with its own version of the licence server too. After installing a second compiler, it took lots of work to get the compiler, license, and license server in sync so that I could actually get the compiler to run.

Boy, I wish I could still use g++.

January 18, 2005

Infinite integers

Filed under: Development

One of the downsides of learning smalltalk is smalltalk envy. I need extended integer support in C++. We store floating point numbers to N decimal points by multiplying by 10 n+1 so that we can use only integer operations for speed. Actually, the only operations we perform are addition and a couple of divides near the end.

The problem is that sometimes the numbers get too big, and overflow. I can get a library to handle infinite integers, but with some overhead. I haven’t yet profiled any of my options, but the main thing my application does is add, so the impact could be large.

In smalltalk, I would use the fast SmallInteger type, which automatically would get promoted to Integer when overflow occurs. I avoid the extra overhead most of the time.

Most of the C++ libraries don’t seem to do that. One of them definitely does,  CLN by Bruno Haible. I think that it’s the number library for CLISP, so it’s well tested. It uses an int for as long as it can, and allocates space from the heap for larger numbers. I saw some other math libraries claim that it was the fastest, although I suspect that’s when it’s configured to use GMP. Both of these have acceptable licenses for commericial use.

At least I have a starting point.

January 12, 2005

I miss refactoring in Visual Studio C++

Filed under: Development

My bread and butter programming is in C++, but I’ve also spent a lot time with java in eclipse. I’ve had Martin Fowler’s Refactoring book for a long time, and I’ve followed the XP trail back to Smalltalk.

I’ve really learned to take advantage of the refactoring available in eclipse so that it feels completely natural. Now when I’m working in C++, it all seems so hard.

Just to rename a function parameter is such a pain. The software I’m maintaining was originally written by someone else, who seemed to have a fortran view of the world. I’ve improved most of the code by hand over time. Now that I’ve seen the refactoring rubicon, crossing back to the other side is painful.

I once renamed a variable by global replace, and broke the code in a subtle way that took lots of time to track down. This is one of the dangers of dealing with someone else’s code which has a lot of cut, paste and modify. Now I’m forced to rename the parameter in the function declaration, and try to compile. The compiler only warns me once about each undeclared variable, so I fix one use, and then compile again, in a long, slow, painful loop.

I have been writing negative lines of code for a long while as I’ve been improving, but every now and then I have to go into a virgin section of code to fix things, and the horror returns.


Get free blog up and running in minutes with Blogsome | Theme designs available here