How does the book compare with the standard Tcl/Tk book, Practical Programming in Tcl/Tk
(2nd edition)?
I own both books. I find the Welch book to be a very good primer on using the language. McClennan/Harrison is a good book once you are up to speed on the basics. It covers a set of best practices from some guys who have written a lot of tcl code and in the process developed a set of useful techniques for Tcl programmers.
TCL uses nul-termination for all strings. This eliminates any possible use of binary data.
No longer true as of tcl v8.0
TCL stores numbers as numbers only within an "expr" statement. The return value of the expr is a string, and the parameters to it are strings, so you have to be able to do all of your math within a single expr for it to be fast.
I'm not a professional programmer myself (whatever you define that to be), but the tone of your comment suggests a lack of familiarity with perl or emacs.
Perl is in fact a good scripting language, but the scope of scripting is much larger than you think, which could explain your disdain for its OO features. Scripting languages are often used to write rather large (100,000+ line) applications. OO provides features for complexity management that become very useful when applications reach that size. Also consider that other popular scripting languages (including Python and Tcl (through the [incr tcl] extension) provide OO structure. Scripting does not just refer to 20 line bourne shell scripts that pipe run a couple of useful binary apps together.
As for emacs, I'll first note that I am an avid user of emacs and I disagree with your perspective of it. Emacs was not written to be "user-friendly" text editor. It is more an extremely extensible text editing environment. Flexibility appears to be much more a design criterion than short learning curve. I agree that emacs has a high learning curve to comprehend all the features, but the effort spent familiarizing yourself with operating it reaps many benefits. I found that once I got over the hump of learning a large portion of the commands in emacs that I could work very productively. Human-Computer Interface issues experts have shown (sorry, I have no references) that human motor memory works much better using a keyboard than using a mouse -- try hitting a menubutton without looking at your screen.Memorization of key commands makes one much more productive because you rely less on screen feedback to execute commands. Perhaps the difference could be compared to that between having to stare at the keyboard and type with one finger and being a touch typist. Learning how to touch type takes some time, but the benefits are grand.
As for useability, I'm not sure what version of emacs you have used, but the versions I use (both Xemacs and emacs) have pull-down menus. I've always preferred a program with menus that allow me to learn to use the application. Over time I memorize the key commands and forsake use of menus any longer. I would also note that, at least on unix, that emacs motion and editing key commands are rather pervasive; they work in applications such as Netscape, FrameMaker, and any tcl/tk based gui application. I'm not sure you could call them standard, but they can be found many places.
Linus is a hacker L0pht is a lamer, i mean, a cracker
I have to admit I find it pretty ironic that an Anonymous Coward is calling the L0pht a lamer. For starters, the L0pht is an organization, not a single person (which could be a simple grammar thing, but just to clarify). In addition, I would hardly classify as crackers an organization who, among other things, find security holes in supposedly "safe" software, then proceed to expose said holes through public Security Advisories. As far as I'm concerned, their work is a great service to the public (ie, I'd rather have them find holes in major software than others). Take a look at their page for more info.
People would be much better off using a language such as Dylan, Smalltalk, or Eiffel that were well thought out.
Contrary to the above statement, C++ was in fact very well thought out. If you feel differently, I suggest reading The Design and Evolution of C++.
Given the set of design goals Stroustroup sought to meet and the tradeoffs he needed to consider in designing c++, I would say he did a very good job.
As for Dylan, Smalltalk, Eiffel, Java, etc, a major issue to take into consideration is that none of these were designed with backward compatibility to C as a constraint. Freedom from this is part of what makes Java a "safer" language to program in.
Someone else mentioned that C++ is like multiple languages wrapped up into one. Well...it is. As I understand, Stroustroup seems to believe that programming need not follow only one paradigm. C++ supports multiple forms of programming, including Abstract Data Types, Object Oriented Programming (there's a difference between the two!), and Generic Programming (through templates). And that's not to mention C, which is also encapsulated in C++ (remember, every program in Kernighan and Ritchie is a C++ program).
Even when I program in C-style, I still tend to program in C++ insofar as I use c++ style comments and I prefer to declare variables close to where they are used (given a large program, this increases my comprehension). Not to mention I prefer C++ strong typing to ensure my code uses the correct parameters.
Slashdot Mirror
I own both books. I find the Welch book to be a very good primer on using the language. McClennan/Harrison is a good book once you are up to speed on the basics. It covers a set of best practices from some guys who have written a lot of tcl code and in the process developed a set of useful techniques for Tcl programmers.
No longer true as of tcl v8.0
same as above.
I'm not a professional programmer myself (whatever you define that to
be), but the tone of your comment suggests a lack of familiarity with
perl or emacs.
Perl is in fact a good scripting language, but the scope of
scripting is much larger than you think, which could explain your
disdain for its OO features. Scripting languages are often used to
write rather large (100,000+ line) applications. OO provides features
for complexity management that become very useful when applications
reach that size. Also consider that other popular scripting languages
(including Python and Tcl (through the [incr tcl] extension) provide
OO structure. Scripting does not just refer to 20 line bourne shell
scripts that pipe run a couple of useful binary apps together.
As for emacs, I'll first note that I am an avid user of emacs and I
disagree with your perspective of it. Emacs was not written to be
"user-friendly" text editor. It is more an extremely extensible text
editing environment. Flexibility appears to be much more a design
criterion than short learning curve. I agree that emacs has a high
learning curve to comprehend all the features, but the effort spent
familiarizing yourself with operating it reaps many benefits. I found
that once I got over the hump of learning a large portion of the
commands in emacs that I could work very productively. Human-Computer
Interface issues experts have shown (sorry, I have no references) that
human motor memory works much better using a keyboard than using a
mouse -- try hitting a menubutton without looking at your
screen.Memorization of key commands makes one much more productive
because you rely less on screen feedback to execute commands. Perhaps
the difference could be compared to that between having to stare at
the keyboard and type with one finger and being a touch typist.
Learning how to touch type takes some time, but the benefits are
grand.
As for useability, I'm not sure what version of emacs you have used,
but the versions I use (both Xemacs and emacs) have pull-down menus.
I've always preferred a program with menus that allow me to learn to
use the application. Over time I memorize the key commands and
forsake use of menus any longer. I would also note that, at least on
unix, that emacs motion and editing key commands are rather pervasive;
they work in applications such as Netscape, FrameMaker, and any tcl/tk
based gui application. I'm not sure you could call them standard,
but they can be found many places.
I have to admit I find it pretty ironic that an Anonymous Coward is calling the L0pht a lamer. For starters, the L0pht is an organization, not a single person (which could be a simple grammar thing, but just to clarify).
In addition, I would hardly classify as crackers an organization who, among other things, find security holes in supposedly "safe" software, then proceed to expose said holes through public Security Advisories. As far as I'm concerned, their work is a great service to the public (ie, I'd rather have them find holes in major software than others). Take a look at their page for more info.
Contrary to the above statement, C++ was in fact very well thought out. If you feel differently, I suggest reading The Design and Evolution of C++.
Given the set of design goals Stroustroup sought to meet and the tradeoffs he needed to consider in designing c++, I would say he did a very good job.
As for Dylan, Smalltalk, Eiffel, Java, etc, a major issue to take into consideration is that none of these were designed with backward compatibility to C as a constraint. Freedom from this is part of what makes Java a "safer" language to program in.
Someone else mentioned that C++ is like multiple languages wrapped up into one. Well...it is. As I understand, Stroustroup seems to believe that programming need not follow only one paradigm. C++ supports multiple forms of programming, including Abstract Data Types, Object Oriented Programming (there's a difference between the two!), and Generic Programming (through templates). And that's not to mention C, which is also encapsulated in C++ (remember, every program in Kernighan and Ritchie is a C++ program).
Even when I program in C-style, I still tend to program in C++ insofar as I use c++ style comments and I prefer to declare variables close to where they are used (given a large program, this increases my comprehension). Not to mention I prefer C++ strong typing to ensure my code uses the correct parameters.