From rfunk Wed Jan 27 11:08:52 1999 Subject: Re: [COLUG] Language Comparison In-Reply-To: <> from Keith Ward at "Jan 26, 99 09:22:37 pm" To: Date: Wed, 27 Jan 1999 11:08:52 -0500 (EST) Keith Ward wrote: > My main concern was over >the language de'jour (python, tcl,tk, java, etc.) since a new one >seems to pop up every so often. Are these new languages really that >much better then the ones used to write them (C/C++)? It all depends on what you're doing. Those languages let you ignore a lot of the low-level things like memory allocation and release, and make it much easier to do some things. On the other hand, you get less speed and control than it C (and maybe C++, but again, don't lump the two together). I disagree with those who say that all of Java's power is in its cross-platform abilities. The language itself (along with standard class libraries) is much nicer than C++. The cross-platform ability often makes it the language of choice, but also makes it almost always slower than C++ (unless you compile it to native code). A couple years ago I was writing a bunch of Perl, but something came along that required C. It was somewhat like going from C to assembly -- I had to build my usual functions from scratch. If you have lots of string processing to do, Perl is excellent; I often use it for mail-processing tools. Majordomo mailing list software is written in Perl, for example.
From Wed Jan 27 19:04:16 1999 From: Rob Funk <> Date: Tue, 26 Jan 1999 23:45:46 -0500 To: Subject: Re: [COLUG] Language Comparison References: <> <> In-Reply-To: <>; from Mark Nielsen on Tue, Jan 26, 1999 at 07:58:28PM -0500 There are entire classes that teach the technical and theoretical differences between various languages.... I'll try to give a practical answer.... Mark Nielsen wrote: >C/C++ is the 90's version of assembler. If you are a good programmer in >C/C++, you can throw away any other programming language. Not quite.... First, C and C++ are two different languages with similar syntax, that are good for very different purposes. C is good for Unix systems programming and similar low-level work, where it helps to know what's really going on. It's also the best language to write object libraries (for Unix) in, since pretty much everything can link to C libraries. C programs tend to be quite fast, since you're specifying (almost) every little thing that happens. It's true that C is used most places assembler was once used, but there are still a few things that require assembler. C++ is better for high-level applications, where you want to concentrate on manipulating high-level data rather than focusing on what's happening to individual bytes and words. Unlike C, C++ hides a large amount of what's happening to the data; one effect of this is that it's easier to write slow code without realizing it in C++. It tends to produce larger binaries than C, and it's difficult or impossible to link C++ with anything compiled with a different C++ compiler, let alone a compiler for a different language (such as C). Though almost anything *could* be done in C or C++, it's important to realize that there may be a better language for the job. Fortran is much better for numeric processing; Perl (or maybe even COBOL) is more suited for string processing; assembly is better for making sure a small routine runs as fast as possible. I see the Java language as a better C++. C++ is much too complex; Java takes the same concepts and streamlines it all into something more reasonable. I'd like to see more compilers take Java to native machine code, so I wouldn't have to deal with C++ so much. (Java is still much more complex than C though.) The portability aspects of Java still need work; I haven't seen it work very reliably yet, but there is potential. >Perl is a kick-ass programming language, that is very powerful and >user-friendly (considering how much power it has) that if you don't care >about it being slower than a compiled c program, is fantastic. Perl is extremely useful (the "Swiss Army Chainsaw" of programming), especially if you're familiar with both C programming and Unix shell scripting. The syntax is mostly like C, with some shell scripting (including awk and sed) constructs thrown in. It's extremely flexible ("There's more than one way to do it" is a Perl mantra), which is also one major disadvantage: it's extremely easy to write unmanagable Perl code. Also, every perl script loads the entire (huge) perl "interpreter" into memory. Perl does take longer to start than equivalent C code, but after the initial startup it actually approaches C's speed, since the startup time is a sort of runtime compilation phase. Perl is very good for prototyping something that may eventually be rewritten in C, since it can do pretty much any function C can (and more), either on its own or with an add-in module. It's also good for when a shell script gets too big and unwieldy. As my programs grow and develop, they tend to start in Bourne shell, migrate to Perl, then eventually to C. If I get better at C++ that might come next. >Python -- I don't know, heard many good things about. Python is starting to replace both Perl and Tcl in many places, because it is much more structured than both, and it is designed from the start to be object-oriented. (Perl had OO tacked on in version 5.) Like Tcl, it usually comes with an interface to the Tk GUI toolkit, so it's quite easy to make GUI programs. Like Tcl, Python was intended to be embedded in applications. >Tcl/Tk -- an easy language to learn to make GUI programs. If you know > Perl, you might as well learn PerlTk. Since Perl is now > compilable, write your GUIs in PerlTk and compile them. Tcl and Tk are not the same; they come from the same source, and Tcl usually comes with an interface to Tk, but talking about PerlTK doesn't say anything about the Tcl language (or the Tcl/Tk team). (Perl and Python both have Tk interfaces available, but unlike Tcl and Python, tkperl isn't part of the usual standard perl package.) Tcl is basically a scripting language comparable to the shells, but more powerful. (Note that SCO Unix uses Tcl scripts where everybody else uses Bourne shell scripts.) Like the shells, it is line-oriented and string-oriented; all variables are passed by string substitution. Its best feature (other than the easy Tk link) is probably the ability to substitute the output (or value) of one command into the argument of another. The shells can do this with backquotes, but Tcl's syntax allows it to be nested deeper, the way Lisp and Scheme do it. Tcl was intended to be embedded in other programs, as a scripting language for an application. It was not intended for standalone scripts. >SQL - database language for many database servers. Standard Query Language, usually embedded inside another language that runs on the client. >COBAL, Fortran, Pascal, Modula, --- many scary languages, good for >specific tasks, used by many academic people for god knows what. COBOL is generally used in the business world, particularly on mainframes, for traditional data processing tasks like payroll. It has good database-style abilities. It was designed to look "friendly" to a business person, but that makes it extremely verbose and ugly. Fortran is THE dominant number-crunching language. Used in many a scientific lab. No other general-purpose language is as good at manipulating numbers. (Things like Matlab are not general purpose.) Pascal was originally intended to be a language to teach programming, particularly structured programming (subroutines, functions, while loops, if clauses, no goto). The language doesn't give access to many system resources, though particular compilers have extensions to make it more useful. Generally major projects aren't written in Pascal, but TeX is the canonical exception. Pascal is not dead -- Borland's Delphi is Pascal with a GUI interface. Modula, Modula-2, and Modula-3 are mostly teaching languages based on Pascal, but each adds interesting language features. The basic distinguishing feature over Pascal is the ability to load modules to add functionality; we generally take this for granted these days. I think Modula-3 is being used for some major real-world project. >Visual Basic -- a f**cked up attempt my MS to make programs easily using a >GUI interface. Much better interfaces (like Delphi, I heard) exist that >blows Visual Basic away, but people don't buy them because "everyone uses >VB". Truly, I know from experts who program in VB and even an author of a >book on VB, who claim VB isn't worth it anymore. The VB language also doesn't have much in common with the BASIC of 20 years ago -- it took the structured programming idea and embraced it, leaving little resemblance to the BASIC that I grew up with. I know C, Perl, Unix shells, and old-style BASIC well; C++, Java, Modula-2, Pascal, Fortran, and Tcl somewhat; and the rest I've only seen and read about. I think it's important for Unix hackers to know Bourne and C shells, C, and Perl. Tcl, C++, Java, Python, and Fortran would be of secondary importance (in approximately that order).
From rfunk Wed Jan 27 12:19:29 1999 Subject: Re: [COLUG] Language Comparison In-Reply-To: <> from Keith Ward at "Jan 26, 99 09:22:37 pm" To: Date: Wed, 27 Jan 1999 12:19:29 -0500 (EST) Most of the modern language sites include comparisons with their "rivals": ("by people biased in various directions") (pretty biased toward Perl) There are some relevant articles listed at:
From rfunk Wed May 19 19:45:15 1999 Subject: Re: [COLUG] TCL/TK In-Reply-To: <> from Curtis Smith at "May 19, 99 11:03:42 pm" To: Date: Wed, 19 May 1999 19:45:15 -0400 (EDT) Curtis Smith wrote: >does anyone script in TCL? what is it good for? is it easy to learn, >use? i've read that it good for irc bots. can it be used as a cgi >scripting language? I use tcl/tk occasionally for small utilities that need a GUI, since it's the most commonly installed GUI scripting language in the wider Unix world (python/TkInter and perltk are not nearly as common, though python is catching up). See my "tktips" program for an example. Writing tcl is basically like writing a shell script, but more powerful and therefore a bit more complex. Like a shell script, things can quickly get out of control, at which point it's time to reimplement all or part of it in a language more suitable for larger projects. SCO Unix (at least the release I once had the misfortune of working on) uses tcl for almost all its scripting needs, where everybody else uses shell scripts. I think this is a huge mistake and makes SCO horrible to work with at that level. Tcl shines in combination with other things -- most commonly with tk for graphics, but another significant example is Expect for talking to other programs. Some applications programs use tcl as a scripting language, somewhat equivalent to Microsoft's Visual Basic for Applications. (Other applications programs (mostly GNU-related) prefer using guile for this purpose, and Richard Stallman once wrote an essay on why tcl is bad for embedded scripting, tcl's original target use. I haven't done enough in that area or with tcl or guile to comment on whether I agree with him or not.) Any language that gives access to environment variables, file I/O, stdin/stdout, and command-line arguments can be used as a CGI scripting language. Tcl is probably equivalent to bash for this purpose. >i'm just trying to decide if its worth the time to learn. It's definitely worth learning ("if you have to ask if a programming language is worth learning, the answer is probably yes." -- me, just now), but like any language you need to keep in mind its strengths and weaknesses. Reading Ousterhout's notes on tcl's original purpose is instructive. There are many shops that use tcl almost exclusively; Chem Abstracts is one of them, at least the area where I interviewed a few years ago. (I wrote a longer message to colug about the pros and cons of various languages du jour a while back (January?).)