|
Post by JayUtah on Apr 12, 2007 11:51:12 GMT -4
Java sucks. C sucks. Fortran sucks. Perl sucks. Python sucks. Long live REXX!
Discuss.
|
|
|
Post by BertL on Apr 12, 2007 11:58:41 GMT -4
I think HTML still rocks.
|
|
|
Post by JayUtah on Apr 12, 2007 12:01:19 GMT -4
It does, but HTML is a markup language, not programming language. It would be difficult to express an algorithm in HTML.
|
|
|
Post by LunarOrbit on Apr 12, 2007 12:12:01 GMT -4
Does PHP count?
I did a bit of BASIC programming with my dad's Commodore 64 when I was a kid, but nothing fancy. Learned Turing, Turbo Pascal, and a bit of C in high school. Taught my self the basics of Visual Basic after high school and then learned a bit more in college. But the majority of my programming is PHP. I see enough similarities between that and VB and C++ that I could probably do something with them... if I could afford to buy the compilers.
|
|
|
Post by petereldergill on Apr 12, 2007 12:21:42 GMT -4
Jay, is this the first thread you've ever started? I've never seen you start one before!
Pete
|
|
|
Post by Joe Durnavich on Apr 12, 2007 12:30:32 GMT -4
|
|
|
Post by wingerii on Apr 12, 2007 12:33:58 GMT -4
There was quite an uproar (well, in the Slashdot comments, at any rate) when my department "sold out" to Microsoft and required that all first-year electrical and computer engineering students use C# instead of C++ in their introductory OOP course. The question is, if we sold out to Microsoft, why didn't the professors do a better job of trying to sell the language to us? "...because of their differences, half of programmers now hated C++, and the other half hated Java, so Microsoft decided to put them together, thinking, 'hey, here's something everyone can hate!', and thus C# was born." -- My ECE150 professor
|
|
|
Post by JayUtah on Apr 12, 2007 12:50:12 GMT -4
I don't think I've started a thread in this section before; I might have started one in the Apollo hoax section.
PHP most certainly counts. It's the workhorse of web presentation layers. One could argue that PHP is what Perl should have been if it had been designed properly.
Since my expertise straddles engineering and computer science, I believe I have an uncommon perspective. I've learned probably half a dozen compiled languages and probably another half dozen interpreted languages. I find strengths and weaknesses in all of them according to criteria ranging from the design of the language itself to the ease with which each fits its intended niche.
Compiled languages I use or have used include: Fortran, Ada, PL/I, C, C++, Pascal, Modula 2, and Java (arguably compiled). Also a smattering of assembler for various architectures both obscure and common.
Interpreted languages include various dialects of Basic, REXX, all the Unix shells, JCL (now there's a Sherman's march through anyone's brain), Perl, Python, two or three dialects of Lisp, Prolog, Scheme, APL, and PHP.
I tend to believe that one should use the right tool for the right task. But "right tool" can include lots of criteria such as the proficiencies of the person you assign to the task. If someone is a Perl whiz and the task could be done equally well in Perl or PHP, then let him work in the language with which he's most comfortable. But if the task lends itself especially to a high-level interpreted text-processing language, and your programmer perfers to work in Fortran, then that's perhaps less desirable.
|
|
|
Post by JayUtah on Apr 12, 2007 13:07:26 GMT -4
For every language I know, I can make a fairly balanced Love and Hate list for it. And some of that branches out into characteristics of the people who prefer that language and problems that language has been assigned to solve.
Java doesn't irritate me, but Java evangelists sure do. For some reason, some people who prefer Java want it to be not only a good and useful language, but the One True Language. That seems immature to me, and I have seen a lot of Java-only applications go down in flames not because Java is a bad language or because the programmers lacked skill, but because Java was simply not the right choice of language to solve the problem.
One thing Java got very right was runtime access to first-class types. That is the advantage that a pseudocompiled language gives over a purely-compiled language. You can define a class in Java, create an object of that class, and then programmatically and polymorphically create and walk a descriptor of that object to have sequential access to its members. That makes distributed objects a snap and properly entrenches Java in the distributed application market.
One thing Java got very wrong was the everything-is-a-class philosophy. It was introduced when object-oriented programming was being hailed as the cure for all design ills, a view today seen as less promising. But Java is now stuck with it. That choice has a number of consequences: deep and mysterious class hierarchies, a rocky distinction between classes and integral/atomic types, some violations of polymorphism and symmetry, and the mispackaging into classes of functionality that more properly belongs to modules.
|
|
|
Post by LunarOrbit on Apr 12, 2007 13:14:16 GMT -4
I could find this out by looking at the link I guess, but is it limited in any way? When I took a programming course in college we were given a free edition of VB but it wouldn't compile stand alone programs, they would only run in VB. Either way I will probably give Visual Studio Express a try... I often get the itch to do some programming.
|
|
|
Post by JayUtah on Apr 12, 2007 13:35:28 GMT -4
Perl is one of those languages that sort of congealed around a specific problem and then oozed out into a broader range of applications. It shares a lot with Fortran in that its form emerged through use rather than from a coherent design. The good thing about Perl is that there are eight ways to do everything. The bad thing about Perl is that there are eight ways to do everything, and some Perl programs use all eight ways. This leads to what I call write-only code. You figure out some clever way to do something in Perl, and then six months later when you have to change it, you can't figure out what it's doing so you just rewrite it. Good Perl programmers I've seen use only a subset of the language and use it consistently. What makes Perl good is its doggone utility. It's the programming equivalent of the well-timed air strike in a war movie. When your process paints itself into a corner, chances are you can extricate yourself with four well-written lines of Perl. But the things that make Perl useful in a pinch (e.g., the multi-faceted $_ variable) make it terrible where more deliberate, conscientious programming need to prevail. My philosophy says that a script that uses $_ anywhere in it should have a life span not to exceed half a day. If you're writing code for the ages, program correctly. One advantage of Perl is that it's a weakly-typed language. Its major disadvantage is that it's a weakly-typed language. There is a clear advantage to variables changing type according to context. But that quickly dulls when you realize that contexts also demand and enforce certain types, and it's not always clear which implicit conversion you are dealing with. The joke goes like this: $john = 3; $jane = 5; print Answer: $john + $jane;
Most weakly-typed languages respond deterministically, of course, but what should the answer be? Critics of weak typing say you may get any of Answer: 8 Answer: 7.999999999999425 Answer: 35 Answer: 3 + 5
depending on whether the context suggests integer arithmetic, real-number arithmetic, string concatenation, or simple dereference. Perl's strength are hashes and lists, which comprise the two principal forms of aggregate data structures: the (possibly-ordered) collection and the association list. You can build almost anything else out of those. In Perl's implementation, composite data structures create syntactical problems. Until you wrap your mind around its arbitrary notions of context, you have to jiggle the syntax of @, %, and $ to access properly a reference to an array of hashes. That's a symptom of a language that has been widely used before it was widely thought about. Languages that "don't let you do as much" aren't always as useful.
|
|
|
Post by Joe Durnavich on Apr 12, 2007 15:29:39 GMT -4
Perl is one of those languages that sort of congealed around a specific problem and then oozed out into a broader range of applications.
I am somewhat terrified of what Perl 6 is going to be. That project has been cooking way too long. I could settle for a faster interpreter with a smaller memory footprint.
I believe the goal now is to have Perl written entirely in Perl. There can be advantages to that. I have to distribute across a variety of Unix platforms, some ancient, some modern, and sometimes you need to add a Perl library that requires access to a C compiler. Our customers' systems rarely have one.
Perl has a do-it-yourself object-oriented syntax that is a bit tedious. You must retrieve and reference through the $self variable yourself rather than having the language handle it for you behind the scenes. It is impressive, however, that you can do it all.
The feature I miss the most is an actual switch or case statement.
It shares a lot with Fortran in that its form emerged through use rather than from a coherent design.
I suspect this may be the case for many scripting languages. Even Microsoft didn't realize that their VBS scripting language would be used and had to scramble to add in functionality that should have been there earlier. I wrote a script that among other tasks retrieved the name of the current working directory. It blew up at the first customer I gave it to because they had an earlier version of the interpreter that did not support the function.
My philosophy says that a script that uses $_ anywhere in it should have a life span not to exceed half a day.
I did a grep for $_ on some of my code and only a few hits came up. Generally, it was code I copied and pasted from elsewhere that I didn't want to mess with because it was the right combination of line noise that did what I needed.
If you're writing code for the ages, program correctly.
Or at least refactor as soon as you realize that one-shot program is going to be around and is going to be expanded over time.
|
|
|
Post by Joe Durnavich on Apr 12, 2007 15:36:38 GMT -4
I could find this out by looking at the link I guess, but is it limited in any way? When I took a programming course in college we were given a free edition of VB but it wouldn't compile stand alone programs, they would only run in VB.I don't believe it is limited in that fashion. These days, Microsoft wants you to write to .NET, which means you compile to their Common Language Runtime code (like Java's bytecode). The .NET framework doesn't care how the code was generated. This link is the feature comparison: msdn2.microsoft.com/en-us/vstudio/aa700921.aspx
|
|
|
Post by JayUtah on Apr 12, 2007 16:40:42 GMT -4
It is impressive, however, that you can do it [at] all.
My approach to objects is that the language should offer them, but not require them; not all problems are object-oriented. Perl rightly offers both objects and modules but does not require you to package your program according to either.
The Netscape 3.x code base was written by true C gurus and includes object-oriented code written in C, not in C++. It uses hand-rolled method tables and carefully nested structures. It worked very well and was both a clean design and a lean implementation.
I suspect this may be the case for many scripting languages.
I agree. The first three letters of REXX stand for Restructured EXtended -- it was IBM's second attempt (third, really) at a general-purpose interpreted programming language. And this is IBM, the company that normally thinks things through very carefully. I haven't written a REXX program of any complexity since the mid 1980s, but those programs just felt right. It's hard for me to get that same feeling from Perl.
It blew up at the first customer I gave it to because they had an earlier version of the interpreter that did not support the function.
And this is also where Java shoots itself in the foot. The interface to its runtime is too fluid, and the runtime's behavior too capricious, to allow programs of useful complexity to be written that don't require being tied to a specific runtime release or vendor. That's not a problem except where several Java applications from several vendors might run on the same machine; if each requires its own runtime for skew avoidance reasons, you get several copies of Java's extremely heavyweight runtime simultaneously.
I did a grep for $_ on some of my code and only a few hits came up.
It's okay as long as you use it clearly and consistently. It's when it's the lazy man's variable that you run into problems, such that by inserting an innocent line or two during revision you change what $_ means in some later reference.
|
|
|
Post by gillianren on Apr 12, 2007 17:29:10 GMT -4
I know the guy who wrote the glossary to the original Perl handbook.
|
|