3 ms·

> * Spring startup config (this is basically coding in another XML-based language) The alternative of manually wiring up beans or giving up and using shitty si

by agentgt 10y ago

> * Spring startup config (this is basically coding in another XML-based language) The alternative of manually wiring up beans or giving up and using shitty singleton patterns is pretty awful (remember this was preannotation days). A pretty sexy annotation DI these days is Dagger2 but alas you seem to hate annotations. > * JSPs (again, programming in a new XML-based language) That is not an XML language unless you are talking about JSPX or JSF. It is a crappy templating language. Lots of languages have those (like PHP had Smarty or Pear...). I totally agree JSP and the future JSF was a horrible addition to Java. > * Maven Config (IMO incredibly painful-to-use XML-based language) A config that your IDE instantly knows how to properly setup and allows for massively powerful inheritance (see super poms). If you import a Maven project with Eclipse or IntelliJ it just works. Now I admit Maven is verbose and has lots of baggage but it has some serious pros and a lot of those pros are actually because it uses XML (like Eclipse can automatically adjust your Maven file without changing formatting). I have scripts that I have written in many languages (bash, python, etc) that can read Maven POM files thanks to XML. You can't do this with Gradle. > * Hibernate config, mapping files Yep that sucked but you hate annotations... so I guess you propose programmatically doing the mappings? I despite hibernate anyway. > * Tomcat config (basically a pre-cursor to Spring in some sense) Oh like Apache config is any better. I mean seriously Apache has made up weird SGML config. > Java is not a dynamic language, sorry. The JVM bytecode is fairly dynamic, but the language certainly isn't. It is a dynamic language. You can instantiate classes by string names and manipulate their bytecode on the fly. You can call methods dynamically as well. Yeah it doesn't have the ease of metaprogramming like Ruby or Python but its its there through libraries (CGLIB). Honestly I'm not sure what you mean by dynamic (please cite something) but I guess you mean interpreted and even that is sort of wrong as well (bytecode is interpreted by the JVM). > Also, I think Java would have been better off never introducing annotations Annotations also allow for preprocessing aka light weight macros. A full macro system probably would have been better. I look forward to your blog post (in all honesty).

sreque 10y ago
You asked for examples and that proceeded to defend almost all of the ones I listed, which basically proves my point that this is how things work in the Java community. You can call things via reflection, therefore the language is dynamic? You have a strange definition of what makes a language dynamic. By that definition just about every language is dynamic. In C/C++ I can dynamically load symbols, call functions by string names, call C++ constructor functions, etc. I've never in practice seen anyone use compile-time annotation processors. In practice, annotations define runtime global variables that some frameworks make use of by doing expensive classpath scanning on startup to add or rewrite bytecode at runtime. These frameworks basically help cement java's reputation for having incredibly slow startup times while at the same time making it very difficult to understand how your code works. Even if you aren't doing classpath scanning to generate code, using annotations also introduces unnecessary coupling in your code in practice. The blog post will have some good examples I've seen in the wild. :)
- agentgt 10y ago
  > In practice, annotations define runtime global variables that other frameworks can make use of by doing expensive classpath scanning on startup to rewrite bytecode at runtime. Dagger2 is DI a compile time annotation library. Yes there needs to be a lot more libraries like this. I totally understand some of your hate for annotations (I have my own with Spring Boot). Despite my tone from the previous comment I think there should be a lot more plain old programmatic configuration (ie just load up objects and setup some properties during the bootstrap). I had aspirations of making a howto guide using Dagger2 and various other compile time / code generation libraries (like jOOQ and MapStruct) as I too absolutely hate the classpath scanning hell that is Spring these days. I can't deny though that some people find the "magic" more productive particularly for ramp up time. All in all I violently agree with you more than you think (hence why I'm looking forward to your post). I still don't know what a dynamic language is and neither does Wikipedia for that matter [1]. Its pretty nebulous. Its like saying strongly typed. [1]: https://en.wikipedia.org/wiki/Dynamic_programming_language#Examples https://en.wikipedia.org/wiki/Dynamic_programming_language#E...
  - NiceGuy_Ty 10y ago
    Dynamically typed languages carry the types of values at runtime. That is, whatever is executing your code can look at a value itself and read off the type of it. Statically typed languages check all of the types of their values at compile time to make sure that it's sound. Then, they can strip the type information from those values and execute them without having to perform any runtime checks. In a dynamically typed language, the way to apply an operation is to read the type tag on it first, make sure the operation you want to apply can be applied to it, and then execute that operation. In a statically typed language, that check happened at compile time, so you're safe to just apply the operation to the value. Oftentimes languages may not be fully statically typed or fully dynamically typed. Java's use of reflection, instanceof, and casting means that it carries some type information at runtime. C++ has typid, C# has GetType(), etc. etc. Haskell as a language has full type erasure and can be considered fully statically typed, but there are some. GHC extensions (Typeable) which point to some type information being held at runtime by the compiler.

by agentgt 10y ago

sreque 10y ago

You asked for examples and that proceeded to defend almost all of the ones I listed, which basically proves my point that this is how things work in the Java community. You can call things via reflection, therefore the language is dynamic? You have a strange definition of what makes a language dynamic. By that definition just about every language is dynamic. In C/C++ I can dynamically load symbols, call functions by string names, call C++ constructor functions, etc. I've never in practice seen anyone use compile-time annotation processors. In practice, annotations define runtime global variables that some frameworks make use of by doing expensive classpath scanning on startup to add or rewrite bytecode at runtime. These frameworks basically help cement java's reputation for having incredibly slow startup times while at the same time making it very difficult to understand how your code works. Even if you aren't doing classpath scanning to generate code, using annotations also introduces unnecessary coupling in your code in practice. The blog post will have some good examples I've seen in the wild. :)

agentgt 10y ago
> In practice, annotations define runtime global variables that other frameworks can make use of by doing expensive classpath scanning on startup to rewrite bytecode at runtime. Dagger2 is DI a compile time annotation library. Yes there needs to be a lot more libraries like this. I totally understand some of your hate for annotations (I have my own with Spring Boot). Despite my tone from the previous comment I think there should be a lot more plain old programmatic configuration (ie just load up objects and setup some properties during the bootstrap). I had aspirations of making a howto guide using Dagger2 and various other compile time / code generation libraries (like jOOQ and MapStruct) as I too absolutely hate the classpath scanning hell that is Spring these days. I can't deny though that some people find the "magic" more productive particularly for ramp up time. All in all I violently agree with you more than you think (hence why I'm looking forward to your post). I still don't know what a dynamic language is and neither does Wikipedia for that matter [1]. Its pretty nebulous. Its like saying strongly typed. [1]: https://en.wikipedia.org/wiki/Dynamic_programming_language#Examples https://en.wikipedia.org/wiki/Dynamic_programming_language#E...
- NiceGuy_Ty 10y ago
  Dynamically typed languages carry the types of values at runtime. That is, whatever is executing your code can look at a value itself and read off the type of it. Statically typed languages check all of the types of their values at compile time to make sure that it's sound. Then, they can strip the type information from those values and execute them without having to perform any runtime checks. In a dynamically typed language, the way to apply an operation is to read the type tag on it first, make sure the operation you want to apply can be applied to it, and then execute that operation. In a statically typed language, that check happened at compile time, so you're safe to just apply the operation to the value. Oftentimes languages may not be fully statically typed or fully dynamically typed. Java's use of reflection, instanceof, and casting means that it carries some type information at runtime. C++ has typid, C# has GetType(), etc. etc. Haskell as a language has full type erasure and can be considered fully statically typed, but there are some. GHC extensions (Typeable) which point to some type information being held at runtime by the compiler.