Tag Archives: Programming

Languages

Programming Languages Home

You tend to find two things relating to programming languages on the Internet. The first is a long list of all the languages, often with links to a representative web site. The second category are the “representative” web sites, detailed descriptions of a particular language.

I hope to make this part of ZX81.org.uk to be the middle-ground. I won’t cover every language ever designed and nor will I cover them in vast amounts of detail. Instead I’ll look at each languages main features, advantages and flaws.

What makes me qualified to write these critiques? Well, I’ve used all of the languages covered so far on at least one non-trivial project and at university I did a lot of programming language design and compiler development courses.

The two languages I’ve covered so far are the major Unix stalwarts Perl and C.

Opinion

Software Project Survival Guide

Introduction

For many people here, writing software is, if not a job, then a hobby. Our enthusiasm is a double-edged sword. Our technical knowledge is usually much greater than people who just develop software for a living. This sounds like a big advantage, but it’s not as large as you would have thought.

Let’s have a look in ‘Software Project Survival Guide’ (SPSG) to see what Steve McConnell, famed author of ‘Code Complete’ and ‘Rapid Development,’ has to say on the subject.

The most relevant bit I can find is in chapter two. It’s a project survival test. Out of thirty-three questions, only one (28: “Does the project team have all the technical expertise needed to complete the project?”) is directly related to our ability to effectively code.

That can’t be right, can it?

Content

While you’re still reeling over the consequences of that last paragraph, I’ll slip in some of the dull things that the book has to cover and finish with some of the more glamorous stuff at the end when you’re brain is back in gear.

Some of the most important stuff is ‘management.’ Whether it’s planning, quality assurance, tracking what’s been developed so far or checking on the number of defects, it’s not the ‘techies’ that are the most important.

At first this comes as a shock, but the more you think about it, the more it makes sense. Unless you know what’s going wrong, you can’t fix it. Unless the complete design is documented a team can’t effectively write the software quickly.

Think about Linux kernel development. It obviously work well, but it’s not terribly optimal. The same bug might get fixed several times and there’s not a huge amount of up to date documentation so people have to dive in at the code. For free software this works fine — since the time is usually free, but if you have deadlines and are under contract to deliver a working product on time you’re going to lose a lot of money.

Good bits

McConnell takes the three hundred pages to explain these past two paragraphs in detail. It sounds very dull, but he has a clear, friendly style that makes it, if not entertaining, then not as dull as it might have been.

He splits the project into stages, explains in broad terms what they are and documents each one in more detail in the later chapters. It’s all very clear and logical leaving you in no doubt what stage you’re currently at and what you should be doing for the successful execution of it.

Bad bits

‘Code Complete’ is a book that just about everyone that writes computer programs should read. ‘Software Project Survival Guide’ does not fall into the same category. The book should be read by “anyone who has a stake in a software project’s outcome” according to the preface, but that is only accurate once you define the type of project it covers.

To cut a long story short, if you write software professionally you should read it. It’s probably more use to managers and team leaders, but you can be a better developer if you know the kind of things that need to be done. Besides, almost everyone will be in charge of people at one point and will need a broader picture than merely what the other modules do. (Well where I work that’s true, anyway.)

It covers projects that have a customer whether that’s an internal customer, an external client or people that buy shrink-wrapped software. What it doesn’t cover are software projects like Linux, massive sprawling projects developed because someone is interested in doing it. This is not unreasonable. Half the challenge in a ‘normal’ project is tracking whether you’re running to schedule. If you don’t have a schedule and cost target it doesn’t matter. However, maybe we could take a few hints from the book to ‘streamline’ the process.

Overall

Steve McConnell has done it again. I don’t think that it will go down as a classic like ‘Code Complete,’ but SPSG is an indispensable book for any developer that has any interest in the process and not just lines of code.

The facts

Author: Steve McConnell

Cost: ?22.49

ISBN: 1-57231-621-7

Buy this book from Amazon.com of from Amazon.co.uk.

Opinion

Open Sources

Introduction

This is a very strange book by almost any criteria. Firstly, much of the content is available on the web in one form or another. This includes an appendix which is literally a Usenet discussion printed. Secondly, most of the writers are techies first and writers second. You don’t get that kind of admission from most writers, even when it’s obviously true.

Content

There are fifteen essays by eighteen writers. I’m not going to go through all of them, but I shall note some of the highlights.

The style prize, without doubt, goes to Larry Wall for ‘Diligence, Patience, and Humility.’ It’s one of the longer essays, has dozens of useless-looking diagrams and for much of the time seems to go nowhere. You keep reading, though. You may not see where it’s going, but you’re intrigued. And it’s worth it — despite initial appearances, it does go somewhere!

As a Linux-biased web site, I couldn’t miss out Linus Torvalds piece, ‘The Linux Edge.’ His simple message — Linux has survived by having a good design — is thoroughly investigated, but the best bit is that he criticises just about everyone else in the industry, often without much justification, and still comes out the other end smelling of roses! I’m not sure how he did it, but I know I’d hate Bill Gates more if he said pretty much the same things.

As always he comes across as very modest, and attributes many of the good ideas to other people.

I liked Marshall Kirk McKusick’s potted history of Unix too. I think I’ve seen much of that before, but not in one place.

Since he practically started the whole thing, I need to mention Richard Stallmans ‘The GNU Operating System and the Free Software Movement.’ It’s an interesting piece in that he contradicts some of what the other authors in the book have to say (as has been well documented, he dislikes that phrase ‘Open Source’ and demands that people call it ‘free’ software). It’s clear that he knows exactly what he wants and where he wants to go, but it’s equally clear that he’s going to put a lot of businesses off free software if he keeps going the way he is. RMS, I respect what you’re saying, but calm down!

The final mention goes to the two Eric Raymond essays. Raymond has been at the centre of the Open Source movement since the Cathedral and the Bazaar,’ and fully deserves the opportunity to write two pieces in Open Sources. The first piece ‘A Brief History of Hackerdom,’ describes the key points and people that gave rise to our current position. The second, ‘The Revenge of the Hackers,’ looks to the future.

Like much Raymond stuff, some is ‘personal’ and has a number of anecdotes about himself. It seems that many people hate this, but I feel that where it doesn’t get in the way of the message and while it’s still interesting and well written, it’s fine. The two essays are, indeed, fine.

Overall

I can’t really criticise this book. All the people in it are more influential than myself, better developers than myself, better writers than myself or, more commonly, all of the above. So while I like some of the writer more than others, and while I actually disagree with some of the assertions made, it is, at least, well written and thought provoking.

As a book intended to document the new-found popularity of the Open Source model, the book is a classic and a must-buy.

The facts

Author: Edited by Chris DiBona, Sam Ockman and Mark Stone

Cost: US$24.95

ISBN: 1-56592-582-3

Buy this book from Amazon.com or from Amazon.co.uk.

Opinion

Engineer or Hacker?

Eric Raymond would have us believe that everyone that develops software for fun is a hacker. I know that historically this has always been the case, but that doesn’t necessarily make it the right thing. All good, and bad, things come to an end.

I doubt that it will happen any time soon, but I think that ‘hacker’ is a term that should whither and die.

The first problem, and this is the obvious one, is the public perception of it. Yes we all know that hackers write code while crackers break into computer systems, but how many people ‘outside’ know that? How many professional software developers, i.e., those who do it just for a living rather than for fun, know that?

If even professionals don’t know the difference, how can the rest of the population have a chance?

Of course there’s always the fanatical wing, those that claim that we should hit the problem face-on. We should call ourselves hackers because we know that we’re right and that everyone else is wrong.

It’s actually a very politically correct way of doing things, but I remain unconvinced that it works. Richard Stallman continues to insist on the term ‘free software,’ even though most people find it more confusing than ‘Open Source.’ None of this is about changing ideals or opinions, it’s just about the correct marketing of the term.

The second problem I identified is much more subtle. What does the term ‘hacker’ mean? My dictionary defines it as follows:

hack‘ vt cut, chop (at) violently;

It goes on, but that’s the important part. My objection comes from the lack of precision that the term implies. You get a program and violently cut and chop it around until, by chance, you get something out at the end that seems to work okay.

I hope you don’t develop software like that, I certainly don’t. Any half-decent developer follows a process, no matter how ill-documented. When you debug software you don’t just dive in adding ‘print’ statements all over the place, guessing where it goes wrong. Instead you make a hypothesis and test, modifying your original until you get a good idea what’s wrong, then you start with the ‘print’ commands or your debugger.

Does that sound uncontrolled and violent?

All that planning and precision, all the experience that it takes to be able to make a reasonable and accurate hypothesis sounds more like engineering of some kind.

And that it why I call myself a Software Engineer rather than a hacker, even when I write code in my spare time.

Opinion

Oracle Builtin Packages

Introduction
Steven Feuerstein’s ‘Oracle PL/SQL Programming‘ book has, over the last couple of years, become my bible on the subject of writing sizable Oracle PL/SQL programs. As I said in my review, it’s useful because it covers just about everything, including the things that don’t work.

So if that book covers just about everything, why would anyone want to buy ‘Oracle Builtin Packages’?

Content

In fact, as the first chapter of the book explains, this entire book was origianlly chapter 15 of ‘PL/SQL Programming’ but Oracle complicated things by adding more to the PL/SQL programming language (all the pseudo-object oriented stuff in version 8 ) and many more new or enhanced packages. The result: either a single two thousand page monster, or two more reasonably sized tomes.

But like the first book, this is still a bit of a monster in its own right. It stands at 931 pages and there’s very little padding; if only all technical books had such a high signal-to-noise ratio!

It seems rather pointless to go into detail on the content of all the different sections…

The two chapters that I’ve used the most are those on DBMS_FILE, which allows you to manipulate operating system files, and DBMS_SQL. Just about everything I know about these modules I learned from this book. When I was originally writing the code, ‘Oracle Builtin Packages’ was by my side, open at the relevant page. When colleagues mistakenly thought I knew what I was talking about, this book was open beneath my desk giving me superiour bluffing ability.

The main critisism that I can think of is that some of the material is getting rather out of date. The DBMS_SQL package is no longer as necesary as it used to be — Oracle 8i introduced some new syntax to the PL/SQL language that largely replaces it.

Conclusion

I’ll be brutal: in marked contrast to Feuerstein’s first book, if you regularly write PL/SQL code you can get by without reading this book.

But you will be more productive if you get it. You won’t be spending days writing code to do things that Oracle have kindly supplied a routine to do and you won’t give up on PL/SQL and write a program in Pro*C because you don’t realise, for example, that you can manipulate files.

No, this book is less vital than ‘Oracle PL/SQL Programming’ but it is still a thorough, well organised and useful book. It’ll quickly pay for itself many times over, and that’s a very high recommendation.

The facts

Author: Steven Feuerstein, Charles Dye, John Beresniewicz

Cost: US$46.95

ISBN: 1-56592-375-8

The Penguin Says

NEdit 5.02

3 Comments

Introduction

The bottom line is this: I’m lazy. At work I chop and change environments every few months. I usually manage to use Windows NT as my client OS. Then at the server end there’s Solaris or HP-UX. And then I go home and have Linux and Windows 95 to play with.

It gets confusing after a while. Emacs doesn’t think very much of me pressing ESCAPE-k-k-k-a when I try and put something at the end of the third line up. And Notepad is unimpressed with ^X^C when I try and quit.

No, what I needed was some consistency. ^C to cut and ^Z to undo, please and thank you.

And then out of no-where, NEdit appeared. (In all probability, it was Freshmeat, but you get the idea.)

What’s it do?

More than Vi and less than Emacs.

NEdit sit in the middle ground doing just about everything that most people want to do. It doesn’t check your mail, it doesn’t let you surf the net. But it does help you edit your text.

It will high-light the syntax of your program, and if it doesn’t know about the language that you’re using you can tell it. (I added most of PL/SQL.) It uses most of the conventions that you’ve got used to in Windows and the Mac — like ^Z to undo ^N to start a new document. I still sometime press escape at the end of a paragraph, but that’s just me being brain-washed into the ways of Vi at an early age.

To appease ‘normal’ Unix people, it is also scriptable. There’s a macro language and you can call programs from the ‘Shell’ menu. The macro language is nothing like Emacs, but does support functions and variables and seems to be able to do all the basic stuff and some of the more complex things that people want to do. (I’ve not had need to look at it in any detail, the truth be known.)

While we’re talking about configuring it, NEdit is very strong in this area. It is a little confusing at first — the obvious menu items refer to this session of NEdit rather than NEdit as a whole — but once you’ve lost all your settings a couple of times everything become clear! You can change just about any aspect of the program, from the font, it’s colour and size, through to the size of a tab character. And none of this requires the editing of a text file — it’s all menu based.

It’s all a bit too user-friendly to be a real Unix application, but I’m not complaining.

What’s wrong with it?

I’ve been using NEdit on and off for nearly six months now. I’ve used it to edit HTML, C, shell scripts, plain text, Perl and various configuration files, and there’s nothing that jumps up at me and says ‘that’s wrong!’

Okay, the help could do with being more Window-ish, but then it’s not something you have to use very much. There are some languages that don’t have syntax high-lighting built in (SQL and PL/SQL are the ones that immediately spring to mind), however there is a huge list there so I’ve probably just been unlucky — and I can add them myself if I want.

NEdit is supplied as two executables. The main one, nedit, does exactly what you’d expect. There is a second one called nc which is slightly confusing. As I understand it you should use nc most of the time. What it does it open the document with an existing copy of NEdit if there is one, and starts one if there isn’t. This is a useful feature, but I don’t understand why it couldn’t have been included as part of the main executable.

Finally, and this probably just the executable that I picked up rather than any of the author’s faults, the executables were not ‘stripped’ (meaning that it was over 200K bigger than need be). Still, it was easy to fix and it only comes in at around 2Mb, anyway (presumably with Motif libraries linked in).

Verdict

NEdit is a class application. It brings a simple to use, yet powerful editor to Unix. Since Emacs and Vi — incredibly powerful but ridiculously complex and user-hostile — still seem to be the most popular editors, this is something we need to bring Linux to the masses.