Live data from Hacker News

Learning (needlessly) hard technology

johndcook.com

41–50 of 55 posts

Re: Learning (needlessly) hard technology

#41
post #13
post #7

Seems to work well for SAP. I also have a suspicion that for example Java is so complicated because it was created by a consulting company - complex tech means high paid consultants.

I don't think Java the language is particularly complicated - it has a much simpler core than C++, which it sort of superseded in a lot of areas. People went a little nuts with the XML and ObjectBuilderFactoryFactory nonsense and all of the "enterprise" stuff, but you could create similar levels of insanity in any programming language, if the fad storm hits.

I think a lot of those people, at least initially, were employed by Sun. They came up with verbose Java naming, class libraries and other idioms. Also, they were the one who wrote J2EE specs and such. So it would be reasonable to say that Core Java developers set the tone of Java community at large.

Re: Learning (needlessly) hard technology

#42

>> If something really is unnecessarily complex, better alternatives are likely to arise, perhaps suddenly. I suspect that a good majority of corporate code assets trend toward becoming unnecessarily complex. After a certain level of complexity is reached, a company will often look for that better alternative and decide to rewrite from scratch. But in many/most cases of this that I know of, this attempt to recreate/r…

>> I wonder if that's what most developers out there are doing, maintaining complexity

Oh they are. No need to wonder.

Re: Learning (needlessly) hard technology

#43
post #33
post #24

Earlier quoted context omitted.

I've had to face the most horrible people with the most horrible requests.One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible.I understand maintaining a high quality of code.But a major part of the reason for using archaic/available-for-the-past-10-years technology is 2 fold: 1.The HPBs do not want to/cannot learn anything new l…

> One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible I assume you know it really is possible, right? (in URL parameters - with certain limitations about size if I remember correctly... or did just IE choke at 2048 bytes? I forget...) I am not arguing you should use GET instead of what should clearly be a POST, but saying it is…

But the AJAX spec says that if the the request type is GET,the body/data is set to null[1] or am I reading it wrong.

[1]:http://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-send

Re: Learning (needlessly) hard technology

#44
post #33
post #24

Earlier quoted context omitted.

I've had to face the most horrible people with the most horrible requests.One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible.I understand maintaining a high quality of code.But a major part of the reason for using archaic/available-for-the-past-10-years technology is 2 fold: 1.The HPBs do not want to/cannot learn anything new l…

> One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible I assume you know it really is possible, right? (in URL parameters - with certain limitations about size if I remember correctly... or did just IE choke at 2048 bytes? I forget...) I am not arguing you should use GET instead of what should clearly be a POST, but saying it is…

Do the servers really throw away the POST data on GET requests, like the RFC say they do?

Because that would be an easy place to send data.

Re: Learning (needlessly) hard technology

#45
post #33
post #24

Earlier quoted context omitted.

I've had to face the most horrible people with the most horrible requests.One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible.I understand maintaining a high quality of code.But a major part of the reason for using archaic/available-for-the-past-10-years technology is 2 fold: 1.The HPBs do not want to/cannot learn anything new l…

> One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible I assume you know it really is possible, right? (in URL parameters - with certain limitations about size if I remember correctly... or did just IE choke at 2048 bytes? I forget...) I am not arguing you should use GET instead of what should clearly be a POST, but saying it is…

And I agree with you. I was not even talking about rebuilding.Its more of.Like imagine if you were asked to make up http handling code from scratch in every project.If you were asked to ignore things like Jquery Ajax or Angular or any other such libraries which are designed to make your work easier and no matter how much you do you can never test the robustness of your private library compared to these. My Point essentially is: I do not want to reinvent the wheel every time.There are a large number of wheels in todays FOSS world.When I can concentrate on the things that matter like stream lining the business logic better,Why should is spend time trying to make framework level code work.

To summarize: You do not need to always rebuild or always stay with legacy code.You need to adapt and determine where would you spend more of your development effort.I cannot spend 80% of my time solving problems that the world has already solved

Re: Learning (needlessly) hard technology

#46
post #43
post #33

Earlier quoted context omitted.

> One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible I assume you know it really is possible, right? (in URL parameters - with certain limitations about size if I remember correctly... or did just IE choke at 2048 bytes? I forget...) I am not arguing you should use GET instead of what should clearly be a POST, but saying it is…

But the AJAX spec says that if the the request type is GET,the body/data is set to null[1] or am I reading it wrong. [1]: http://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-send

Depends on what you meant by "Payload" in the first comment. I assumed it to mean "a bunch of bytes", so you could have just used URL parameters, which don't have a standardised maximum length, but you can generally rely up to about 2,000[0] or so. If that wasn't enough, you could split up the requests like the other comments said[1], or go full hack-mode and use the cookies[2]. (using a Set-Cookie response header to clear them after the request was made)

Edit: Of course this isn't recommended, but I think the time wasted trying to convince the (seemingly terrible) manager could have been better spent.

[0] http://www.boutell.com/newfaq/misc/urllength.html

[1] https://news.ycombinator.com/item?id=10649995

[2] https://news.ycombinator.com/item?id=10650110

Re: Learning (needlessly) hard technology

#47
post #9
post #3

Perhaps what is "needlessly" hard (whatever that really means) to one is the exact right solution for someone else? Anyway, I can hardly think of a dumber way to spend my oh-so-valuable time then to spend it on learning a tech just because its "needlessly" hard (yes I know I'm overusing the parenthetical, for effect of course), but to each their own. To be honest, learning it as a strategy to bump up one's rates coul…

> Perhaps what is "needlessly" hard (whatever that really means) to one is the exact right solution for someone else? Trying to be everything to everyone is one of the surest ways I know to generate byzantine monstrosities. On the other hand, it takes some real nerve and discipline to tell 'No, that is not really what our product is about' to a paying customer.

Yet, extensible interfaces are often successfully used to create stuff that are everything for everybody.

It takes good engineering, and you still won't be able to say yes for every request (for lack of time if no other reason), but it does not require your product to be needlessly hard to use.

It's also not for every product. I just wanted to point that exceptions exist.

Re: Learning (needlessly) hard technology

#48

Good ol' accidental complexity and essential complexity. There's a nontrivial amount of technologies that are complex and otherwise byzantine for no reason. Given the lack of alternatives, knowing the arcane tech inside and out can provide for a sustained stream of money, but that's hardly ethical.

It's not always "no reason." Back the 1990s, GNU autoconf looked like a miracle to me, and in fact, back then you got better results compiling from source than you got using what passed for a package manager. These days people complain that autoconf is too complicated, being a bunch of shell scripts on top of shell scripts compiled with M4. Then there is SAP, which stands alone in its ability to destroy value. SAP st…

SAP is the perfect example to support learning hard tech for dollars. So many people get paid a premium to work on that stuff because nobody can get rid of it without risky moves.

Re: Learning (needlessly) hard technology

#49
What he's missing here is that this is a great strategy for any tech that will be hard to get rid of. Overly complex tech strongly integrated with businesses internal apps and procedures rarely disappear when something better comes along. Name a major company supplying enterprise software and there's probably better stuff. You don't see everyone flocking to it.

The concept is called lock-in. One can build a career strategy on it if done right. Just ask all the people working 9a-5p getting paid a premium to do SAP, legacy Microsoft, Oracle, COBOL on IBM mainframes, pipelines between legacy data sources/consumers, and so on. Some of this gets hit by outsourcing but many jobs remain. And one can always start an outsourcing consultancy with in-country, priority support or services. ;)

So, it's a valid approach that's working out for many much better than alternatives which require dozens of constantly changing skills and high layoff risks due to being replaceable & easy to automate. I'm not saying it's the best or lowest risk approach. You'll probably hate the career unless you see work as a means to an end to have fun in spare time. It's got lots of potential though.

Re: Learning (needlessly) hard technology

#50
post #7

Seems to work well for SAP. I also have a suspicion that for example Java is so complicated because it was created by a consulting company - complex tech means high paid consultants.

Java was created as simplification to other object and modular programming languages in the early 1990s - mainly C++ and ADA. Java added more features and class libraries as time went on.
Post reply on HN