Leave a comment

momentsmusicaux November 12 2013, 13:15:43 UTC
Why didn't the first coder just do a 'is the string length less than 5? Yes: pad it with 0s at the front'. Considering only those two cases is brittle (though I admit I don't know the business logic of US postcodes). But the first rewrite is already into total insanity territory.

Better still, use a language that considers that this sort of thing is a frequent use case: http://php.net/manual/en/function.str-pad.php

A case to rewrite the whole project, surely! ;)

Reply

andrewducker November 12 2013, 13:20:21 UTC
Because, as it says further down:
"What happened to that piece of code? It was for zip codes, it was only supposed to pre-pend one or two zeros when importing zip codes from CSV files. Anything with fewer than three digits is supposed to be an invalid code."

The point being, you don't change working code to match your preferences for how code "should" be unless you have a good reason, understand _why_ the original developer did it that way, and are prepared to regression test it.

Reply

andrewducker November 12 2013, 13:20:53 UTC
Or as the author says at the end:
"As many of you have noted, the post is not about the Agnostic or his code, it’s about the dynamic of programmers eager to rewrite code in their own image, and the hypothesis that our (I am equally guilty of this behaviour) motivation for doing so is to emphasize the small differences between ourselves and others."

Reply

momentsmusicaux November 12 2013, 21:32:01 UTC
It's a fair accusation, but there's more to it than that.

If I have code in front of me, I need to understand it. If the idiom the original writer used is overly complex, or badly chosen, or just badly written, and if I have or feel I have authority to rewrite it to be more legible, I will.

Not as drastically as the examples, but things like breaking up stupidly long clauses for example.

Reply

andrewducker November 12 2013, 21:40:31 UTC
That's where I love refactoring tools - I can select a bunch of code, click "extract method" to pull some of it out into its own method, and know that the result does exactly the same as the original code, without having to worry about doing it manually and breaking something along the way.

Reply

skington November 12 2013, 14:20:50 UTC
momentsmusicaux November 12 2013, 21:30:01 UTC
Yeah yeah. Already read that.

Name a language that is better suited to handling code on the web. That has support for regexes and string manipulation. And unicode. And date/time manipulation, with timezones. And handling of CSV files for data import.

The more I see of other languages, the more I realize that PHP, despite being a ragged mess when looked at from an aesthetic point of view, is popular because it gives you the tools to get the job done.

Case in point: AFAIK, Andy's script for posting these links every day doesn't change to account for DST because the libraries for timezone handling are crappy in whichever language it's written in (this is dimly remembered from a conversation in the pub over a year ago, so I could be wrong). In PHP, handling that would be a total breeze.

Reply

andrewducker November 12 2013, 21:37:47 UTC
Nope, the script didn't do it because I couldn't be arsed dealing with different time zones from a UI perspective (i.e. accepting posting times from users in their own timezone and converting to UTC in the back end) at the time, and decided to do everything in UTC ( ... )

Reply

skington November 13 2013, 02:05:45 UTC
Perl has regex support built in. It has by far the best Unicode support of all scripting languages (if you consider most recent versions against each other). Its DateTime module is excellent for parsing dates and times. CSV is a stupid format, but Text::CSV and/or Text::CSV::XS are fine.

And I could say the same thing of many other scripting languages, I suspect; it's just that I write Perl code professionally, so that's what I know. I would be shocked if Ruby and Python weren't better than PHP at the things you mentioned; then again, PHP is so shockingly bad that I'd give it at best even odds against Visual Basic. Hell, even stuff like Java or C# might be better than PHP ;-) .

If you've read the "PHP is a fractal of bad design" article and dismissed it as "meh, PHP gets the job done", then you do not understand the job. You do not understand what can be done with a proper programming language. You are a poster child of the Dunning Kruger effect, and there is no point talking to you.

Reply

meowpurrr November 13 2013, 07:49:07 UTC
my problems with perl when i tried to pick it up over a decade ago, having already been exposed to VB & PHP, were:
- the seeming reliance on the programmer to remember/know what was in the unnamed variable thingy ($_ ?) at all times, and what would/wouldn't overwrite it,
- lack of a central searchable web site to search for functions/examples/etc the way PHP has. no, man pages are not good enough.
- the weird difference between what PHP would call numeric-key and string-key arrays and having to remember which symbol to use or nonsense would ensue, rather it just being a bucket you can stuff with whatever you like (PHP's number parsing issues notwithstanding),
- in terms of hooking to apache, ISTR mod_perl being harder to work with than mod_php, and weird conventions around using /cgi-bin and scriptalias and all of that rather than just "files with extension blah run in this interpreter".

Reply

skington November 13 2013, 14:45:44 UTC
All perl man pages are online these days, if they weren't 10+ years ago, and in any case stackoverflow.com is there to answer your questions ( ... )

Reply

meowpurrr November 13 2013, 15:35:59 UTC
The thing PHP has had for as long as I've used it is a single site you can type a function name into, and it will redirect you to the page dedicated to explaining that function. A lot of Perl teaching examples also relied on grabbing things from CPAN, where again it wasn't clear how to usefully use a new module without having to read and understand the module's entire code. (Although PEAR modules aren't hugely better in that regard, but there is usually some phpdocumenter web output to be found ( ... )

Reply

momentsmusicaux November 13 2013, 08:28:54 UTC
I probably am.

I taught myself on Perl back in the early 2000s. I liked it, and I still do, but there's one reason right there why PHP took over: libraries. With PHP you don't need to go to CPAN and figure out which library you might need, muck around downloading it on all your environments (which last time I tried didn't work on OS X, had to hack something together). DateTime and CSV are just there when you want them.

Also, perl is pretty much dead isn't it? How many years had perl 6 been in development?

> CSV is a stupid format

It's simple, it's human-readable, and it's easily exportable from spreadsheet apps which is what humans use to create lists of data. What are your objections? What would you consider superior? And please don't say XML (ugly and unreadable). I'd consider JSON for small data sets, or for data requiring nesting, but it's unforgiving which makes it a PITA, and for a very large data set it's just a ton of needless duplication.

Reply

andrewducker November 13 2013, 09:02:45 UTC
There are advantages to all three data formats:
CSV - really easy for non-techies to produce. Very simple, can be processed easily.
JSON - Javascript can read it natively
XML - you can use schemas to ensure that data is syntactically correct, and it's massively more powerful in the structures you can use

We use all three at work, in different places, and there are definitely situations where each of them is the right answer.

Reply

skington November 13 2013, 14:20:55 UTC
CSV is pretty much the only option in some cases, yeah, especially if you're expecting the person producing or consuming it to load it into a spreadsheet. But there's a lot of cruft in the format, and a whole lot of things that can go wrong - see the arguments to the constructor of the Perl module for an example of all the cruft you have to work around.

Reply

meowpurrr November 13 2013, 15:40:21 UTC
For CSV type things, I tend to use tabs instead of commas. Removes having to worry about whether commas in the data are escaped, and copying and pasting from excel to a text editor produces tabs anyway.

Reply


Leave a comment

Up