Comment by pyre | Hacker News Reader

Comment by pyre | Hacker News Reader

Parent Full thread

> a problem that is likely to get worse as the number of whitespace characters continues to proliferate (not just plain spaces and tabs, but non-breaking spaces vs regular spaces....).

I know that people love to hate on Python's semantic whitespace, but this is the first time that I've seen someone argue that Python's lifespan is limited because we are about to enter a period of exponential growth in the number of whitespace characters.

Where do you feel that this growth in the number of whitespace characters is going to come from? Do we not already have a plethora of whitespace characters in the current Unicode standard, in addition to things like the vertical tab of yesteryear that languishes in the ASCII standard? How come we don't see any of these issues now, even with the number of whitespace characters that we already have at our disposal?

> The thing is that such work is not applicable to the "throw together an app using an ORM or NoSQL fast" crowd

Are you trying to imply that using an ORM is the sign of someone trying to "whip something together fast?" What are your feelings on DBIx::Class? Should those people who use it jump ship to some other language so that you can bid then "good riddance?"

> I know that people love to hate on Python's semantic whitespace, but this is the first time that I've seen someone argue that Python's lifespan is limited because we are about to enter a period of exponential growth in the number of whitespace characters.

I think the various Unicode whitespace characters are likely to gain more use generally. The big problem though is that whitespace characters all look alike and so you can't read and parse the way a computer does.

> Are you trying to imply that using an ORM is the sign of someone trying to "whip something together fast?" What are your feelings on DBIx::Class? Should those people who use it jump ship to some other language so that you can bid then "good riddance?"

Not really. ORMs can be used in significant applications and in fact a lot of people use DBIx::Class that way in Catalyst etc. I am referring specifically to the quick and dirty app crowd. You have PHP, Python, Javascript (via Node.js) and Ruby largely taking that role over. And that's fine. Perl is a wonderful language, but to write good quality, maintainable, robust code in it takes some work. But that work is well rewarded.

> I think the various Unicode whitespace characters are likely to gain more use generally.

I'm curious what you expect these increased usage to stem from, and how you feel that it will inevitably find its way into source files.

> The big problem though is that whitespace characters all look alike and so you can't read and parse the way a computer does.

In general, the editor takes care of indentation for the programmer. What developer is going to add (e.g.) non-breaking spaces as an option for indententation in the development tool that they maintain?

If you're worried about copy-pasting, then that's already an issue in some places. I've had SQL break because the whitespace contained invisible characters due to an encoding issue during copy-paste, and PostgreSQL (IIRC, could have been Oracle) wasn't very helpful in diagnosing the issue.

Unexpected invisible characters cropping up anywhere are going to give you issues, Python or not.

> I think the various Unicode whitespace characters are likely to gain more use generally. The big problem though is that whitespace characters all look alike and so you can't read and parse the way a computer does.

I think the big problem is, that there are people out there, that think Python programmers have a huge urge to use non-standard whitespace characters in their source code.

> Perl is a wonderful language, but to write good quality, maintainable, robust code in it takes some work. But that work is well rewarded.

The reward for that kind of code is the same in all languages, but your statement implies, it's maybe better to choose a language, where it's not as hard as with Perl to write good quality, maintainable, robust code. Point taken.

Writing good perl code is easy once you sign the social contract.

Writing good code in any language is remarkably time-intensive to learn. There are any number of ways to mess up code and the coding patterns and antipatterns are different in any language.

It takes struggling with the ways of doing things in the language and seeing what works and what does not. Perl is no exception, except that there is no One True Perl way. Every Perl programmer finds his or her won way.

Reply on news.ycombinator.com