Sam Dutton’s blog

Lots of dialog boxes in Windows that should be resizable, aren’t.

This is very annoying and completely unneccesary: it’s simple to write the code so dialogs are resizable.

How can this be so after decades of Windows development?

This is one of the world’s Great Interface Mysteries.

Here’s the dialog box that pops up when you edit environment variables in Windows.

The box isn’t resizable so you can’t see all the text without copying it and pasting it somewhere else.

D’oh!

Below is the same but different.

I’d like to be able to see all the commands containing the word show, but I can’t because the box isn’t resizable.

Double d’oh!

 

 

 

 

What is it about Find & Replace?

Noone seems to get it right.

Visual Studio 2005 is one of the worst culprits.

I guess the main problem is that as with so much Microsoft stuff, they seem caught between catering for beginner and expert – and wind up getting it wrong for both.

1. The box pops up the ‘9 occurrence(s) replaced.’ message in an oversized, separate window – but if you uncheck ‘Always show this message’, the confirmation message is displayed (miles away) on the window frame.

2. Those rather puzzling right-pointing buttons next to the text entry fields are disabled unless you use regular expressions or wildcards – but there’s no way to know that unless you’ve ticked the relevant box, which is hidden.

3. What the hell is ‘Quick Replace’ as opposed to ‘Replace’? Who cares?

4. There are effectively four dialog boxes in total: Quick Find, Quick Replace, Find in Files, Replace in Files. There could easily be just two, or even one.

5. Find & Replace in the HomeSite editor has a wonderful, simple feature: multi-line text fields. You can put line breaks in the find or replace text without scary stuff like regular expressions.

6. Anyway – pop-up boxes are annoying and slow – why not have a simple Find area in the window frame, as in Firefox?

Python is great.

I love it: numbers of arbitrary precision, dictionary keys of any type, easy file reading, stuff like random.sample(xrange(1000), 10)…

Fantastic!

But…   Python is being sold for the wrong reasons.

In particular, Python is (of all the languages in all the towns…) compared to C: the archetypal boring, old fashioned and difficult language.  I have a hunch that most of this comes from Python evangelists who endured a grim semester of C but never went on to use C — or rather C++ — in real life.

In reality, different languages are not as different as some people make out.

 

With Python, you don’t have to worry about memory

Well — sort of. Except that you *do* have to worry about memory, as with any language. Objects take memory. Worry about it.

The difficulties of memory handling in C/C++ are over-rated:
1. Noone uses malloc() and free any more, unless they’re making a mistake or doing something unusual.
2. Most (or many) C/C++ objects are (or should be) allocated on the stack, in the scope of a function — in practice, this is much like garbage collection in other languages.
3. Lots of C++ code is written using toolkits like Qt, which allocate and free memory for objects and their children created on the heap (i.e. with new) without leaks.

 

Dynamically typed languages are easier

Really?

They’re easier because you don’t have to type in those pesky words like int and double.

…but they’re harder if you’re trying to work out what the hell a long and complex method actually returns, or takes as an argument.

So — a little bit yes, a little bit no.

 

Python is flexible

Because typing is dynamic? Since did you need s to be ’spam’ one minute and 42 the next?

 

Python is terse

So what?

Did you ever look at a piece of old code and say ‘This is wonderfully terse!’

Far better to understand code than admire it.

 

Python is fun!

This is sort of true.

You get much more ‘bang for your buck’ in the first five minutes of learning Python than for lower-level languages: open(‘myfile’).read() can be pretty exciting if you’re used to file handling in C.

But once you’re up and running, the ‘niceness’ of a language doesn’t really matter. In fact, I sometimes think it doesn’t really matter what language you use: all that matters is how well you know the language and how well you use it.

 

Self is good, self is explicit

To me this is mystifying.

I think, again, it stems from developers trained academically in C, but unused to actually working with C++. Personally, I’d go nuts if I had to type in self every time I coded in C++. The idea that the self keyword removes ambiguity is daft. The C _private idiom is a much better alternative to avoid name clashes — and only very stupid C code has variables at global scope.
To my mind, self is just clutter — and as the first parameter of every method it’s annoying and confusing.
So there.

 

Python has loads of useful built-in types

Bring on the nasty null-terminated C character strings… Yuk. What a pain. Python strings are so easy! But who in their right minds (with some obvious caveats) uses C strings?

It seems that certain Pythonistas have never used the C++ Standard Library, let alone Boost or Qt or any of the other toolkits that are a normal part of C++ coding.

 

Python is instant: no need to compile! 

Well… sort of.

Except that you’ve still got  to wait for source code to be compiled into byte code.

In reality, recompiling a C++ program (if you haven’t changed header files) is not much slower than running the Python interpreter on a Python program.  My Pentium 4 running Visual Studio usually takes 5-30 seconds to recompile and run my (Qt GUI) app in debug mode. Even recompiling the whole program (25,000 lines or so) takes no more than a minute or two.

Bad C/C++ programs have lots of inter-dependencies that make recompilation slow. Good code use class decoupling and techniques like the PIMPL idiom to keep compilation fast, no matter how large the program.

In the end, it comes down to good code design: sensible idioms, pattern usage, and all the rest. Same for Python, C, C++ and every other language.