If you can read this, either the style sheet didn't load or you have an older browser that doesn't support style sheets. Try clearing your browser cache and refreshing the page.

(Tiobe)   If you ever griped about JavaScript, Ruby, Perl, Python, PHP, VisualBasic, C# or C++, well, Objective-C is now more popular than any of those. If that doesn't make you happy, what will?   (tiobe.com) divider line 159
    More: Unlikely, Visual Basic, PHP, JavaScript  
•       •       •

2176 clicks; posted to Geek » on 06 Jul 2012 at 10:11 AM (2 years ago)   |  Favorite    |   share:  Share on Twitter share via Email Share on Facebook   more»



159 Comments   (+0 »)
   
View Voting Results: Smartest and Funniest

Archived thread

First | « | 1 | 2 | 3 | 4 | » | Last | Show all
 
2012-07-06 11:58:10 AM  

Nexzus: I only program in Malbodge


Chef is beats the eggs out of Malbodge
 
2012-07-06 12:03:04 PM  

hallotavagyna: t3knomanser: hallotavagyna: var whatever

JSON isn't a programming language. It's a data-interchange format. And, like all data-interchange formats, developers should never interact with it directly.

Right.. javascript would be the language of choice to parse that data.


Hardly. JSON is only popular because it's ridiculously easy to parse or produce. It doesn't even matter what language you're in.

And, what do you mean "...And, like all data-interchange formats, developers should never interact with it directly".... ????

Seriously? Explain this to me.


Why should anyone be writing a JSON parser at this point? There's already several, for any language out there. If you're writing a JSON parser, odds are extremely good that you're doing something wrong.
 
Zel
2012-07-06 12:08:05 PM  

hallotavagyna: t3knomanser: hallotavagyna: var whatever

JSON isn't a programming language. It's a data-interchange format. And, like all data-interchange formats, developers should never interact with it directly.

Right.. javascript would be the language of choice to parse that data.

And, what do you mean "...And, like all data-interchange formats, developers should never interact with it directly".... ????

Seriously? Explain this to me.

//I was more-or-less saying that javascript is where it's at.


Except you forgot to mention javascript. It's like saying you love to program in ajax or c-pound.

You should never write an xml parser, you should write apps that talk to an xml library! Same goes for json, to a lesser extent.
 
2012-07-06 12:17:00 PM  

LouDobbsAwaaaay: wildcardjack: LouDobbsAwaaaay: fortran 90!

/stuck there forever

Did you have professor Groendyke also?

Atmospheric science. We were very early adopters in computers (one guy named Richardson even had an idea for a "computer" made from a bunch of dudes in a room cranking through equations to predict the weather, before the advent of the much less lame electronic computer), and we stuck to fortran. I don't know if anyone else uses it at this point, but even modern weather prediction models are written in fortran.


I could swear that my friend (forecast meteorology IIRC) used Fortran 95.
 
2012-07-06 12:24:58 PM  

armanox: I could swear that my friend (forecast meteorology IIRC) used Fortran 95.


There are several brands that developed over the years, and as long as they are backward compatible they're fine. But the bulk of the code that's written for models is in *.f90, from what I've seen. I've cracked open the WRF (the current standard for research) as well as two operational models, and it's almost all in fortran 90. If there are advantages to later versions of fortran, they haven't made themselves particularly well-known to the wx community.
 
ZAZ [TotalFark]
2012-07-06 12:25:58 PM  
even modern weather prediction models are written in fortran.

Fortran has friendly to vectorization since before C existed while C implementors spent years trying to figure out why requiring code like

double f(double * restrict noalias __attribute__((input_dependency(bar))) __declspec(Redmond) foo) {
#pragma vector safe
return foo[0] + foo[1];
#pragma vector unsafe
}

sent customers running away.
 
2012-07-06 12:34:57 PM  
Who says' I'm writing

Zel: hallotavagyna: t3knomanser: hallotavagyna: var whatever

......

Except you forgot to mention javascript. It's like saying you love to program in ajax or c-pound.

You should never write an xml parser, you should write apps that talk to an xml library! Same goes for json, to a lesser extent.


Fair enough.. I need more coffee. I should have simply said JavaScript after I got all smart-assey with the json I wrote.

Here is my pride and joy:

http://www.stubhub.com/san-francisco-giants-tickets/giants-vs-padres- 7 -23-2012-2032177/

...I wrote the logic on this page that parses the ticket table, and built the map off of the Google Maps API. Both the ticket table, and the maps interact with each other. Several thousand lines of code and 10 months to build.

This was hands-down the most difficult thing I've ever worked on. The filters interact with the seat map, and the ticket list. And.. you can zoom into the row level. The Google Maps API was fun to learn.
 
2012-07-06 12:46:36 PM  
i.qkme.me

/Fark you, Java.
//That is all.
///return 0;
 
2012-07-06 12:53:57 PM  
This website requires JavaScript.

No, no it farking doesn't.
 
2012-07-06 12:58:12 PM  

Abner Doon: hallotavagyna: t3knomanser: hallotavagyna: var whatever

JSON isn't a programming language. It's a data-interchange format. And, like all data-interchange formats, developers should never interact with it directly.

Right.. javascript would be the language of choice to parse that data.

Hardly. JSON is only popular because it's ridiculously easy to parse or produce. It doesn't even matter what language you're in.

And, what do you mean "...And, like all data-interchange formats, developers should never interact with it directly".... ????

Seriously? Explain this to me.

Why should anyone be writing a JSON parser at this point? There's already several, for any language out there. If you're writing a JSON parser, odds are extremely good that you're doing something wrong.


I have not hired many people with "I wrote my own parser for [insert interchange format here] that did not answer the question 'Why did you do that?' with an answer other than 'As an academic exercise.'"

I do not need wheel inventors. Fire inventors are even worse.
 
2012-07-06 01:07:21 PM  
Abner DoonIf you're writing a JSON parser, odds are extremely good that you're doing something wrong.

Considering the crapton of available Java JSON libraries, one could argue that nobody has gotten it right.

For example, when I started using one for a project a few years ago, I simply got the org.json one (there might have been fewer choices back then). Pretty soon I ended up getting its source to e.g. stop the parser from blowing up if it encounters some unexpected unicode character or whatever.
----------

In case anybody reading this needs a Java library and is considering to simply throw a dart at the list:
Another thing I find a little bit annoying about the org.json one is the decision to throw an Exception if you do something like "jsonobject.get(key)" and there's no "key" in "jsonobject".
Just returning "null" like Java's collection classes do would feel more natural and be less annoying than handling Exceptions or always doing something like "value = jsonobject.has(key)?jsonobject.get(key):nullOrSomeDefaultValueOrWhatev er;"
Then again, most people who aren't me or aren't coding defensively won't really have to care about that because most people probably don't parse JSON that can change without prior notification.


----------

I've actually been thinking about writinga couple of interfaces or wrapper classes for the stuff I usually do with JSON so that I can try different JSON libraries without having to change dozens of classes every time.
Or maybe there already is one? You know, something SAX-like.
Service provider interfaces and abstraction like that is pretty common in Java/J2EE
 
2012-07-06 01:08:09 PM  

hallotavagyna: Who says' I'm writing Zel: hallotavagyna: t3knomanser: hallotavagyna: var whatever

......

Except you forgot to mention javascript. It's like saying you love to program in ajax or c-pound.

You should never write an xml parser, you should write apps that talk to an xml library! Same goes for json, to a lesser extent.

Fair enough.. I need more coffee. I should have simply said JavaScript after I got all smart-assey with the json I wrote.

Here is my pride and joy:

http://www.stubhub.com/san-francisco-giants-tickets/giants-vs-padres- 7 -23-2012-2032177/

...I wrote the logic on this page that parses the ticket table, and built the map off of the Google Maps API. Both the ticket table, and the maps interact with each other. Several thousand lines of code and 10 months to build.

This was hands-down the most difficult thing I've ever worked on. The filters interact with the seat map, and the ticket list. And.. you can zoom into the row level. The Google Maps API was fun to learn.


That... took 10 months???
 
2012-07-06 01:09:00 PM  
...I have not hired many people with "I wrote my own parser for [insert interchange format here] that did not answer the question 'Why did you do that?' with an answer other than 'As an academic exercise.'"

I do not need wheel inventors. Fire inventors are even worse.

jQuery + JSON = match made in heaven. All is solved. And.. when I get laid off / fired / quit, someone with some very basic javascript programming experience should be able to step in and understand what I wrote.

Fire Inventors! HA!
 
2012-07-06 01:09:40 PM  
bold type is bold..
 
2012-07-06 01:14:18 PM  
java.lang.NullPointerException caused by: This stupid article.
 
2012-07-06 01:16:29 PM  
The Voice of Doom
Abner Doon
If you're writing a JSON parser, odds are extremely good that you're doing something wrong.

Considering the crapton of available Java JSON libraries, one could argue that nobody has gotten it right.


i.imgur.com
 
rpm
2012-07-06 01:16:35 PM  

hallotavagyna: Right.. javascript would be the language of choice to parse that data.


If you're a programmer, quit now, save us all a lot of problems.

It is far from the language of choice to parse that data. There's probably more C parsers (mongo, and WTF do you think JavaScript interpreter itself is written in?)
 
2012-07-06 01:18:31 PM  

Shazam999: hallotavagyna: Who says' I'm writing Zel: hallotavagyna: t3knomanser: hallotavagyna: var whatever

......
.....

That... took 10 months???


Yup. Basically, it was a whole bunch of trail and error. We initially built it with Google Maps, then Google said "sorry - that's going to cost you a million dollars per year to use our API, so we went to Bing, and bing said, sure! You can use our map API for 100k per year. So we built it with BING. Then Google came back and said "well, we don't want the competition to get the upper hand, so lets work something out. So we ended up scrapping all of the Bing work, and re-implementing with Google Maps instead.

And.. then we got into cross browser compatibility issues. IE7 hangs with a json response larger than 20k records. So, we had to find a way to break up the response into record sets of 2k or less; recompile and store the response in memory, then parse the data so that the browser doesn't hang/lock up.

I had to build a custom tool that a team in India used to trace the maps - ALL Major League teams (NFL, MLB, NHL, etc...) and basically any venue out there that has tix for sale. Something like 1,200 venues. It looks simple, but there were a ton of underlying issues that needed to be addressed.
 
2012-07-06 01:19:43 PM  
Somehow, I find the idea that Objective-C is more popular than C/C++ incredibly hard to believe.

Enjoy having programming skills that won't transfer outside of a specific market space, kiddies.

/Does C and C#
//If C# was made open it'd become the language to rule all languages
///Even more so if you could run it sans CLR
 
2012-07-06 01:23:05 PM  

hallotavagyna: Shazam999: hallotavagyna: Who says' I'm writing Zel: hallotavagyna: t3knomanser: hallotavagyna: var whatever

......
.....

That... took 10 months???

Yup. Basically, it was a whole bunch of trail and error. We initially built it with Google Maps, then Google said "sorry - that's going to cost you a million dollars per year to use our API, so we went to Bing, and bing said, sure! You can use our map API for 100k per year. So we built it with BING. Then Google came back and said "well, we don't want the competition to get the upper hand, so lets work something out. So we ended up scrapping all of the Bing work, and re-implementing with Google Maps instead.

And.. then we got into cross browser compatibility issues. IE7 hangs with a json response larger than 20k records. So, we had to find a way to break up the response into record sets of 2k or less; recompile and store the response in memory, then parse the data so that the browser doesn't hang/lock up.

I had to build a custom tool that a team in India used to trace the maps - ALL Major League teams (NFL, MLB, NHL, etc...) and basically any venue out there that has tix for sale. Something like 1,200 venues. It looks simple, but there were a ton of underlying issues that needed to be addressed.


You should have known about the licensing costs before you start the project. Yes, it costs a butt-ton, just like all Google products.

I would've fired the decision maker at that point, but hey, what do I know.
 
2012-07-06 01:23:37 PM  
Bullshiat.
 
2012-07-06 01:24:24 PM  

hallotavagyna: javascript would be the language of choice to parse that data


JSON is not JavaScript. It's a subset of JavaScript.

hallotavagyna: And, what do you mean "...And, like all data-interchange formats, developers should never interact with it directly".... ????


I'm currently working on an application with .NET MVC on the back-end and KnockoutJS/jQuery on the front-end. I never touch a JSON object directly, except for debugging purposes. I let .NET MVC handle serializing my server-side ViewModel classes into JSON, and I let jQuery/Knockout do the heavy lifting of turning the JSON into typed VIewModel objects on the client.

JSON might glue them together, but I have no interest in interacting with JSON directly.
 
2012-07-06 01:25:49 PM  

hallotavagyna: t3knomanser: hallotavagyna: var whatever

JSON isn't a programming language. It's a data-interchange format. And, like all data-interchange formats, developers should never interact with it directly.

Right.. javascript would be the language of choice to parse that data.

And, what do you mean "...And, like all data-interchange formats, developers should never interact with it directly".... ????

Seriously? Explain this to me.

//I was more-or-less saying that javascript is where it's at.


I believe he was saying with any good data interchange, developers shouldn't have to parse it themselves. When JSON first came out, we had to do most of the parsing ourselves. Fortunately, most programming languages now come with JSON support that automatically converts it for us into or from usable objects.
 
2012-07-06 01:26:12 PM  

rpm: hallotavagyna: Right.. javascript would be the language of choice to parse that data.

If you're a programmer, quit now, save us all a lot of problems.

It is far from the language of choice to parse that data. There's probably more C parsers (mongo, and WTF do you think JavaScript interpreter itself is written in?)


And you should have quit a long time ago to save us hip programmers some embarrassment!

You are that guy that does everything on a round-trip to the server. Shave your neck beard, get a fixie and a plaid shirt and get all "web two.osey"

Give me a .jsonp response and I'll do some magic in the browser! I'll get all "ajax" on that ass..
 
2012-07-06 01:26:31 PM  
Also, obligatory.
 
2012-07-06 01:39:07 PM  
hallotavagyna
And you should have quit a long time ago to save us hip programmers some embarrassment!
You are that guy that does everything on a round-trip to the server.


hallotavagyna
And.. then we got into cross browser compatibility issues. IE7 hangs with a json response larger than 20k records. So, we had to find a way to break up the response into record sets of 2k or less; recompile and store the response in memory, then parse the data so that the browser doesn't hang/lock up


Sounds like you could have used someone like him.
 
2012-07-06 01:43:21 PM  

The Voice of Doom: hallotavagyna
And you should have quit a long time ago to save us hip programmers some embarrassment!
You are that guy that does everything on a round-trip to the server.

hallotavagyna
And.. then we got into cross browser compatibility issues. IE7 hangs with a json response larger than 20k records. So, we had to find a way to break up the response into record sets of 2k or less; recompile and store the response in memory, then parse the data so that the browser doesn't hang/lock up

Sounds like you could have used someone like him.


A good programmer will find a way to overcome obstacles. We did consider that, but management said "no round trip to the server" as they wanted to make this functionality into an API. Intercepting the response, then breaking it up into several different arrays did the trick.
 
2012-07-06 01:49:48 PM  

hallotavagyna: but management said "no round trip to the server"


Management should have been told to piss up a rope. They have no business defining the technical details of how an application is implemented.

There are times to do round-trips to a server. There are times to do everything on the client. There are times where you mix the two. A good developer with years of experience will be able to tell which situation is which. Management can't tell their heads from their assholes.
 
ZAZ [TotalFark]
2012-07-06 01:59:29 PM  
My management, years ago, forced one page of our web UI to reload every second so the time displayed in that frame would be correct. Why our UI had to include a clock was unclear.
 
2012-07-06 02:06:41 PM  

ZAZ: My management, years ago, forced one page of our web UI to reload every second so the time displayed in that frame would be correct. Why our UI had to include a clock was unclear.


I had to pitch our internal solution for a travel and expense voucher system to our own management, that was considering buying someone else's.

My team's solution could split expense line items, which was a FARKING REQUIREMENT. The vendor we were competing against could not. To me, that should have been sufficient. But at a meeting in front of management, with both my team and the vendor making our pitches, one of our own managers asked of our solution, "That's nice and all but are you really going to use that color?"

That event precipitated my departure from the company.
 
2012-07-06 02:09:22 PM  

hallotavagyna: var whatever {
"why-this-article-is-retarded":[
"json":"more popular",
"json":"widely used",
"json":"data can be shared from one site to another",
"json":"json is the backbone of nearly all websites now days",
"json":"it's simple to use once you get your head around it",
"json":"it's all about ease of use and being a stud with 'for' loops",
"json":"do you use anything google or facebook? Then you use json"
]
}


json is a programming language?
 
2012-07-06 02:12:13 PM  

t3knomanser: hallotavagyna: but management said "no round trip to the server"

Management should have been told to piss up a rope. They have no business defining the technical details of how an application is implemented.

There are times to do round-trips to a server. There are times to do everything on the client. There are times where you mix the two. A good developer with years of experience will be able to tell which situation is which. Management can't tell their heads from their assholes.


The reason we didn't do client side was because of the filters on the page (the price slider, zones, seats together). When those filters change, we redraw the ticket table. A round-trip back to the server would have been pretty expensive and annoying for the end user. If the browser refreshed every time I changed the price, I would leave the website and go find tickets somewhere else. Client side was the only way to go with this gig.
 
2012-07-06 02:13:16 PM  
sorry -

"The reason we didn't do server side was because of the filters on the page"
 
2012-07-06 02:19:16 PM  
hallotavagyna
A good programmer will find a way to overcome obstacles. We did consider that, but management said "no round trip to the server" as they wanted to make this functionality into an API. Intercepting the response, then breaking it up into several different arrays did the trick.


I'm just wondering why more than 20k records had to be sent to the client:
"Your search returned 20k results. Here, have them are all at once behind the scenes."

Your managers aren't by any chance the ones behind complex.com's compacted Javascript slideshows that result in 300000+ characters (or maybe even lines?! I don't remember) of HTML-Javascript-CSS-mix once their Javascript is done uncompressing the data on the client, assuming the client didn't crash?
Well, probably not, because you would have used JSON and that would probably have resulted in filling a single HTML fragment template from a JSON array and knocked off two or three zeros from the 300,000...
 
2012-07-06 03:07:54 PM  

t3knomanser: Management can't tell their heads from their assholes.


They're often the same thing.
 
2012-07-06 03:09:00 PM  
hallotavagyna
When those filters change, we redraw the ticket table. A round-trip back to the server would have been pretty expensive and annoying for the end user. If the browser refreshed every time I changed the price, I would leave the website and go find tickets somewhere else. Client side was the only way to go with this gig.

You're showing like, what, 20 tickets at a time?
My first instinct would be to build the system in a way that a filter change triggers a new query with the updated set of filters and a range limit for the results so the client only gets what it actually needs; then use the updated data to update only the ticket table entries and the overlay for the seating map.
Then again, I don't know how fast/slow your backend is.

---

Actually..to me that feels not that "web two.osey" /AJAXy what you're doing there:
It looks like you have the client basically downloading the entire database (well a biggish search result) and then run a Javascript and do everything client-side and only use AJAX for user tracking and error reporting.
In fact, I've seen someone do something similar "web two.osey" with paging through search results back in 1999(*).

Hm, that approach might kinda suck if multiple people are browsing the same event and they happen to select tickets that aren't available anymore.
Then again, that's probably pretty rare. And it will happen in one way or another no matter how you build the system because you would have to be able to push updates to the client to avoid it.

(*)
He was (ab)using layers for Netscape3/4
I encountered this when the customer called a few years later because browsing through search results had stopped working - Netscape had gone Mozilla and dropped their "layer" support for the more standards-compliant div (no, it had never worked with IE. The customer was a Netscape-only shop so their requirements only included Netscape compatibility).
 
2012-07-06 03:27:47 PM  
My big beef with most C++ code I've seen - For most, it's just a way for people to write crappy C.Try/catch/throw blocks are just glorified gotos. Defining variables whereverthehell they want to. Creating huge classes that are nothing more than function calls that don't need to be in classes. Etc... I'd desperately like to see some *GOOD* C++ code, but there's so little out there. ;-(
 
2012-07-06 03:32:21 PM  

Grither:

Wait, C++ and C# are different? I thought people were just too lazy to type out the ++ and though they were being clever by replacing it with #. What the hell is wrong with you people?!


that was one loud lol.

/c# dev. learning me some (more) rails this weekend so I can deploy a friend's site to heroku for the frees.
 
2012-07-06 03:33:18 PM  

neilbradley: My big beef with most C++ code I've seen - For most, it's just a way for people to write crappy C.Try/catch/throw blocks are just glorified gotos. Defining variables whereverthehell they want to. Creating huge classes that are nothing more than function calls that don't need to be in classes. Etc... I'd desperately like to see some *GOOD* C++ code, but there's so little out there. ;-(


I hate to break this to you, but your code sucks, too.
 
2012-07-06 03:37:59 PM  

Rent Party: neilbradley: My big beef with most C++ code I've seen - For most, it's just a way for people to write crappy C.Try/catch/throw blocks are just glorified gotos. Defining variables whereverthehell they want to. Creating huge classes that are nothing more than function calls that don't need to be in classes. Etc... I'd desperately like to see some *GOOD* C++ code, but there's so little out there. ;-(

I hate to break this to you, but your code sucks, too.


everyone's code sucks. (mine even says so in my commit messages)

/still trying to figure out how people can think using languages while not understanding them is a good thing.
 
2012-07-06 03:44:17 PM  

thisone: Rent Party: neilbradley: My big beef with most C++ code I've seen - For most, it's just a way for people to write crappy C.Try/catch/throw blocks are just glorified gotos. Defining variables whereverthehell they want to. Creating huge classes that are nothing more than function calls that don't need to be in classes. Etc... I'd desperately like to see some *GOOD* C++ code, but there's so little out there. ;-(

I hate to break this to you, but your code sucks, too.

everyone's code sucks. (mine even says so in my commit messages)



You can work for me. "Everyone's code sucks" is the 1st rule of my teams. It is what drives us to document what we're doing. We write for the maintenance guy that will replace us, not the fairy princesses that we all know we are.
 
2012-07-06 04:02:36 PM  

thisone: Rent Party: neilbradley: My big beef with most C++ code I've seen - For most, it's just a way for people to write crappy C.Try/catch/throw blocks are just glorified gotos. Defining variables whereverthehell they want to. Creating huge classes that are nothing more than function calls that don't need to be in classes. Etc... I'd desperately like to see some *GOOD* C++ code, but there's so little out there. ;-(

I hate to break this to you, but your code sucks, too.

everyone's code sucks. (mine even says so in my commit messages)

/still trying to figure out how people can think using languages while not understanding them is a good thing.


That was exactly the point I was making with my original post. ;-) Thank you for putting it so succinctly. I don't understand C++ as well as I should, which is why I don't use it...
 
2012-07-06 04:20:45 PM  

Rent Party: thisone: Rent Party: neilbradley: My big beef with most C++ code I've seen - For most, it's just a way for people to write crappy C.Try/catch/throw blocks are just glorified gotos. Defining variables whereverthehell they want to. Creating huge classes that are nothing more than function calls that don't need to be in classes. Etc... I'd desperately like to see some *GOOD* C++ code, but there's so little out there. ;-(

I hate to break this to you, but your code sucks, too.

everyone's code sucks. (mine even says so in my commit messages)



You can work for me. "Everyone's code sucks" is the 1st rule of my teams. It is what drives us to document what we're doing. We write for the maintenance guy that will replace us, not the fairy princesses that we all know we are.


hang on, you mean to tell me there are teams out there where I don't have to pick my words very carefully when asking if there's a reason a class is being newed up all the damn time for one stand-alone method instead of just making the method static?
 
2012-07-06 04:24:15 PM  

The Voice of Doom: You're showing like, what, 20 tickets at a time?
My first instinct would be to build the system in a way that a filter change triggers a new query with the updated set of filters and a range limit for the results so the client only gets what it actually needs; then use the updated data to update only the ticket table entries and the overlay for the seating map.
Then again, I don't know how fast/slow your backend is.


Yeah, this. Although every browser out there has made considerable JavaScript improvements over the past few years, odds are your backend could probably do this faster. I'd have made a query API that takes in the filters and the usual sort/order/offset/limit stuff, then returns only what you need. When you change the filters onscreen, call the API and use the callback to redraw things. Maybe stick memcached or something in front of it to handle the really popular queries (like whatever your default is).
 
2012-07-06 04:33:14 PM  

Lego_Addict: Nexzus: I only program in Malbodge

Chef is beats the eggs out of Malbodge


Hah. I never thought a joke programming language would make me laugh.


Take ingredient from refrigerator.
This reads a numeric value from STDIN into the ingredient named, overwriting any previous value
 
2012-07-06 04:43:21 PM  
"Where's My Coffee, Intern?" productions proudly presents
'Hallotavagyna : Ballad of an Illiterate, Insecure Jr. Developer'


hallotavagyna: var whatever {
"why-this-article-is-retarded":[
"json":"more popular",
"json":"widely used",
"json":"data can be shared from one site to another",
"json":"json is the backbone of nearly all websites now days",
"json":"it's simple to use once you get your head around it",
"json":"it's all about ease of use and being a stud with 'for' loops",
"json":"do you use anything google or facebook? Then you use json"
]
}



....
[Several cringe-inducing posts later]
....


hallotavagyna: And you should have quit a long time ago to save us hip programmers some embarrassment!

You are that guy that does everything on a round-trip to the server. Shave your neck beard, get a fixie and a plaid shirt and get all "web two.osey"

Give me a .jsonp response and I'll do some magic in the browser! I'll get all "ajax" on that ass..


i.imgur.com
 
2012-07-06 04:50:29 PM  

thisone: Rent Party: thisone: Rent Party: neilbradley: My big beef with most C++ code I've seen - For most, it's just a way for people to write crappy C.Try/catch/throw blocks are just glorified gotos. Defining variables whereverthehell they want to. Creating huge classes that are nothing more than function calls that don't need to be in classes. Etc... I'd desperately like to see some *GOOD* C++ code, but there's so little out there. ;-(

I hate to break this to you, but your code sucks, too.

everyone's code sucks. (mine even says so in my commit messages)



You can work for me. "Everyone's code sucks" is the 1st rule of my teams. It is what drives us to document what we're doing. We write for the maintenance guy that will replace us, not the fairy princesses that we all know we are.

hang on, you mean to tell me there are teams out there where I don't have to pick my words very carefully when asking if there's a reason a class is being newed up all the damn time for one stand-alone method instead of just making the method static?


Yes, these places do exist. Weekly "please beat me up" code inspections (where we don't congratulate each other on how clever we are) are the norm.
 
ZAZ [TotalFark]
2012-07-06 05:04:05 PM  
As long as we're bashing languages, here's a valid C++ function definition under the new standard:

auto f()->void{[]{}();}

I know somebody who had reason to use the []{}() construct. He needed a function call but didn't need it to do anything. It's the same "((lambda()())" in Scheme.
 
2012-07-06 05:09:40 PM  

Rent Party: thisone: Rent Party: thisone: Rent Party: neilbradley: My big beef with most C++ code I've seen - For most, it's just a way for people to write crappy C.Try/catch/throw blocks are just glorified gotos. Defining variables whereverthehell they want to. Creating huge classes that are nothing more than function calls that don't need to be in classes. Etc... I'd desperately like to see some *GOOD* C++ code, but there's so little out there. ;-(

I hate to break this to you, but your code sucks, too.

everyone's code sucks. (mine even says so in my commit messages)



You can work for me. "Everyone's code sucks" is the 1st rule of my teams. It is what drives us to document what we're doing. We write for the maintenance guy that will replace us, not the fairy princesses that we all know we are.

hang on, you mean to tell me there are teams out there where I don't have to pick my words very carefully when asking if there's a reason a class is being newed up all the damn time for one stand-alone method instead of just making the method static?

Yes, these places do exist. Weekly "please beat me up" code inspections (where we don't congratulate each other on how clever we are) are the norm.


dude, you're gonna make me cry (out of desperation). Next your going to tell me you get specs.
 
2012-07-06 05:15:20 PM  

thisone:

dude, you're gonna make me cry (out of desperation). Next your going to tell me you get specs.


We don't write until we have them. And even more, if there is some confusion on what the spec is, we make the business owner clarify it. And when it comes to priorities, anyone that says "They're all top priority!" is immediately killed and eaten.

/ OK. I made that last part up. We just tell them they can't have all of them unless they trade us more time.
 
Displayed 50 of 159 comments

First | « | 1 | 2 | 3 | 4 | » | Last | Show all

View Voting Results: Smartest and Funniest


This thread is archived, and closed to new comments.

Continue Farking
Submit a Link »






Report