Java call stack – from HTTP upto JDBC as a picture (2006) • Hacker News Board

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#61

Post by [deleted] » Thu, Mar 08, 2018, 10:30 PM UTC

jimbokun wrote: post #60

kuschku wrote: post #47

Earlier quoted context omitted.

Java has annotations, C/C++ has macros, every language from Lisp to Rust to Scala has some form of macros or annotations. These can often be very powerful, but of course debugging is more complicated.

Lisp macros are still just code, code that executes at compile time instead of run time. Code generated in response to an Java annotation is only loosely associated with the annotation itself. Annotation Oriented Programming arose out of Java's lack of powerful and general abstractions like first class functions. Lambda syntax for "single abstract method" interfaces has largely addressed that problem, but the use of…

[deleted]

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#62

Post by nickbauman » Thu, Mar 08, 2018, 11:32 PM UTC

jlg23 wrote: post #11

nickbauman wrote: post #7

The fact that Spring even exists should be a big red flag for the value of static typing. People routinely make mistakes using type systems. And when done correctly I see static type systems work very well solving problems that they themselves created.

How do you get from deeply nested method calls to "people routinely make mistakes using type systems"?

The gambit of static typing is that the type checker can attest correctness. But the result, if indeed that the type checker does this (provide a mechanism of provable correctness), you still have to deal with protocol bloat that type systems incur. Hence the deeply nested method calls: that's a result of adopting a static type system.

I'm saying that with all that overhead, people still routinely make mistakes using static typing systems. They get the compiler to tell them that they're correct but their code is still not working.

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#63

Post by harunurhan » Fri, Mar 09, 2018, 1:34 PM UTC

rhacker wrote: post #5

Not sure it is any smaller today. Some additional layers not seen are the DTO transformations (not seen because they don't become part of the stack when it's hitting JDBC) but two more major subsystems. Many IDEs now automatically filter out these well known stacks from view. Personally moving from a mostly Java background to entirely typescript on the backend and front-end.

Although I like TypeScript as a language, and use Node.js, also really appreciate sharing code such as (data types/interfaces etc.) btw frontend and backend, I think call stack is much worse on the side, especially when you start using frameworks. At least here you get a huge but relevant stack, you can find your business logic, but Node.js it's not rare to get irrelevant unhelpful stack traces which you can't figure out even if you dig in.