?

Log in

Language Elitism - The Desian Universe
Links Home / GitHub January 2017
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
 
 
 
deskitty
deskitty
Des
Thu, Dec. 14th, 2006 12:27 am
Language Elitism

So I've decided that both PHP and Python have made my list of bad/annoying programming languages.

>>> PHP

PHP was actually on it before, but this just confirms what I already knew -- PHP is a badly-insecure language. As such, it does not belong in the web programming space. Security is a huge issue, and if you don't pay attention to it, it will come back and bite you. By ignoring this, PHP developers are placing all of their users at a disadvantage. Even if the language itself doesn't have holes, it is still notoriously easy to write insecure code in PHP. Contrast this with Perl, which has been around at least as long, and has had plenty of time to implement (and actually use effectively) security measures such as tainting. People say Perl is old, or ugly, or difficult to understand -- and they might be right. But Perl also has at least one kickass web framework that's nicer (and safer) to code with than PHP.

>>> Python

Python has been added to the list. I was wavering on it for a while, but I've finally decided it deserves a place. This was the straw that broke the camel's (well, the python's) back -- I believe that lambdas (anonymous functions, closures, whatever you want to call them) should have a place in every high-level language. Lambdas are extremely useful for quick, short functions that need to keep their context (e.g. GUI event handlers), and IMO are conceptually cleaner than generators (e.g. for complex iteration schemes). Named inner functions are a clumsy, but acceptable substitute. Or they would be, if it weren't for what I would consider to be Python's OO shortcomings.

It's been a while since I've used Python, so my memory's a bit fuzzy, but I have a very distinct recollection of feeling as though the OO features were bolted on as an afterthought. (Yes, I am aware this is not the case, however, I think my impression is more relevant here, because it has more influence on day-to-day usage than factual history.) WTF is up with len(), for example? Why can't it just be a normal method? Do we really need a special def __len__ for what amounts to a normal method call?

I'm also a bit dubious on Python's handling of packages (though I hear that's been improved), globals (why do I need global keywords everywhere?), statements vs. expressions, and indentation. IMO statements and expressions should be one and the same -- every statement should return a value (even if it's None). Are there any good reasons for keeping them separate?

Also, I think indentation-based grouping is a neat concept in principle, but in practice it seems to have some shortcomings. First is the necessity for the pass statement -- if there is a block that does nothing, then I don't think one should see anything there (not even a nop keyword). Second, it's not really possible to implement a syntax for lambda that allows multiple lines and still keeps consistency with the syntax of the rest of the language. Finally, splitting statements across multiple lines is clumsy (you need to use \), and there's no way (that I know of) to put multiple statements on the same line. Yes, I am aware that doing so is supposedly Bad(tm), but they said that about goto, too, and I know I've run across cases where using a goto made the most conceptual sense. I'd argue the same rule applies to splitting/joining statements on a line.

I'm also a little concerned about the rumblings I've been hearing from the Python community about new syntactic features each release. (Decorators one time, improved generators the next...) I don't have a problem with any specific feature, but I think it's telling that the Python devs feel it's necessary to keep adding new language features (and deprecating old ones). It suggests to me that maybe their overall language design/philosophy isn't as flexible as perhaps it should be. (But, obviously, that's a totally subjective judgement, and you should make your own.)

By contrast, Lisp syntax hasn't changed in a long, long time. C++ syntax has remained relatively stable since the introduction of templates (though there are rumors of more changes in C++0x, perhaps rightfully so).

So ... I'm still on a quest for the Perfect Language(tm). Maybe one of these days I'll get around to finishing Dryice, and then I'll have a first approximation thereof, or something. ;P I'm not silly enough to believe I'll find a perfect language, but I may as well try, yeah? ;)

-- Des

Tags: , ,
Current Mood: sleepy sleepy

6CommentReplyShare

kion
kion
Kevin Kress
Thu, Dec. 14th, 2006 09:19 am (UTC)

I won't argue Php, but python? I mean seriously what else does any self respecting person use to script these days. Say perl and I'll come down there just to put you out of your misery.


ReplyThread
deskitty
deskitty
Des
Thu, Dec. 14th, 2006 04:13 pm (UTC)

I will say Perl.

The reason I will say Perl is that (despite the fact that it's butt-ugly), it's still quite possible to write very powerful scripts in that language with a minimum of fuss.

Sometimes you need powerful text manipulation facilities, and sometimes you don't want to bother with OOP. For simple scripting situations, where you're building a program to interact with other tools on the system, I've always found Perl easier to work with than Python, for two reasons: first, I/O redirection is chicken-simple, and second, Perl's regexes are unmatched (except perhaps by Ruby, which I haven't seriously used).

Is it butt-ugly and quirky? You betcha. But not, I feel, in a way that interferes with getting work done in Perl's target domain.


ReplyThread Parent
kion
kion
Kevin Kress
Thu, Dec. 14th, 2006 06:03 pm (UTC)

I will say Perl.

The reason I will say Perl is that (despite the fact that it's butt-ugly), it's still quite possible to write very powerful scripts in that language with a minimum of fuss.


As long as they are < 1000 lines and intended to be written once then thrown away. No argument.


Sometimes you need powerful text manipulation facilities, and sometimes you don't want to bother with OOP. For simple scripting situations, where you're building a program to interact with other tools on the system, I've always found Perl easier to work with than Python, for two reasons: first, I/O redirection is chicken-simple, and second, Perl's regexes are unmatched (except perhaps by Ruby, which I haven't seriously used).


If I need to parse a list, I'm going to use perl. If I'm going to write a real program in a scripting language I'd rather stab myself in the face than use perl.


Is it butt-ugly and quirky? You betcha. But not, I feel, in a way that interferes with getting work done in Perl's target domain.


1) It is unmaintainable for large programs
2) It "object orientedness".... you want to talk about tacked on with little thought. The person who invented bless should be tortured in public.
3) Its syntax is at best arcane at at worst redundant to all hell
4) Did I mention completely unmaintainable?
5) You have no room to bitch about python modularization, perl is just as bad or worse.
6) References... no seriously, they are beyond stupid
7) scalar casting to arrays or hashes... just because you can doesn't mean you should


ReplyThread Parent
deskitty
deskitty
Des
Thu, Dec. 14th, 2006 06:50 pm (UTC)

1) It is unmaintainable for large programs

I disagree. During the course of my job search, I saw large Perl codebases that were very cleanly-written, and were pretty easy for me to understand. (These are production systems, mind you, in use and in development for a number of years.)

As you should know, maintainability is more a function of the programmer and the way in which he/she expresses concepts, and less about the specific language. The language certainly plays a role in terms of the available idioms, but I think it's possible to write readable code in almost any modern, somewhat-mainstream programming language.

2) It "object orientedness".... you want to talk about tacked on with little thought. The person who invented bless should be tortured in public.

That's not Perl's target domain -- it wasn't designed to be a language for seriously complex programs. You should use real programming languages for real programs, and Perl for things it's good at -- short, throwaway scripts, web programming when you have something like Mason to help structure it, etc.

Perl's OOness is certainly ... different. I've heard arguments on both sides of that debate, and I think both sides have merit. I would discuss this further, but I'd have to dig up references, and I don't really have time for that at work. :-/

3) Its syntax is at best arcane at at worst redundant to all hell

If you have used it long enough, you can tease out and stick to a relatively consistent subset. My own experience suggests that your assertion is a common one primarily amongst those that haven't taken the time to really learn the language. I had the same objection at first, and it gradually evaporated as I learned more.

5) You have no room to bitch about python modularization, perl is just as bad or worse.

Not. Until relatively recently, Python modules were forced to use relative package names and required __init__.py files in each package, even if it was blank. Perl has none of this silliness.

6) References... no seriously, they are beyond stupid

What's your basis for saying that?

I've never made much use of them, myself (apart from hashrefs/arrayrefs), but I know that PerlTk, for example, makes good use of them. (You can bind a text box to a scalar reference, for instance, and the text box will automatically update the reference as its contents change.) I don't think adding them costs much, if anything -- if you don't use them, you don't have to notice they're there.

7) scalar casting to arrays or hashes... just because you can doesn't mean you should

I agree. I don't quite understand why that misfeature is there. I think the $# syntax is nifty, though.


ReplyThread Parent
toranin
toranin
Toranin
Thu, Dec. 14th, 2006 02:33 pm (UTC)

[Warning: Python fan post.]

WRT Python and lambdas: Named inner functions are a conceptually identical substitute. And if occasionally verbose syntax bothers you, then yes, Python is not the language for you. Python's tendency is to enforce syntax that's most likely to be clear, even when it's less "fun" or compact. It's the exact opposite of Perl in that respect.

Multiple statements on the same line: IIRC ; works.

Changes: IMHO at least, they've not deprecated anything significant between 2.0 and their current release. The fact that they've added several powerful new features and constructs in a backwards-compatible manner is one of the coolest things about the language to me. Generators are one of my favorite language constructs to date, in fact.

OO: Python's OO mechanisms are very powerful, if you can get over using 'self' all the time. Again, it's a matter of seeing past a notational inconvenience to the elegance of the language constructs in operation behind them. *shrug*


ReplyThread
deskitty
deskitty
Des
Thu, Dec. 14th, 2006 04:22 pm (UTC)

WRT Python and lambdas: Named inner functions are a conceptually identical substitute.

I understand that. But I find their syntax not only verbose, but clumsy and less intuitive. I gave a couple examples in my post of situations in which I think this is a problem.

Multiple statements on the same line: IIRC ; works.

OK.

Generators are one of my favorite language constructs to date, in fact.

I suppose it's a matter of preference. I tend to look at generators in the same way I look at Intercal's COME FROM statement. Generators are like inside-out lambdas. I just happen to think lambdas are more elegant. (They are certainly easier to implement, at least if my memory of Python's implementation of generators is accurate.)

OO: Python's OO mechanisms are very powerful, if you can get over using 'self' all the time. Again, it's a matter of seeing past a notational inconvenience to the elegance of the language constructs in operation behind them.

I don't have a problem with the concept of 'self'. In fact, I rather like it. But to my mind, the notational inconveniences get in the way of using Python OO in a clear, consistent manner. They obscure those constructs when in fact they should be exposing them.


ReplyThread Parent