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

31–40 of 55 posts

Re: Learning (needlessly) hard technology

#31

Post by reitanqild »

1971genocide wrote: post #21
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…

> 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.

General problem of Java: It lacks decent onboarding.

I disliked java after school and was convinced I was hopeless so I didn't even bother to apply for Java jobs. Then I was recruited into a Java position and picked up the necessary skills to work during my first 4 days and improved steadily from there, but it only worked for me because I was on a good team.

Now it is me who helps people using Java more efficiently : )

Re: Learning (needlessly) hard technology

#33

Post by annnnd »

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…

> 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 not possible is IMHO misleading. And there are sometimes valid business reasons to use (invalid) technical solutions.

I understand your point, but neither extreme (always staying with legacy / always rebuilding) is particularly good.

Re: Learning (needlessly) hard technology

#34

Post by pc86 »

facepalm wrote: post #17
crpatino wrote: post #11

Earlier quoted context omitted.

What do you mean by Sun having been a consulting company?

I am no expert on Sun, but I think consulting was a huge part of their business? I know they were also well known for their servers.

s/no expert/completely wrong

Re: Learning (needlessly) hard technology

#35

Post by raverbashing »

ekidd wrote: post #16

It's unethical to inflict "needlessly hard" technologies on a client who isn't using them already. But an enormous fraction of the world's valuable, productive software is both needlessly complex and built using (arguably) obsolete tools and frameworks. The are good career reasons to think long and hard before specializing in this stuff. After all, once you go too far down the rabbit hole, you may not be able to clim…

> The are good career reasons to think long and hard before specializing in this stuff. After all, once you go too far down the rabbit hole, you may not be able to climb back out, and nobody wants to be a 35-year-old developer with a completely obsolete skill set.

Exactly

Also you spent time learning something completely unusable beyond a certain niche, that usually does not transport anywhere back to "sanity land"

I'm strongly opposed learning something that will be good for nothing beyond actually making the wheels of bureaucracy and/or legacy turn

Re: Learning (needlessly) hard technology

#36

Post by jcranmer »

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…

It's interesting that you try to compare simplicity via manual length and say in the same breath that assembly is simple. Assembly language manuals easily dwarf most programming languages: x86-64 is a whopping 3439 pages (of which ~1500 pages is the instruction set reference). And before you say that's just because x86 is unnecessarily complex, ARM is 1138 pages, PowerPC 640 pages. By comparison, the JLS is only about 800 pages, C11 sans library about 450, and C++14 sans library about 500.

Re: Learning (needlessly) hard technology

#37

Post by jacquesm »

jcranmer wrote: post #36
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…

It's interesting that you try to compare simplicity via manual length and say in the same breath that assembly is simple. Assembly language manuals easily dwarf most programming languages: x86-64 is a whopping 3439 pages (of which ~1500 pages is the instruction set reference). And before you say that's just because x86 is unnecessarily complex, ARM is 1138 pages, PowerPC 640 pages. By comparison, the JLS is only abou…

The bricks are simple but there are many of them. When I say that assembly language is simple I mean exactly that. The language is simple. If you know what one mnemonic does you'll be able to infer the existence and function of a whole bunch of others since they're usually organized around a matrix of operations and locations to be operated on. Of course a manufacturer would document each and every instruction separately but if you understand the logic behind an instruction set then you have a much easier time of it.

The x86 set, well, let's not go there, it's just too painful.

Re: Learning (needlessly) hard technology

#38

Post by JoeAltmaier »

jcranmer wrote: post #36
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…

It's interesting that you try to compare simplicity via manual length and say in the same breath that assembly is simple. Assembly language manuals easily dwarf most programming languages: x86-64 is a whopping 3439 pages (of which ~1500 pages is the instruction set reference). And before you say that's just because x86 is unnecessarily complex, ARM is 1138 pages, PowerPC 640 pages. By comparison, the JLS is only abou…

Assembly may not be simple, as in 'very little language'. Assembly can be thousands of different language elements. But assembly is simple as in 'very little variation'. There are maybe a dozen addressing modes. There may be 100 or more instructions. When you multiply them, you get large manuals.

And assembly is simple as in 'primitive'. The atoms of assembler are instructions, and even they may be clustered into only a few groups i.e. arithmetic, branch.

I find the resistance to learning assembler is mostly fear. When debugging I very often resort to assembler display, even for machines that I'm not familiar with. I can learn the gist of it in a few minutes just by looking at a little generated code. And there's nothing like the actual machine instructions to find what really caused an exception.

Re: Learning (needlessly) hard technology

#39

Post by ant6n »

annnnd wrote: post #33
shade23 wrote: 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…

Maybe one could try to split up the payload into mutiple GET-request packets, then assemble them server-side. >:‑)

Re: Learning (needlessly) hard technology

#40

Post by vpribish »

ant6n wrote: post #39
annnnd wrote: 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…

Maybe one could try to split up the payload into mutiple GET-request packets, then assemble them server-side. >:‑)

don't forget all that storage space in the cookies too!
Post reply on HN