Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

tef posted:

If you meet someone with a high stack overflow reputation, chances are they'd make a great copy editor. It is a game that rewards those who can cannibalise other peoples answers into a way that garners approval from the idiot who can't google.

My experience is that Stack Overflow is awesome if you have a simple question. If you have a reasonably complex or obscure question, you're not going to get much help. I've asked 4 questions and only one has gotten a useful response that solved the issue. The others I figured out on my own.

I still like answering questions, though.

# ? May 2, 2012 02:36

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 05:50

tef: May 30, 2004; -> some l-system crap ->

I'd wager a quite significant chunk of the questions on SO are examples of the X-Y problem, but trying to ascertain this tends to lose you reputation. You earn more points for answering a stupid question, than you ever will for trying to work out the actual problem they're facing.

# ? May 2, 2012 02:49

The Gripper: Sep 14, 2004; i am winner

Ithaqua posted:

My experience is that Stack Overflow is awesome if you have a simple question. If you have a reasonably complex or obscure question, you're not going to get much help. I've asked 4 questions and only one has gotten a useful response that solved the issue. The others I figured out on my own.

I still like answering questions, though.

The only times I've asked questions on SO they've been crazy as hell and sounded like X-Y problems, so I've never gotten responses. I figure most of the actual, answerable questions have already been asked and answered, and if you can't find a pre-answered question on SO then you're probably doing something horribly wrong or stupid anyway.

# ? May 2, 2012 03:07

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

As a hobbyist who has maybe 5 years of hobbyist experience... I find answers on SO via Google all the time, but if I ask a question on there its not uncommon to not get a good answer.

I think this is because all the easy to answer questions have already been asked.

# ? May 2, 2012 03:16

pseudorandom name: May 6, 2007

tef posted:

Read the JSON rfc sometime, and see if you don't go wat.

That does have the virtue of making escape sequences fixed width, so there's no possibility of ambiguity between the escape sequence and the following text.

# ? May 2, 2012 04:11

Adahn the nameless: Jul 12, 2006

tef posted:

I'd wager a quite significant chunk of the questions on SO are examples of the X-Y problem, but trying to ascertain this tends to lose you reputation. You earn more points for answering a stupid question, than you ever will for trying to work out the actual problem they're facing.

Eric Lippert has answered a couple of my x-y questions by answering y, yelling at me for wanting to do it, then figuring out x and answering that

That in of itself is pretty cool.

# ? May 2, 2012 04:16

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

I try to answer uncommon questions on SO, but then again I only have like 130 points/karma/epeen/whatever. I don't answer questions to get points and don't give a poo poo how many I have. Just help out your fellow devs and be satisfied in doing a good job.

# ? May 2, 2012 04:18

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

Fren posted:

Douglas Crockford's shtick is really getting old.

You could say he's become one of the Bad Parts. :mmmhmm:

# ? May 2, 2012 04:18

shrughes: Oct 11, 2008; (call/cc call/cc)

Suspicious Dish posted:

Yep. Go look at his commit messages. They're all terrible. I shouldn't have to explain what commit messages are for to someone like Douglas Crockford: they're there to summarize a change, and more importantly, detail why it changed.

Maybe instead of saying wrong things in the midst of character assassination you should stop and consider that you may be wrong. Here you are, saying things about the sanctity of commit messages that you have no particular reason to believe. Because guess what? It's not actually important to describe what a commit does. If you disagree, please name one person that was harmed by his commit messages.

Here's why you are wrong. By making rules that commit messages must be long and detailed, you are causing people to make fewer commits! That's bad. Also, it takes time to do that, and if people want to look at the way the code works, they can look at the current version of the code. And if they want to know why it works that way, they can look at the comments in the current version of the code.

The main useful purpose of commit messages is to provide a memorable title for a commit. That's 99% of the commit message value proposition: providing a title better than a SHA-1 hash. His commit messages work admirably for that goal. If you want to go back and look for what commits touched a certain type you don't do so by searching long and detailed commit messages. You use git blame. So what benefit does the long and detailed commit message have?

Nothing! Nobody was hurt by his commit message. If you took out commit messages entirely, you'd retain 95% of the benefits of a version control system. If you limited commit messages to 140 characters, you'd retain 99.9% of the benefits of a version control system.

Guess what: If your commit only changes comments, then your commit message should be "comments". Are you going to sit there and sperg about what comments you changed, and why? No, because that's a waste of time and completely retarded.

code:

Commit: abcdef12345649592202oab
Author: Suspicious Dish <stupid.babby@dish.net>

Changed comments in the Eschaton subsystem and Heaviside Layer.

  - Added more detail about the propensity of MERV configurations.

  - Decreased the manipulexative cofactor of HeavisideAdapterType comments.

  - Added a TODO bitching about public variables.

# ? May 2, 2012 04:23

The Gripper: Sep 14, 2004; i am winner

If you don't give a poo poo about anyone else looking at your commits then yeah, commit messages are just irrelevant metadata. If the only people looking at your commits are developers, and they're only looking at them because something is broken then sure, git blame is the better solution than scrolling through commit messages looking for the relevant one.

But poo poo, if someone tries to submit a pull request to anything I'm maintaining and their commit messages are garbage, I'm not going to look at their changes and try to imply the meaning of them. There's no reason not to use a commit message that in some way assists in knowing why the change was made.

# ? May 2, 2012 04:50

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Those commit messages are all significantly worse than "comments" and are entirely worthless. They tell you absolutely nothing when looking at the commit log (and on projects with useful commit messages, I find looking at the log to be useful approximately all the loving time), and they tell you nothing when looking at the commit itself.

# ? May 2, 2012 05:07

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Also if I saw a commit with the title "comments" my immediate assumption would be that it's a pile of unrelated functional changes along with a single comment since that's what people who can't handle spending a few seconds to write a short sentence per commit tend to do.

# ? May 2, 2012 05:13

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

pseudorandom name posted:

That does have the virtue of making escape sequences fixed width, so there's no possibility of ambiguity between the escape sequence and the following text.

Speaking as someone who's written three JSON parsers, no, the JSON encoding of astral characters has no virtue. It exists that way only to more closely resemble Javascript, which is not a goal any sane person should strive for.

Python's handling is much better. It has fixed-width for both BMP and astral, by using \u for BMP and \U for astral.

\uFF5E -> always 6 characters
\U0001D11E -> always 10 characters

# ? May 2, 2012 05:21

ShadoX: Oct 4, 2004; There is no W!

shrughes posted:

Are you seriously defending lovely commit message practices, in the coding horrors thread of all places?

ShadoX fucked around with this message at 05:30 on May 2, 2012

# ? May 2, 2012 05:21

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Janin posted:

Speaking as someone who's written three JSON parsers, no, the JSON encoding of astral characters has no virtue. It exists that way only to more closely resemble Javascript, which is not a goal any sane person should strive for.

When the entire concept of your format is that it's a subset of Javascript, resembling Javascript is a pretty important goal.

# ? May 2, 2012 05:26

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Plorkyeran posted:

When the entire concept of your format is that it's a subset of Javascript, resembling Javascript is a pretty important goal.

That's *not* the point of JSON, though. It may resemble JavaScript's object notation, but it isn't defined by the JavaScript spec. JSON is already incompatible with JavaScript in dozens of subtle ways, so there would have been no harm in adding a proper astral escape sequence. Especially if they could then go and add it to the JS standard.

# ? May 2, 2012 05:35

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

shrughes posted:

Linus Torvalds thinks you're wrong. I know you don't care about Linus's opinions. I really couldn't care less myself. But his logic is sound: commit messages should contain the motivation behind the change. Maybe it's just a URL to a bug report. Maybe it contains a reference to the JS specification, and an essay or talk by Crockford showing why this JS feature is bad. Maybe it's a link to a graph showing a 20% speedup between this commit and the last.

Maybe it's just the words "JSLint looks for ~~ and `~ in comments at the end of lines to allow certain kinds of behaviors. Two lines were incorrectly marked", because otherwise I can't even start to imagine what this was for.

If I have a fork of JSLint that I'm shipping to my customers (which I can't really do because of the license, but whatever), should I cherry-pick this change?

Janin posted:

That's *not* the point of JSON, though. It may resemble JavaScript's object notation, but it isn't defined by the JavaScript spec. JSON is already incompatible with JavaScript in dozens of subtle ways, so there would have been no harm in adding a proper astral escape sequence.

I only know of one subtle way that JSON isn't a valid subset, and that's the Unicode newline separator not being allowed in a string. It's more of an oversight than anything. Do you know of more?

If you're talking about JS object notation not being exactly JSON, wrt. unquoted keys, of course. But there are rationales for every one of those. What you're suggesting would make JSON not a proper subset of JS.

Janin posted:

Especially if they could then go and add it to the JS standard.

Crockford, if anything, is the guy who would be against adding anything to the JS standard.

# ? May 2, 2012 06:06

shrughes: Oct 11, 2008; (call/cc call/cc)

Suspicious Dish posted:

Linus Torvalds thinks you're wrong.

Linus may actually be hurt by lovely commit messages, considering what he does all day. Crockford's lovely commit messages don't hurt anybody.

# ? May 2, 2012 06:20

pseudorandom name: May 6, 2007

Janin posted:

That's *not* the point of JSON, though. It may resemble JavaScript's object notation, but it isn't defined by the JavaScript spec. JSON is already incompatible with JavaScript in dozens of subtle ways, so there would have been no harm in adding a proper astral escape sequence. Especially if they could then go and add it to the JS standard.

What are those incompatibilities, out of curiosity?

And ES6 does have the proposed \u{xxxxxx} notation.

# ? May 2, 2012 06:27

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

shrughes posted:

Linus may actually be hurt by lovely commit messages, considering what he does all day. Crockford's lovely commit messages don't hurt anybody.

well yes, in the sense that not indenting your code doesn't hurt anybody if you don't like it and you're actively trying to avoid having anyone contribute to or use your program anyway

# ? May 2, 2012 06:29

Zhentar: Sep 28, 2003; Brilliant Master Genius

Thermopyle posted:

As a hobbyist who has maybe 5 years of hobbyist experience... I find answers on SO via Google all the time, but if I ask a question on there its not uncommon to not get a good answer.

I think this is because all the easy to answer questions have already been asked.

I've never tried asking something on SO, but I suspect I'd have a similar experience.

I've been thinking I need to start asking questions so I can answer them, just to get the solution/explanation out there. So many obscure things I've figured out, then soon after forgotten, lost to the world once again.

# ? May 2, 2012 06:51

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Suspicious Dish posted:

I only know of one subtle way that JSON isn't a valid subset, and that's the Unicode newline separator not being allowed in a string. It's more of an oversight than anything. Do you know of more?

pseudorandom name posted:

What are those incompatibilities, out of curiosity?

To start, {} is a valid JSON document, but an invalid JavaScript expression. Numbers are different, in that [1e10000000000000] is perfectly fine JSON but cannot even be represented in JavaScript. Ditto [-0.0], which JavaScript treats as identical to [0.0].

The worst is encoding detection, though. JSON mandates that a document be encoded with UTF-{8,16,32} and specifies how to detect which encoding is used. JavaScript (as far as I know) does not specify this, and leaves it up to the browser to auto-detect based on the page's encoding (good luck including a UTF-8 script in an ISO8859-1 page!).

pseudorandom name posted:

And ES6 does have the proposed \u{xxxxxx} notation.

That's a silly notation; they'd be much better off adopting Python's.

# ? May 2, 2012 06:59

Malloc Voidstar: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

This is presumably a legitimate optimization but it's still one hell of an if-statement:

code:

    public String[] split(String regex, int limit) {
        /* fastpath if the regex is a
           (1)one-char String and this character is not one of the
              RegEx's meta characters ".$|()[{^?*+\\", or
           (2)two-char String and the first char is the backslash and
              the second is not the ascii digit or ascii letter.
        */
        char ch = 0;
        if (((regex.count == 1 &&
             ".$|()[{^?*+\\".indexOf(ch = regex.charAt(0)) == -1) ||
             (regex.length() == 2 &&
              regex.charAt(0) == '\\' &&
              (((ch = regex.charAt(1))-'0')|('9'-ch)) < 0 &&
              ((ch-'a')|('z'-ch)) < 0 &&
              ((ch-'A')|('Z'-ch)) < 0)) &&
            (ch < Character.MIN_HIGH_SURROGATE ||
             ch > Character.MAX_LOW_SURROGATE))
        {

# ? May 2, 2012 07:02

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

The big

is using both .count and .length().

# ? May 2, 2012 07:04

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Janin posted:

To start, {} is a valid JSON document, but an invalid JavaScript expression.

It's a valid JavaScript expression. The problem is that the Block statement takes precedence over the Expression statement.

Janin posted:

Numbers are different, in that [1e10000000000000] is perfectly fine JSON but cannot even be represented in JavaScript.

Many number formats can't be represented exactly in a machine native format, even ones like 0.1 and 0.2, yet we pretend that we can. [1e10000000000000] can still be parsed by JavaScript, even if it will resolve to Infinity.

Janin posted:

Ditto [-0.0], which JavaScript treats as identical to [0.0].

code:

js> [-0.0]
[-0]

Janin posted:

The worst is encoding detection, though. JSON mandates that a document be encoded with UTF-{8,16,32} and specifies how to detect which encoding is used. JavaScript (as far as I know) does not specify this, and leaves it up to the browser to auto-detect based on the page's encoding (good luck including a UTF-8 script in an ISO8859-1 page!).

ECMA-262, Section 6 posted:

ECMAScript source text is assumed to be a sequence of 16-bit code units for the purposes of this specification. Such a source text may include sequences of 16-bit code units that are not valid UTF-16 character encodings. If an actual source text is encoded in a form other than 16-bit code units it must be processed as if it was first convert to UTF-16.

# ? May 2, 2012 07:24

pseudorandom name: May 6, 2007

Janin posted:

That's a silly notation; they'd be much better off adopting Python's.

What, you mean \u verses \U? They can't, they've already defined them to be equivalent. Or do you want to break backward compatibility?

# ? May 2, 2012 08:42

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Suspicious Dish posted:

Many number formats can't be represented exactly in a machine native format, even ones like 0.1 and 0.2, yet we pretend that we can. [1e10000000000000] can still be parsed by JavaScript, even if it will resolve to Infinity.
code:
js> [-0.0]
[-0]

code:

>>> [-0.0]
[0]

Resulting in undefined behavior is just as bad, if not worse, than refusing to parse it outright.

pseudorandom name posted:

What, you mean \u verses \U? They can't, they've already defined them to be equivalent. Or do you want to break backward compatibility?

They could use another character; the point is to avoid overloading \u to mean either BMP or Astral depending on whether there's a { in the escape sequence.

# ? May 2, 2012 16:45

pseudorandom name: May 6, 2007

I don't know what JavaScript interpreter has that >>> prompt, but it is defective.

JavaScript has positive and negative zeroes.

# ? May 2, 2012 17:51

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

pseudorandom name posted:

I don't know what JavaScript interpreter has that >>> prompt, but it is defective.

JavaScript has positive and negative zeroes.

If the chrome dev tool console is a true javascript interpreter, [-0.0] is returning [0] for me.

# ? May 2, 2012 18:00

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

I get 0 out of every browser I punch it into

# ? May 2, 2012 18:00

Opinion Haver: Apr 9, 2007

The best way to distinguish negative zero from zero is to divide by it. Using the Chrome dev console:

code:

> x = [-0.0]
[0]
> 1/x[0]
-Infinity
> 1/0
Infinity

# ? May 2, 2012 18:03

pseudorandom name: May 6, 2007

Yeah, it's purely a display issue, for some reason Chrome and Firebug both display -0 as 0.

# ? May 2, 2012 18:08

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Janin posted:

code:
>>> [-0.0]
[0]
Resulting in undefined behavior is just as bad, if not worse, than refusing to parse it outright.

It's a bit more complicated than that, actually. Mozilla has the incorrect behavior. There is a -0, it just isn't stringified as such:

ECMA-262, Section 8.5 posted:

Note that there is both a positive zero and a negative zero. For brevity, these values are also referred to for expository purposes by the symbols +0 and −0, respectively. (Note that these two different zero Number values are produced by the program expressions +0 (or simply 0) and -0.)

ECMA-262, Section 9.8.1 posted:

2. If m is +0 or −0, return the String "0".

http://es5.github.com/#x8.5
http://es5.github.com/#x9.8.1

# ? May 2, 2012 18:11

pigdog: Apr 23, 2004; by Smythe

Bhaal posted:

In terms of data format I wouldn't say XML is necessarily a terrible way to go in this case, BUT:

If these are being generated by the public, especially if the node structure your software is expecting is very dynamic and/or specific to its requirements, hand editing XML like that can be a real pain especially for end users. (That being said, I don't think hand editing in any format, JSON, YAML, or whatever will be any better in this situation). For instance, if your software encounters node N, say it needs at minimum child nodes X, Y, Z defined, and say it's parsing a user submitted a document with a Node N with only X and Y defined. Do you have a fancy system of defaults to fill in any gaps, or will your internal data structures be incomplete without Z defined externally? If the latter, you'll want to make it easy for them to spot and fix this.

One solution is you could offer a validator so they can quickly fix any mistakes right away. User generates the document, runs it through the validator (web tool or whatever), and it comes back with "Hey dummy! Node N at line 123 needs child node Z defined!".

That's why defining an XSD schema is a good idea. You can say in it that node N needs X, Y, Z and optionally Y, and if the XML doesn't have them, then it's simply invalid. You can publish the XSD and independently validate the XML (at least as far as the structure goes) before submitting it. On the other hand, the code that makes use of such predefined XML format can be simpler and less defensively programmed. The schema kinda works as a contract/conformance test as such.

quote:

A better solution, though involves a lot more dev time, is to make an editor for them. It's on the fly validation as you can have the editor demand input where input is required, generate required child nodes and so on, so your user doesn't get lost in the weeds on your data structures. Also they don't have to worry about syntax or any of that meta data and instead just fill in the pertinent stuff. You could do this in a native app or make a page that builds out form elements with js/jquery/etc, submits to your server, and you feed them back the resulting xml. Note: I don't know how much use those xml documents will see from your userbase, though, so putting in the time to make a tool like this may not be an efficient sub-project to work on if you don't anticipate a lot of user generated documents. If 1 in 10 of your dedicated userbase will ever seriously dabble in it, maybe it's best to provide clear documentation & examples and leave it at that.

Well that's true; the end user would rarely be expected to hand-write XML in the first place.

# ? May 2, 2012 22:27

nonathlon: Jul 9, 2004; And yet, somehow, now it's my fault ...

Contero posted:

What do people think about Yaml? I haven't actually used it in a project yet, but it seemed nice enough.

Belatedly, but I like it a lot. Used it as an editable file format for a few projects I did, to allow people to tweak and roll their own data. It's readable and comprehensible. Wish it had a wider mindshare.

# ? May 3, 2012 08:35

Zorro KingOfEngland: May 7, 2008

is there even a feasible way of looking at a file that big?

# ? May 3, 2012 16:17

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Am I reading that right? Does that say 163 GB?

There are some text editors that will handle large files, but I don't know any that run on Windows. The easiest way would be to write a small tool that split up the file into N-million-line chunks. The resulting chunks would still be large, but should be readable in standard mmap-based editors like Vim.

# ? May 3, 2012 16:32

nielsm: Jun 1, 2009

Zorro KingOfEngland posted:

is there even a feasible way of looking at a file that big?

Should have set up some log rotation.

Obviously, it can be analysed, as long as the software doing it is well-written, though I wouldn't want to do it over a network. If you only need to read entries from some particular date range, you could do a binary search in the file, assuming the entries are timestamped and timestamps are strictly increasing.

# ? May 3, 2012 16:34

epswing: Nov 4, 2003; Soiled Meat

Relatively minor but...

We've partnered with a GPS vehicle tracking company, we poll them and get updates about where a client's assets are. Each update is timestamped DD/MM/YYYY. Recently, they decided to change that to MM/DD/YYYY without telling us. This results in strange numbers for the first half of a month, and broken updates after the 12th :v:

Not really 'horrifying', I'm just still amazed at the sheer lack of competence.

(To be fair, I'll take part of the blame. I could have anticipated them screwing up and compared the current month to the month in the update, and if it was off, flipped day/month. Still...)

# ? May 3, 2012 16:43

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 05:50

Zombywuf: Mar 29, 2008

Zorro KingOfEngland posted:

is there even a feasible way of looking at a file that big?

Awk. Specifically mawk as gawk is sloooow.

# ? May 3, 2012 16:51

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »