Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning (needlessly) hard technology

johndcook.com

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Learning (needlessly) hard technology

#21

Post by 1971genocide »

jacquesm wrote: post #15
Sumaso wrote: post #8

Earlier quoted context omitted.

I don't see how Java is more complicated than any other programming language. It certainly is not one of the more difficult ones. Assembly is complicated. C is arguably complicated. Java being complicated? I disagree.

Assembly and C are dead simple compared to Java. The C reference manual is about 200 pages, if I dropped the Java reference manual(s) from a building it would create a sizeable crater. Assembler is simple like lego is simple: the basics are tremendously easy to understand but the distance between the basic elements and the problems you're trying to solve is very large. The more 'batteries included' something is the m…

> The more 'batteries included' something is the more time you'll spend learning about the eco-system and less about the language per-se.

Not necessary. As a young programmer who did not grow up in the java dominated world of 1990-2008.

I took one look at Java and noped the fuck out.

I found C to be more useful.

But its hard to beat the simplicity of java-script.

Re: Learning (needlessly) hard technology

#22

Post by exelius »

brazzledazzle wrote: post #20
jmnicolas wrote: post #14

I immediately thought about Oracle, then IBM, then SAP ... it seems his friend didn't think about this first !

Some people thrive doing consulting for things like that because they're satisfaction is largely driven by how much they're taking home.

While this is true to some degree, IBM/Oracle/SAP solutions are complex because the requirements are ridiculously complex. Could the requirements be streamlined? Probably, but that would require a wholesale restructuring of the way the company does business. Which, again, will probably happen, but usually not before the company ventures down the path of an ERP implementation and realizes how needlessly complex their business is. But there is a market demand for these types of products; they don't solely exist to fund the increasing size of Larry Ellison's yacht (though maybe in Larry's mind they do).

The main school of thought in business these days is still organizational and process focused. Only the newer guys think of business in terms of products, SOAs, SDGs and APIs, and it'll take decades yet for that kind of thinking to fully infect corporate America.

Re: Learning (needlessly) hard technology

#23

Post by lultimouomo »

jacquesm wrote: post #15
Sumaso wrote: post #8

Earlier quoted context omitted.

I don't see how Java is more complicated than any other programming language. It certainly is not one of the more difficult ones. Assembly is complicated. C is arguably complicated. Java being complicated? I disagree.

Assembly and C are dead simple compared to Java. The C reference manual is about 200 pages, if I dropped the Java reference manual(s) from a building it would create a sizeable crater. Assembler is simple like lego is simple: the basics are tremendously easy to understand but the distance between the basic elements and the problems you're trying to solve is very large. The more 'batteries included' something is the m…

> Assembly and C are dead simple compared to Java. The C reference manual is about 200 pages, if I dropped the Java reference manual(s) from a building it would create a sizeable crater.

I don't think that's a fair assessment of Java. The full specification for version 8 is actually 788 pages, so 500 more than C, but you could reasonably argue that of those at least 100 are dedicated to specify what in C is simply undefined behavior and probably another 100 are dedicated to the memory model. The other 300 hundred would be a reasonable overhead for specifying classes and class loading.

You can say a lot of bad things about Java, but it could very well be the best specified language around; the spec is actually very readable, leaves no room for doubt and actually treats that thing called multithreading that still has no citizenship in the C language. You can't say that of a lot of languages.

EDIT:

I took the time of checking the C11 standard PDF (actually the latest available draft, as the ISO asserts copyright on the standard and you can't get it for free). It's 701 pages. But at least C11 has .

Re: Learning (needlessly) hard technology

#24

Post by shade23 »

pcote wrote: post #4

>> If something really is unnecessarily complex, better alternatives are likely to arise, perhaps suddenly. (This assumes people are free to choose alternatives, not prohibited by law, for example.) Not being free to pick alternatives is a common case. There are a lot of dev teams out there that have "approved technology lists". What gets on this list is decided by management and/or a lead architect. It can often be…

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 lest they need to one day code in those languages 2.They do not want to risk 'wasting time' of the sub-ordinates on learning something new which would benificial compared to actually doing the work needed.

Another third situation that I would agree with: Clients sometimes really do not like to trust new technology.An age old anecdote is always brought ; "Why fix what is working?"

Re: Learning (needlessly) hard technology

#25

Post by TheOtherHobbes »

Sumaso wrote: post #8
facepalm wrote: 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 see how Java is more complicated than any other programming language. It certainly is not one of the more difficult ones. Assembly is complicated. C is arguably complicated. Java being complicated? I disagree.

Assembly isn't complicated. The instruction list for most processors is small and easy to remember, because it's mostly variations on the same few operations.

It gets unwieldy if you try to build complex data structures, because you literally have to do everything the compiler would usually do. So if you're trying to build an incredibly complex machine with lots of objects and interfaces, it will take you a very long time.

Java is complicated because the culture is complicated. It's not just a language - it's a set of architectural practices and expectations, some of which are questionable, combined with a unfeasibly large ecosystem of libraries and add-ons.

So it's easy to learn the basics, but it's not so easy to get to the point where you can start producing high-quality maintainable code within a typical working context.

Re: Learning (needlessly) hard technology

#26

Post by hacknat »

shade23 wrote: post #24
pcote wrote: post #4

>> If something really is unnecessarily complex, better alternatives are likely to arise, perhaps suddenly. (This assumes people are free to choose alternatives, not prohibited by law, for example.) Not being free to pick alternatives is a common case. There are a lot of dev teams out there that have "approved technology lists". What gets on this list is decided by management and/or a lead architect. It can often be…

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…

Or, "No one ever got fired for picking Microsoft or IBM."

Re: Learning (needlessly) hard technology

#27

Post by wellpast »

>> 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/rebuild is found to be intractable.

What seems to happen is that more and more developers are hired to maintain the complexity and I wonder if that's what most developers out there are doing, maintaining complexity, which always makes me think the same thing:

>> That sounds like an unpleasant way to earn a living.

Re: Learning (needlessly) hard technology

#28

Post by jacquesm »

lultimouomo wrote: post #23
jacquesm wrote: post #15

Earlier quoted context omitted.

Assembly and C are dead simple compared to Java. The C reference manual is about 200 pages, if I dropped the Java reference manual(s) from a building it would create a sizeable crater. Assembler is simple like lego is simple: the basics are tremendously easy to understand but the distance between the basic elements and the problems you're trying to solve is very large. The more 'batteries included' something is the m…

> Assembly and C are dead simple compared to Java. The C reference manual is about 200 pages, if I dropped the Java reference manual(s) from a building it would create a sizeable crater. I don't think that's a fair assessment of Java. The full specification for version 8 is actually 788 pages, so 500 more than C, but you could reasonably argue that of those at least 100 are dedicated to specify what in C is simply un…

I just picked up my fairly dog eared K&R for that reference it's 226 pages (first edition). Yes, the C spec grew over the years, but the Java docs were huge right when it started out. I remember buying the full set and it weighed more than I could easily lift up the stairs to my office. All in all it amounted to a few thousand pages. This included the docs on the VM and a bunch of other stuff that you might not need (but which I did need).

The C standard library was a relatively small affair reflective of the way UNIX was built, a couple of well thought out interfaces combined with a lot of freedom (and enough rope to hang yourself several times over).

The Java standard library was absolutely huge and extremely hard to make headway in because each and every part of it seemed to be designed by a committee rather than by an individual (or two).

Re: Learning (needlessly) hard technology

#29

Post by sageikosa »

I long for the day PDF is finally expunged from the technical environment, in the meantime people still like to generate documents with it; and even with the variety of toolkits, frameworks and APIs, there's still a bit of knowledge needed to work with them efficiently.

I don't sell myself as a PDF expert, but my level of knowledge and experience is high enough that I can maintain and improve systems and workflows tightly bound to them. I keep it on my resume, but have no desire to mine that resource for fear of being the canary.

Re: Learning (needlessly) hard technology

#30

Post by reacweb »

auvi wrote: post #18

I have heard from a colleague that he has a friend who is an exceptional SharePoint expert and loathes it because of its complexity. Multiple times he flew to client locations around the US and changed a single line of code and got paid $$$ it.

All the oracle dba that would be jobless if oracle was not insane crap.
Post reply on HN