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!

«‹›1503 »

fritz: Jul 26, 2003

Subjunctive posted:

I would love to hear more about that circumstance, if only because it sounds like the makings of an awesome interview problem. Were you primarily constrained by code size? Did you get a transaction fee for every swap?

piratepilates posted:

Please explain in more detail because that sounds very interesting.

I had a metric shitload of tiny little arrays to sort.

# ? Mar 22, 2014 04:23

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 15:08

Soricidus: Oct 21, 2010; freedom-hating statist shill

qntm posted:

Perl does this as well. Except sometimes they're treated as subroutine calls.

Perl hasn't done this in nearly 20 years. Unless you're an idiot who doesn't use strict, in which case you deserve everything you get.

# ? Mar 23, 2014 01:31

Pythagoras a trois: Feb 19, 2004; I have a lot of points to make and I will make them later.

Is there a licensing horror thread? After installing a LAMP stack more or less against my will to get mediawiki working, the last hurdle took the form of an undefined json function that smelled like a missing dependency. So I looked up the error message and got this:

http://stackoverflow.com/questions/18239405/php-fatal-error-call-to-undefined-function-json-decode#answer-18239665

For the lazy:

Beautiful.

# ? Mar 23, 2014 18:33

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

Ahahaha this is the best part

just reimplement all of JSON badly yourself!

# ? Mar 23, 2014 18:38

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

Cheekio posted:

Is there a licensing horror thread? After installing a LAMP stack more or less against my will to get mediawiki working, the last hurdle took the form of an undefined json function that smelled like a missing dependency. So I looked up the error message and got this:

http://stackoverflow.com/questions/18239405/php-fatal-error-call-to-undefined-function-json-decode#answer-18239665

For the lazy:

Beautiful.

Yep, and Douglas Crockford thinks it's a great idea to cause all this license havoc.

# ? Mar 23, 2014 18:53

..btt: Mar 26, 2008

Cheekio posted:

JSON license

Yeah, ran into this at work a few weeks ago. Still waiting to hear whether we need to replace it. Anyone know of any good replacements with a corporate-friendly license? The JavaScript JSON library I mean, not the php one.

# ? Mar 23, 2014 19:20

Dren: Jan 5, 2001; Pillbug

It doesn't say who decides what good and evil are.

# ? Mar 23, 2014 19:32

kitten smoothie: Dec 29, 2001

IBM has a special dispensation from Crockford to use it for evil.

http://dev.hasenj.org/post/3272592502/ibm-and-its-minions

# ? Mar 23, 2014 20:21

karms: Jan 22, 2006; by Nyc_Tattoo; Yam Slacker

Crockford is such a penis, jesus.

# ? Mar 23, 2014 20:41

Blue Footed Booby: Oct 4, 2006; got those happy feet

Suspicious Dish posted:

Yep, and Douglas Crockford thinks it's a great idea to cause all this license havoc.

Has anyone ever been sued over that license? I'm imagining arguing over definitions of good and evil in court and the judge either shooting himself or you.

# ? Mar 23, 2014 20:42

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Blue Footed Booby posted:

Has anyone ever been sued over that license? I'm imagining arguing over definitions of good and evil in court and the judge either shooting himself or you.

Granted it's fun messing with lawyers.

# ? Mar 23, 2014 20:52

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

KARMA! posted:

Crockford is such a penis, jesus.

You realize, I hope, that he's exaggerating for the sake of a story.

(He's a penis just the same.)

# ? Mar 23, 2014 22:12

Catalyst-proof: May 11, 2011; better waste some time with you

KARMA! posted:

Crockford is such a penis, jesus.

Actually, he owns.

# ? Mar 24, 2014 14:46

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

horse mans posted:

Actually, he owns.

He has his moments (thanks for JSON), but his historical lectures leave me cringing at the sometimes-small stuff he makes up, and I think he's largely been overtaken by the increasing sophistication in the language and how people use it. He was a menace on the ECMA committee lists.

# ? Mar 24, 2014 16:05

Powerful Two-Hander: Mar 10, 2004; Mods please change my name to "Tooter Skeleton" TIA.

This is from memory because I can't be bothered to open the solution but for executing an ssis package:

code:


 Bool success = true;
If (runvalue =true)
{
Package.execute();
If (package.success=false)
{
Success=false;
}
}

Guess what happens when the package fails to execute and the logging is tied to the value of Success? :suicide:

Powerful Two-Hander fucked around with this message at 16:45 on Mar 24, 2014

# ? Mar 24, 2014 16:39

Sulla Faex: May 14, 2010; No man ever did me so much good, or enemy so much harm, but I repaid him with ENDLESS SHITPOSTING

It takes a special kind of blind faith to initialise a security protocol success variable as true

# ? Mar 25, 2014 14:58

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

Subjunctive posted:

He has his moments (thanks for JSON), but his historical lectures leave me cringing at the sometimes-small stuff he makes up, and I think he's largely been overtaken by the increasing sophistication in the language and how people use it. He was a menace on the ECMA committee lists.

json is a crime against serialization formats. just simple enough to work and then everyone writes their own incompatible extensions atop to shoehorn in other data types. the rfc is wrong in many places (unicode esp).

it's basically like the markdown of object markup, used because it's popular, there is a standard which is inconsistent, and no-one can really agree on things.

# ? Mar 25, 2014 17:03

Dren: Jan 5, 2001; Pillbug

what is wrong with the rfc in regard to unicode?

# ? Mar 25, 2014 17:39

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

tef posted:

it's basically like the markdown of object markup, used because it's popular, there is a standard which is inconsistent, and no-one can really agree on things.

The best part of this analogy is that while

quote:

Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).

can arguably be considered a success (this is a thing Markdown can do),

quote:

JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.

is a complete failure because JSON is not a subset of JavaScript. So JSON is basically like the Markdown of object markup except it's somehow even shittier.

# ? Mar 25, 2014 17:51

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

https://www.ietf.org/rfc/rfc4627.txt posted:

To escape an extended character that is not in the Basic Multilingual Plane, the character is represented as a twelve-character sequence, encoding the UTF-16 surrogate pair. So, for example, a string containing only the G clef character (U+1D11E) may be represented as "\uD834\uDD1E".

# ? Mar 25, 2014 17:52

ExcessBLarg!: Sep 1, 2001

pokeyman posted:

is a complete failure because JSON is not a subset of JavaScript.

It's pretty close to being a subset of JS object literal syntax. That's good for familiarity sake. The practical effect of it not being a perfect subset is that you can't guarantee correctness by evaling a JSON string. But folks shouldn't be doing that in the first place.

# ? Mar 25, 2014 18:02

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Lysidas posted:

Non-BMP always requires surrogate pairs, no? Does in ES5.

JSON is standardized in ES5 if nothing else, and it's a proper subset of ES5 (it wasn't of ES3). Having a better-than-XML interchange format that's a de facto standard for use (and standardized in format and API) is a big win for the web.

# ? Mar 25, 2014 18:05

PrBacterio: Jul 19, 2000

Subjunctive posted:

Non-BMP always requires surrogate pairs, no? Does in ES5.

I'm no expert but I'm fairly sure it doesn't in UTF8. In fact if I remember correctly you're not supposed to use surrogate pairs at all in any encoding scheme that's not UTF16 (or otherwise based on a basic character width of 16 bits). But as I said I'm no expert so correct me if I'm wrong :ohdear:

# ? Mar 25, 2014 18:26

pseudorandom name: May 6, 2007

JavaScript inherited Sun's surrogate-pairs-in-UTF8 Java bug, and JSON codified it into the spec for string literals.

# ? Mar 25, 2014 18:35

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

PrBacterio posted:

I'm no expert but I'm fairly sure it doesn't in UTF8. In fact if I remember correctly you're not supposed to use surrogate pairs at all in any encoding scheme that's not UTF16 (or otherwise based on a basic character width of 16 bits). But as I said I'm no expert so correct me if I'm wrong

You are correct. Surrogate pairs are a hack to work around the limitations of UCS-2, the end result of which is UTF-16.

It's an implementation detail that extant Javascript interpreters use UTF-16 for in-memory string storage, and this should not have been codified in the JSON standard. To support ASCII backslash-"encoding" of non-BMP characters, I like Python's \U0001D11E.

# ? Mar 25, 2014 18:37

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

Of all the things I expect Crockford to "get right", a decimal floating point format is not one of them.

# ? Mar 25, 2014 18:39

pseudorandom name: May 6, 2007

Lysidas posted:

You are correct. Surrogate pairs are a hack to work around the limitations of UCS-2, the end result of which is UTF-16.

It's an implementation detail that extant Javascript interpreters use UTF-16 for in-memory string storage, and this should not have been codified in the JSON standard. To support ASCII backslash-"encoding" of non-BMP characters, I like Python's \U0001D11E.

JSON predates JavaScript's \u{0001D11E} syntax, and the surrogate pair idiocy is compatible with JavaScript.

# ? Mar 25, 2014 18:44

JawnV6: Jul 4, 2004; So hot ...

Suspicious Dish posted:

Of all the things I expect Crockford to "get right", a decimal floating point format is not one of them.

Can't remember if I said this before, but it looks like being able to access al/cl registers was the driving motivation here.

# ? Mar 25, 2014 18:52

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Decimal has been on the ES battlefield for ages, too. IBM agitated for it, but never really got to an acceptable proposal. In fact, IBM voted against ECMA approval of ES5 to make a point about how pouty they were about a lack of decimal arithmetic. I guess value types are the future prospect for them, but I don't know how real (hey-o) they are at this point. I probably wouldn't pick Douglas for that role either.

I'd forgotten some of the sordid surrogate pair history, but you're right, and it's coming back now. Removing support for surrogate pairs expressed in HTML entities broke sites for Firefox and Safari/Chrome both, but things adapted (or, as likely, we all stopped caring). I wonder if I still have old mail from the debates when we first added Unicode support to the Netscape JS engines; people get pretty serious about their code points.

Edit: sorry, I'll stop making GBS threads up the thread with random nostalgia.

Subjunctive fucked around with this message at 19:17 on Mar 25, 2014

# ? Mar 25, 2014 19:12

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Subjunctive posted:

JSON is standardized in ES5 if nothing else, and it's a proper subset of ES5 (it wasn't of ES3). Having a better-than-XML interchange format that's a de facto standard for use (and standardized in format and API) is a big win for the web.

Looking through the ES5 spec, the grammars still don't match up. The line terminators U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR aren't allowed in ES5 string literals but are allowed in ES5 JSON.

Which is fine, whatever, I don't care, it just blows up the stated design goal of JSON. I'm not even sure who to blame for that failing.

Dealing with these exceptions is certainly less effort than dealing with how XML is bastardized though, so I think we agree about JSON tripping over that low bar.

In fact, I take it back. That JSON isn't quite a subset of JavaScript is as boneheaded as Markdown's "what's a grammar?" tef I approve of continuing your analogy.

# ? Mar 25, 2014 19:38

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

pokeyman posted:

Looking through the ES5 spec, the grammars still don't match up. The line terminators U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR aren't allowed in ES5 string literals but are allowed in ES5 JSON.

I think you're wrong, in ES5, about it being an illegal character.

http://es5.github.io/#x7.3 defines those as part of LineContinuation, which in the StringLiteral definition (http://es5.github.io/#x7.8.4) has a character value of the empty character sequence. So it should fit the grammar, though I'm not sure it has the same value. (!)

The JSON portion of the spec is confusing. It talks about JSON being a restricted object literal expression, which sure sounds like a subset, but then there's text about it using a smaller set of characters in WhiteSpace, specifically U+2028 and U+2029, so...

I'll ask Dave Herman, if I can't find the relevant portion of es-discuss archives.

Edit: I sobered up or something. It's clearly not the same value, because those become present in the decoded string, so it's not a subset in a useful way. Maybe even worse, since eval will silently corrupt data. Another in the set of RFC-JSON infelicities (like its specification of strings not permitting all JS strings to be round tripped). JSON.stringify will even produce the unescaped form, if I'm reading step 11 of Quote correctly. :smith:

Apologies, then, I stand disappointedly corrected. Wish Mark Miller had triumphed there, but I guess it was inevitable.

Subjunctive fucked around with this message at 22:36 on Mar 25, 2014

# ? Mar 25, 2014 21:26

Fuck them: Jan 21, 2011; and their bullshit

So as part of my "do something totally different every month" full stack job I was appointed CSS lord and charged with cleaning up our 1200+ LOC style.less.

What we actually use was able to be split into a half dozen appropriately named files I just imported into style.less, each of which has 70 LOC at most. Now you can find what you're looking for in a place that makes sense instead of duplicating poo poo!

I've removed some 500 lines of poo poo, junk, un-used, bad form, or just duplicated lines from style.less; I saw poo poo like medium-input and mediumInput both doing the same thing, or things like large-input and "mediumPlusInput" doing the same thing. When I was merging classes together that did the same thing before picking a name for the other devs and telling them to change to it, I saw this gem:

code:

.large-input, mediumPlusInput, wideInput

{

    width: 175px !important;

}

What makes me laugh the most is that when I first started, compiling to CSS took a while, and a few times actually made the less compiler run out of memory!

:q:

# ? Mar 25, 2014 21:37

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

The first step to almost any CSS refactor is control+f for !important and removing them. It's so rare for that to actually be necessary (not sure I've ever seen a time, but I imagine it exists).

# ? Mar 25, 2014 21:39

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Subjunctive posted:

I'll ask Dave Herman, if I can't find the relevant portion of es-discuss archives.

Did you find the relevant part of the mailing list? I'm curious what the reasoning is behind this continued stupidity.

# ? Mar 25, 2014 23:22

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

pokeyman posted:

Did you find the relevant part of the mailing list? I'm curious what the reasoning is behind this continued stupidity.

It's spread out, but the reasoning behind ES5's stance is compatibility with then-existing JSON in the wild. (Which was informed more by what json2.js did than what the RFC specified, perhaps obviously.) I note that JSON.stringify can produce output that isn't RFC-compatible either, but only in cases that were illegal before, so it's not a compatibility concern.

The original damage in json.js and subsequently codified in the RFC is almost certainly just Crock going fast and ignoring/misunderstanding the ES3 spec's grammar before he froze the unversionable RFC. He'd not be the first to be tripped up by the spec's complexity, but it's one of the more unfortunate cases. I guess I could just ask him, though IIRC our last exchange was somewhat heated.

# ? Mar 26, 2014 00:10

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

I remember Douglas Crockford proudly proclaiming that JavaScript should never have more than one number type, and that floating point is the problem, and that a better number type can be found.

He then reinvented fixed point formats a few times before giving up.

# ? Mar 26, 2014 00:48

Fuck them: Jan 21, 2011; and their bullshit

down with slavery posted:

The first step to almost any CSS refactor is control+f for !important and removing them. It's so rare for that to actually be necessary (not sure I've ever seen a time, but I imagine it exists).

Our CSS was such a stupid mess that even while we're really, really pre-release with our product our owner sat down and goes "ok this is bad, fix it" and "guys, stick to standards, and stop letting the client make you tweak stuff every time they call in."

I should mention that in effect we've let each dev have their own little set of styles, and for that matter let end users - probation officers, not designers or devs - basically dictate what a page should be like while ignoring the specs the client gave us, because the client has basically said so.

I'm quite glad we're doing it now and not later in the game.

# ? Mar 26, 2014 00:53

DaTroof: Nov 16, 2000; CC LIMERICK CONTEST GRAND CHAMPION
There once was a poster named Troof
Who was getting quite long in the toof

tef posted:

json is a crime against serialization formats. just simple enough to work and then everyone writes their own incompatible extensions atop to shoehorn in other data types.

If you really need to do that kind of thing with JSON, you might as well go full retard.

# ? Mar 26, 2014 03:27

Pythagoras a trois: Feb 19, 2004; I have a lot of points to make and I will make them later.

Apparently Microsoft released the source code for MS-DOS and Word for Windows? I found this article but I can't seem to track down the actual code:

http://blogs.technet.com/b/microsof...-to-public.aspx

# ? Mar 26, 2014 03:40

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 15:08

apseudonym: Feb 25, 2011

Suspicious Dish posted:

Of all the things I expect Crockford to "get right", a decimal floating point format is not one of them.

dec64_divide(0,0) = 0.

:smith:

# ? Mar 26, 2014 03:46

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!

«‹›1503 »