Slashdot Mirror
What I Hate About Your Programming Language
chromatic writes "Perl programmers like punctuation. Python programmers like indentation. Every programming language has its own syntax, stemming from its philosophy. What I Hate About Your Programming Language examines the issues that shape languages as they grow. It's not advocacy, I promise."
What he hates about PHP doesn't sound so bad, and doesn't seem like anything that won't be corrected in PHP5.
I knew there was a reason I liked it.
Produce a language without some rules and you would end up with even messier code.
I wish some higher level languages would force the use of comments in code, make it part of the declaration for a class or function.
He likes JavaScript, but hates something about all other languages? Most of his complaints are just plain nonsense. Want regex in Java, well upgrade then! Upgrade to the latest compilers/bug fixes. He doesn't like the way Perl syntax LOOKS like??? He's not all that good looking himself! Most of his complaints are overly simplistic, and full of fluff. There are much worse things to complain about languages, besides syntax, and inappropriate usage.
If no one has heard of it they can't make fun of it. Until they realize that I haven't gotten around to loops in the released version yet :-)
.jar files can be executed from the console, J2dk for Linux/ppc version 1.4 is released, caffeine springs from trees, and C++ no longer requires the programmer to deal w/ pointers. Oh yeah, and all BASIC interpretters are dumped into Sol.
I think that varied languages are a necessity. It'll be better when
You can't judge a book by the way it wears its hair.
I looked at this article, and I was disappointed by what a limited set of languages chromatic had examined. Where was Prolog? ML? Common Lisp? SNOBOL? Smalltalk? Dylan? All the languages in the article are in the class of "imperative languages with varying amounts of object-oriented gravy." If you're talking about how languages embody a philosophy, why stick to languages that pretty much embody the same philosophy, with some minor tail-fins and chrome as their differences?
[I suppose that's some flame bait....]
The lack of good line termination (sorry, but a caridge return doesn't cut it) is another problem.
The dogcow says "Moof!"
I don't think it's always technical. A few years ago it seemed like most comments in regard to Java were positive, but when it became evident that it wasn't really "free" in the same sense as is perl or python... then lots of people started bashing it. Though like many languages has it's flaws, it still remains a solid language. The same with VB, virtually no-one in *this* audience considers VB a great language, which is reinforced by the fact that no-one's really putting much effort into creating a VB like tool for Linux (albeit there are several dead projects that have tried). It's a shame because VB actually works quite well for a particular niche- quickly developing business apps. In the case of VB, I can safely predict most people here will not give it credit because of it's links to Monopolysoft.
Blender And Linux Fan
This just brought to mind the .NET CLR.
I have done a little bit with this, coded a couple apps where a member on my team really really liked VB and myself a java guy liked J#.
We could work well together without having to worry about learning a syntax that we didn't feel comfortable with.
Oh man, his criticisms of Java, C & C++ (three languages I enjoy) are dead-on. The way he addresses the whitespace issue in Python isn't anything new, but it's stated more clearly and articulately than I've ever read.
:D
My only complaint about the article is that his condemnation of XSLT isn't rabid and acidic enough for my tastes.
Good stuff. None of the languages he addresses are glaringly bad and in fact most are actually quite good (well... XSLT is a bad joke), but these are great points to remember when someone starts spouting off about how language XYZ is the ultimate.
ANSI C itself is at least stable. The procedural part of the language is generally accepted (it's basically the same in Java, C++, etc.) The declaration syntax has problems. It's broken for historical reasons. Originally, C was LALR(1), but then came "typedef", and it went downhill from there with "class", etc. Nobody has been able to fix this properly. This is why the parser gets lost in so many error situations.
C++ suffers from some early bad design decisions. Templates came late. Strostrup knew about templates, and decided not to put them in. This led to great pain and ugly code, templates went in, and it's taken a decade to clean up that mess.
Java was supposed to clean this all up, but now Java is getting generics, which it wasn't supposed to need. So it's going down the same path as C++, but with a new set of mistakes.
Other attempts to fix C include Objective C (which still has a following) "C+@" (a Bell Labs product that predates Java), "C#", a Microsoft variant, and several others with tiny market share such as "D". None are enormously better than C.
I'd like to see C++ cleaned up, but the ANSI committee is more interested in putting in obscure features for template writers.
you'll be stuck running your code on a microsoft server
http://www.apache-asp.org/
neurostarCurrently just supports perl scripting though.
Actually i enjoy programming in a lot of languages and, as problably most who programmed for a while, the problem is seldom the language (otherwise you chose the wrong for the job).
:(
But it always get's ugly when it comes to debugging. You're in a bad mood anyway (it's a bug - probably your bug - and it will cost you, very probably, even more time than programming the whole f**king function).
No matter which language, after a while you start hating your debugger. You're programming 3D and have a problem with vectors - all u see variables with some numbers. You're programming a database and the results don't fit.. all you see are variables with wrong result. Etc...
It's always like your car broke down and you get messages like iron content of bumper 100%, mass of bumper 1.4, foo.ineedtorenamethis 1.5...
And then you gotta dig through the dirt
I think that the gcc group had that figured out first. gcc uses front ends to translate the c, c++, fortran, java, and whatever other languages it can use to intermediate files, which are then compiled to assembly then machine code.
Once again, Microsoft "innovates" themselves into territory where others have lead them.
The middle mind speaks!
Better would be languages which are self-documenting...
There is no language that will force perfect code. There is always room for a poor programmer to produce hard-to-understand code. Functions that do two unrelated things, confusing control flow, bad variable names, broken code that was repeatedly patched instead of being cleaned up... the possibilities are endless.
Nonetheless, some languages have been designed with self-documenting code in mind; sometimes it even works.
If you look at languages like COBOL, they have long descriptive keyword names designed to make the code easy to read. But you get tired of looking at those long keywords.
I haven't used ADA, but I understand that it is somewhat designed for self-documenting code, and that as a result you are hemmed in on all sides by language rules. (ADA fans please comment here.)
The best language I have seen for this is Python. As a rule there is exactly one way to do things, so you don't trip over obscure hackish tricks that you have to puzzle out. The language doesn't force self-documenting or comments, but it does force indentation; everyone indents their Python pretty much the same (compare with the mess that is C indentation). The language is high-level enough, with lots of libraries, so you don't need to write 10 lines of code just to do one simple thing.
Python was designed by a guy who is both a computer geek and a math geek. The math geek in him led to a very tidy language design, and I like it very much. I think schools ought to be using Python to teach introductory programming classes.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
One fault I find with the author's assessment is that he is evaluating the language only from the standpoint of the one who is writing in it. I think a better language assessment would also evaluate a language from the viewpoint of the poor bastard who actually has to read someone else's code written in that langage. Does the language have the tendency to produce code that is readable and understandable by the person who didn't write it? Or does the language have the tendency to produce code that is readable/understandable by only its original author?
For example, Perl allows the programmer who writes a perl program try to make their code as terse and unreadable as possible, fitting everything on one line by exploiting some bizarre behavior of the perl interpreter. While this "expressiveness" might be wonderful to the person who's writing the code, it's really going to be a problem for a second person who might want to contribute to it or maintain the project after the original author threw in the towel or got hit by a bus.
Another example is operator overloading. Perhaps operator overloading is useful to the first person writing the code, as it provides a nice little shortcut where they can do foo + bar as opposed to something like foo.add(bar). But if there's another person who's decided to work on this project, and they're not very familiar with the code and they are trying to get the idea of how it works, how can they tell whether foo+bar is a mathematical operation or some sort of concatenation? Yes, if they look over the code enough, they can understand it. But perhaps that extra amount of fuss and the extra amount of time wasted trying to make sense of things will convince that person it would be easier to write their own stuff than try to reuse someone else's.
A final area I wish the author focused on is documentation. Does the language support some sort of embedded and standardized documentation that make it easier for the first programmer to provide information that would help a second programmer make sense of the code, or is documentation at the discretion and mercy of the first programmer and whatever bizarre and non-standard documentation system they might use?
I would suspect that projects using languages that make it harder on the person who has to read the code have higher incidences of duplication of effort and a great NIH (Not Invented Here) tendency.
But that's just my opinion.
Ergonomica Auctorita Illico!
Paul Graham put together a brief list along those lines, titled What Languages Fix.
When Knuth set out to reinvent publishing, he had to decide what language to write TeX et al. in, and wanted others to be able to use it (or he'd probably have coded in MIX). In later years, he explained that he asked everyone he respected to name their three favorite languages. There was a wide range of #1s, but most folks put Pascal as #2. So he wrote in the language that everyone liked less than something else.
On the other hand, if Pascal is good enough for the gods, it's good enough for us grunt coders.
Unfortunately the result is a language whose omitions actually make it more verbose and harder to maintain than C++.
I disagree with this a little; I find uncommented Java code easier to understand than commented C code. Regardless, I'm not a huge Java fan, partly because I've always found the class library to be a pain in the ass. The first Java project I worked on, I spent hours trying to figure out how to manipulate dates properly. Writing the code in Python or Perl instead would have been much shorter, easier to understand, and took me a few minutes to figure out. I've never figured out how Java's anal retentive typing is supposed to make this type of thing "better".
While technically right, this misses the point.
McCarthy's LISP 1.5 was never meant to be used by industry. (In fact, it was never meant to be a computer language at all; McCarthy's LISP was meant as a simpler model of the Turing Machine, and it was only turned into a proper programming language by an enterprising grad student.)
MacLISP, ZetaLISP, etc., were all attempts to take a purely theoretical language and turn it into a language useful for productive tasks. Why do you consider this to be an example of LISP's flexibility causing forks? If LISP wasn't that flexible, it would have never been able to make the leap out of the laboratory and into the real world.
Once people had experience at making LISP work in the Real World, then Common LISP came about. This is the way languages evolve, and that's just the way it should be.
No language ever springs from a designer's head full-blown and perfect, like Athena erupting from Zeus' skull. A cycle of languages diverging and then converging is a sure sign that the language is healthy and alive.
In fairness, some IDEs color different comments different ways. I've seen people use the different comment styles to make different kinds of comments. There's no steadfast rule, it's just preference, and SOME people use them that way.
I understand what you're trying to say, but PHP doesn't really have a counterpart. You can't really compare it with Perl, Java, or C++. The closet we have to something that compares to PHP is ASP, which is hardly a substitute. Perl wasn't really designed for web use, althought it's found its way there.
Either way, you seem awfully angry about this. PHP is flexible and is meant for all programmers. Like the rest of the Linux debates, the camp that "hates" PHP is often the same people who are elitist about Linux in general.
>>(define language? (lambda (x) 'scheme'))
As someone already pointed out, ? indicates a predicate function, which returns #t or #f. And this function really doesn't take a parameter... so I'd actually just define it like this.
(define language 'scheme)
Well, you might want to call it as a function, so this would be better.
(define language (lambda () 'scheme))
Er, the use of @foo to define an object attribute is great; it means there's no need to type self. all the time, makes attributes obvious, and means you don't need to use lame prefixes like m_ObjectAttribute.
A much better hate would have been the awful Perl/sh-era pseudo globals ($_ $@ $! $| $" $' $1 - what were you thinking matz!?); we all hate those
Why am I disappointed with Perl, and thrilled with Python and SWIG? I sent Larry Wall some fan mail in April of 89, enthusiastically asking about upcoming features, and describing what I wanted to do with it:
He replied:Python is extremely well designed to thoroughly solve the extension language problem -- on purpose, not as an afterthought! And SWIG makes it very easy to expose rich programming interfaces, structured data types and complex class libraries to extension languages.
Will someone who's intimately familar with how Perl has evolved over the past 14 years since I submitted that request, please describe how difficult it is using Perl as an embedded extension language, integrating Perl with pre-existing applications, extending Perl with libraries written in C and other languages, exposing complex data structures and class libraries to Perl?
-Don
Take a look and feel free: http://www.PieMenu.com
I've been thinking lately about languages, what if I could write code in a pseudo language, with extremely flexible syntax the ideals of what i'm trying to program. e.g. I want to add a bunch of integers together. Sometimes when I write papers, I do it by hand on paper, cause, believe it or not, my thoughts get lost sometimes because I'm trying to process the typing in my memory (lol, no, I'm not retarded) Usually my papers flow better that way, that's not to say that I couldn't go straight to typing and produce something great. But the idea behind this thought is that I don't want to aggravate myself about the details of any particular language. I just want to put my thoughts on paper or something and then worry about what language, what environment i want to run this through later, after the main details are put forth.
I then want to take that pseudo code, which has strict syntax, pass it to a parser that then generates code in any language whatever it is that i want done. So I could say, convert to VB or C or Java or perl and out comes some generalized code that you can then compile with your favorite interpreter or compiler. I know it would be strange to convert object-oriented code into non-object-oriented code, but wouldn't that be a neat tool? And wouldn't that be a beast to code?
Anyone interested in a project? Sorry, this is loose and somewhat stream of consciousness, but I think it has merits, open discussion?
This was a very interesting article. I natively speak Perl, C, and C++, know enough about PHP to get by, and still remember some Commodore 64 BASIC (10 ? CHR$(147)). I am also, as I believe I've said before, not afraid to learn things like Java, Python, Ruby, maybe even Visual Basic again (God forbid) should they prove exceedingly relevant to my case - in fact, I quite look forward to knowing (hopefully) all of them and then some. But never Pascal. (Just kidding.)
I've really found that the thing I hate most about programming in general is that no single language is the right one to use for any of my programs! I am very interested in any effort I ever come across to do functional merging of disparate environments. In addition to a couple of workarounds I've invented in the past for shoehorning Perl into PHP, I like reading about things like SWIG, the open CLR, and even COM (the concept more than the implementation), and a smile always comes to my face when I think about the Inline library written for Perl.
Now, the thing I really pine for is all of this interlanguage binding stuff being easy, fairly portable, more synactically simple, and less hacky. I know that these exist, but not quite completely together. If I write a program in Perl with use Inline C, I can never be sure that anyone else has all the development tools necessary to compile all the C on the fly. Writing a program in Visual Basic with a nice mouse-drawn GUI and an external component is really easy - but it's Visual Basic. Writing a component wrapper for Perl is fairly straightforward with SWIG, but some well-thought-out language features would make it easier. And COM... I'm going to have to try wrapping my head around that book again someday... I'm sure the ATL makes it all very simple, but can I use ATL from MinGW? From C? From Perl? And don't try to tell me that I need to learn yet another flavor of XML to make all of this work.
That's mis tus centavos.
(Note: I disclaim perfection. Don't hit me too hard; I admit I haven't done enough of my homework to claim this post isn't full of holes. Once I've looked this whole matter through, if ever, and if I still haven't come up with anything good, I may just have to take a deep breath, lay down a syntax, figure out how to use a lexer generator and a compiler compiler, and throw together some ghastly but very easy-to-use homogeneous aggregator system. Either that, or I wait for Parrot to interoperate with Mono...)
Actually, that's unlikely.
This blog entry by Dan Sugalski gives an expanation:
The most valuable commodity I know of is information. - Michael Douglas as Gordon Gekko, Wall Street
God help you if you're quoting a guy who drafted at least 12 different calling conventions for his vaporware Parrot VM in the last year. (Gee, we'll make ALL the registers available for parameters! Scratch registers - what are they?)
The only way Perl6 will be finished is if Parrot finds a real designer - not a pretend one like it has now. I predict that Perl6 will be finished BEFORE Parrot is completed. Someone will take Larry's Apocolypses and just write a frigging Perl6 interpreter without a line of Parrot.
If you want a really small and fast interpreted language - go to www.lua.org
The notion of "coding in C is a premature optimization" is completely rediculous. While I'll admit that for different tasks, different languages are more appropriate, if you know C best, then you should probably do it in C.
Plus the notion that coding in C is an automatic optimization over other languages is absurd. It is true that do to the lower level nature of C, it can be used to make very efficient code. But in many cases I know I can write equally efficient code in C++ (or other languages) because of the nature of the problem.
Heh, starting to sound a bit hypocritical here aren't I? I guess what i am trying to say is. If you can do it best in a given language, do it in that language. I am however an advocate of learning as many languages as you can, so that you can make a better choice regarding this issue..on your own.
so don't go out of your way to do it in another language just because someone said you can do it slightly better if you took the time to learn about "language x."
General purpose languages are just that "general purpose", it is silly to force yourself to program in an "uncomfortable" language just because it may fit the problem better...you'll probably end up making worse code anyway.
proxy
Then he tries to have it both ways by wanting to ignore exceptions and yet force comments.
And how can you have someone writing an article on various languages repeatedly saying "I don't really know much about this? *rolls eyes*
And how exactly can you search databases without doing set operations?
The rest of this article is full of cliches ("It's a lot easier to solve problems if you have a toolbox full of good tools.")
And his English - "Language Badnesses"... Jesus.
As a particular example, take PHP's error handling. The language has no real exceptions, which is forgivable--but it insists of making up for it by faking them.
It has something akin to sigaction(), but much less powerful. It allows you to provide one function to handle all errors, except for some that PHP insists on handling itself. At least that function can switch on the error, right? Nope! There are only 5 different error codes which your code can catch, only 3 of which you can actually throw (again, with a function instead of a language construct).
And if you thought this was bad, try the error handling in the library. Each set of functions seems to have its own function to check for errors, and you have to repeatedly check the manual to find out how a function indicates failure. I've seen the following different methods of indicating failure:
function returns FALSE
function returns TRUE
function prints a message to the browser
function returns 0
function returns 1
function returns nonzero
function returns negative
call another function to find out
functions returns something that can be fed into another function to find out
function raises an error condition you can catch (through fake exceptions described above)
function raises an error condition you can't catch
pass in a variable by reference and the result will be there
check if the returned array is empty, and if it is use a different function to find out whether that indicates an error or just a (legitimate in context) empty array
Don't even get me started on the naming conventions of functions, or the ordering of their arguments. (Check out the array functions if you want some good examples.)
PHP is a language that was designed for small, simple CGI scripts, and it does this well. It does not scale. PHP was never meant to be used from the command line, but how else can you write a cron job to do some nightly maintenance? (Write in another language? Sure, and give up all the libraries you've written for the project.) Sure, you can use lynx -dump http://example.com/nightly.php >/dev/null, but then you have to make sure no one but you can use that script, and it's just generally an ugly thing to do.
For all of its faults (and it has many), one of the thigs Perl does well is provide actual language features for things like merging arrays, sorting arrays with a user-provided comparison function, or declaring a variable with loop scope. PHP's libraries keep growing, which is nice, but the language itself is too small and too limited. I don't want to use library functions for everything, nor do I honestly care whether the language is even context-free. I just want a lanugage that doesn't suck.
</rant>
Gates' Law: Every 18 months, the speed of software halves.