Why things are done a certain way

blakeyrat

JS doesn't have the ability to change the separator character?

Dear Christ no! That would be a WTF in a sane language. JS is designed for light scripting needs (and completely mis-used as a app language on the web). All scripts share the same namespace.

blakeyrat

Why would that even be necessary? I've yet to see a webserver balk at doubled-up "/"'s in the path.

Dunno, not my code. The URL isn't loaded, though, it's sent to a web analytics DB server in a tracking pixel. Maybe their data collection web servers have wonky escaping. (The analytics software our company wrote doesn't have this issue, but sadly it's not as enterprisey as the competition.)

@PSWorx said:

Depends on the problem you're trying to solve, I'd say. There are some problems that are really better represented with a functional programming style, in which case chained/nested fucntions can actually be easier to comprehend.

As an example, I've recently had to parse a custom XML format in java, with XPath or similar technologies not available (Yes, I know, the Real WTF). So I've had the choice between

Node rootNode = doc.getChildren()[1];

Node firstRecordNode = null;
for (Node i : rootNode.getChildren()) {
if (i.getNodeName() == "person") {
firstRecordNode = i;
break;
}
}

Node dateOfBirthNode = null;
for (Node i : firstRecordNode.getChildren()) {
if (i.getNodeName() == "dateOfBirth") {
dateOfBirthNode = i;
break;
}
}

Node dayOfBirthNode = dateOfBirthNode.getChildren()[1];

String dayOfBirth = dayOfBirthNode.textValue();

return dayOfBirth;

or writing an utility function and doing

return doc.findFirst("root").findFirst("person").findFirst("dateOfBirth").findFirst("day").textValue();

I'd like to note however, that this only works for (practically) pure functions. I agree that chaining functions with side effects is a huge WTF.

This is hardly an argument in favour of long function chaining. The important action here was to create the "findFirst" abstraction. Then you would have had 4 or 5 sequential statements to contend with instead of the original mess. Of course, like you already said, the correct solution is to use XPath or something else that was actually designed for this.

By doing it the way you did it, you've created a brittle solution. If your design requires you to throw an exception when "findFirst" fails, then I guess you're OK in that specific case, but if somebody changes the spec to return null instead, you're boned. There is no clean way to chain a null reference like that (well, except with C# extension methods and some of the stuff you find in pure-functional languages). Same deal if you want to provide a default value instead. While your version isn't exactly awful, it's definitely walking the crap line.

The question in your case is, why wouldn't you want to split it up? What advantage does chaining confer? As far as I can tell, it's just a show of laziness - "I can't be bothered to create a few local variables so I'm just going to slap it all together on one line." Or maybe it's some bizarre style preference that you've locked yourself into; either way, it's ultimately likely to do more harm than good.

@Zecc said:

Have you met jQuery?

The intellectual wanking about jQuery's chaining ability was what turned me off of it in its early days, but once you realize it's just an irrelevant nerd feature that nobody actually uses, you'll probably find that jQuery is the best JS API out there. Scrapping some old WebForms/Atlas code and digging into the MVC+jQuery combination was one of my most enlightening experiences in web development.

morbiuswilters

@blakeyrat said:

The idea is good, but Javascript's using /regexhere/ syntax instead of quoting regex causes no end of pain for people who have to parse it.
You gotta love seeing lines like:
(location.href + '/').replace(/\/\/$/, '/')
/\/\/\/\/\/\/\/\/\/\/\/ indeed.

What's wrong with that syntax? That's what perl and sed use, too. If you think that isn't readable, you must not use regexes much. Not that quoting is really that bad, but what I like about having regexes as first-class objects is the built-in operators to make expressions easier.

PJH

@morbiuswilters said:

@blakeyrat said:
You gotta love seeing lines like:
(location.href + '/').replace(/\/\/$/, '/')
/\/\/\/\/\/\/\/\/\/\/\/ indeed.
What's wrong with that syntax? That's what perl and sed use, too.

Only by default - they can be made a bit[0] more readable:

<font face="courier new,courier"></font>
Hence my earlier question about changing the separator in JS.

[0] FSVO, admittedly.

blakeyrat

@morbiuswilters said:

What's wrong with that syntax? That's what perl and sed use, too. If you think that isn't readable, you must not use regexes much.

You win the prize!

Out of curiousity, do Perl and Sed use // and /* for comments?

@morbiuswilters said:

Not that quoting is really that bad, but what I like about having regexes as first-class objects is the built-in operators to make expressions easier.

Except I don't think JS has any of those.

bridget99

@bstorer said:

@Zecc said:
Whatever. TRWTF is having a line like a().b().c().d(e().f().g(h().i().j()));
Bullshit. Function chaining is a beautiful, magical thing.

Agreed. My typical coding style is to write code that looks like that. Also, I break out all of the parentheses using vertical whitespace, similar to the way more conventional programmers lay out curly braces. When my colleagues complain, it's a dead giveaway that they didn't really graduate in CS, since otherwise they would have taken Lisp, and would have a greater appreciation of this style of coding. ("But don't you remember from Lisp class... wait, you did go to college, right?")

I also use a great deal of copy/paste and repetition during implementation. Then, at the end of the process, I use parameterized macros to factor out commonalities.... no need to worry about scope, function call overhead, or anything else more sophisticated than text replacement. Again, if anyone complains, I fall back on year 4 of CS: "everyone knows that pass-by-name is more powerful than pass-by-value or pass-by-reference." Being right never felt so wrong ;)

Lingerance

@blakeyrat said:

Out of curiousity, do Perl and Sed use // and /* for comments?

No, they're both limited to "#" comments*. Also, sed (hence Stream EDitor) isn't really used as a full language. It's mostly used for some shell-script glue when awk/grep/perl wouldn't be appropriate.

*I may be wrong about perl though

DescentJS

perl can probably use any character for a comment, you just have to configure it and sacrifice a chicken.

morbiuswilters

@Lingerance said:

*I may be wrong about perl though

perl doesn't have real multi-line comments. There are a variety of methods for achieving them, but they all rely on abusing aspects of the language's syntax. Read it and weep. Literally.

PSWorx

@DescentJS said:

perl can probably use any character for a comment, you just have to configure it and sacrifice a chicken.

@http://www.perl.com/lpt/a/663 said:

It's as simple as that. Now, to just do one language seemed a waste of this idea. Many languages have nice multiline comments or even single line comments. So, we decided to support a few more languages - in fact, 44 in total right now.

The irony is not without a certain beauty.

PJH

@PSWorx said:

@http://www.perl.com/lpt/a/663 said:

It's as simple as that. Now, to just do one language seemed a waste of this idea. Many languages have nice multiline comments or even single line comments. So, we decided to support a few more languages - in fact, 44 in total right now.

The irony is not without a certain beauty.

May I tentatively suggest a new coding challange...

Write some lines of ~~code~~ comment that, in no matter what language it's thrown at, it will accept those as comments and not bother looking at them?

I forsee brainfuck and something requiring comments starting in column one being a problem, but still...

tgape

@PJH said:

May I tentatively suggest a new coding challange...

Write some lines of ~~code~~ comment that, in no matter what language it's thrown at, it will accept those as comments and not bother looking at them?

I forsee brainfuck and something requiring comments starting in column one being a problem, but still...

For the unlimited version you've suggested, it cannot be done - there are multiple combinations of languages which see each other's comment characters as syntax errors, such that regardless of which language you lead in, another language will barf before it gets into the comment.

The related, more traditional, challenge, is to write some code whose execution has the same effect in as many different languages as possible. This is generally performed by abusing comment characters to hide each of the languages from the others.

dhromed

@Aaron said:

The intellectual wanking about jQuery's chaining ability [is] just an irrelevant nerd feature that nobody actually uses,

Exactly.

I like jQuery a lot. It's really cut into my JS dev time. Prototype tries too hard and *requires* Scriptaculous to do anything nifty, making it the Visual Studio of js libraries. I haven't really touched upon Dojo or Mootools, but they seem work well also, given the casual enthusiasm of their users.