I've been reading Bruce Eckel's Thinking In Java and in the chapter on generics, he briefly mentions the Nice programming language as something that handles parametrized types better than Java, but compiles into Java bytecode.
Does anyone have any experience with this? Generics make my head hurt, so the prospect of an alternative that interoperates with Java is appealing... but I sort of feel like it would be like trying to learn both French and Quebecois and getting yelled at if I get them mixed up in the wrong context. (no offense meant so please don't ding me for not being PC) And whoever thought up the name "Nice" should be shot, since it makes it impossible to search for any websites other than the sourceforge one.
I'd also suggest looking at Scala, a multi-paradigm (OO and functional) language that runs on the JVM. Martin Odersky, the "father of Scala" was also a primary contributor to the implementation of generics in Java, including his work on the Pizza and GJ implementations.
The current type-erasure mechanism in Java does force one to understand some implementation details to make sense of restrictions, but it is fair to say that using full-blown generic support in any language is going to require a learning curve.
I found Java Generics and Collections to be a well-written introduction and guide to using generics in Java 5.
Maybe the question to ask is, "Why do generics make your head hurt?" How are you using them that causes such pain?
I'll agree that there are flaws with generics in Java, and there are situations (e.g., extends) that do cause problems, but what exactly is your issue?
Using another language that compiles to byte code might help you in the short run, but if you're working in a team that delivers systems that others will have to maintain you might have problems introducing a technology like Nice, no matter how elegant it is.
I'd say look at Scala or Groovy. It's my impression that Nice is an experimental language that never caught traction. If you don't like Java's generics at all, then you might prefer groovy, which is dynamically typed. If you like the idea of generics, but find Java's implementation of them confusing (like I do), then you might like scala, which handles generics more sensibly.
Related
Is there a way to use a Domain Model written in Scala from a Spring+Java+Maven project ?
Asking this after going through Scott Wlaschin's video on Functional Domain Modelling. Would love to implement some of it using Scala and bring the power of Functional DDD to our mundane old spring code! 🙏
Any help would be wonderful!
There is no "ADT magic" in the video. There is a powerful type system in the language and a functional approach.
You can leverage Java's type system to some degree and also use some functional libraries like vavr or maybe something like reactor. It will improve your code greatly, but it wouldn't be so powerful like in functional languages with great type system (like F#, Haskell, Scala, and other ML-like langs)
If you want to leverage Scala's type system (which is even more powerful then F#) you should use Scala almost everywhere because guarantees of the type system are in the compiler. And you can use Spring from Scala (but I think this is a huge antipattern).
There are 2 parts here.
One part has nothing to do with ADT's, rather Scala and Java compatibility.
Everything written in scala compiles down to JVM bytecode, so whatever 'magic' you are referring to, can be written in Java, albeit much less concise and readable.
And therefore is usable.
The second part is the type-checker
Part of ADT magic is compile-time safety checks, such as exhaustive match checks amongst others...
You will not get that when you call instanceof in java on a case class designed in Scala
I am studying Scala right now, and have been doing so for the last month. Today, (via Twitter) I stumbled upon another language that seems to be quite similar, Gosu.
What are the essential similarities and differences between Scala and Gosu with respect to their most influential parent, Java? Are there any web-sites that compare and contrast these two languages?
Yeah, our language comparison chart is largely a joke. Especially the "Not Lisp" row. :)
As Stephen C pointed out from my original post, in general, Gosu is simpler than Scala, while Scala has more advanced features than Gosu.
Scala and Gosu have many similarities:
Both are statically typed, but use type inference to reduce code bloat
Both support closures and more functional-style programming
Both provide additional functionality on top of the existing java libraries, especially around collections.
And here are some differences:
Gosu does not support general operator overloading
Gosu does not provide syntactic support for Monads
Generics in Gosu are simpler than in Java (at the cost of correctness) where they are more (or at least as) complicated in Scala (although Scala does a much better job with correctness.)
Gosu does not support things like Scala's implicit '_' argument in closures: it is more explicit in cases like this.
Gosu's extensions to the core Java libraries are less dramatic. We weld additional methods onto existing java types, rather than introducing a new type hierarchy.
There is one big difference between Gosu and Scala on the functionality side: Gosu has what we call an Open Type System. This allows people to plug in arbitrary resources to the Gosu compiler. As as an example: Gosu (as of 0.8.5) supports XSD and WSDL files as first class citizens:
http://lazygosu.org/xml.html
The Open Type System is, on the functionality side, the real differentiator between Gosu and other statically typed JVM languages.
All that being said, the unfortunate reality right now is that Scala is much more mature than Gosu in some areas, especially tooling. There is great IDE support for Scala in all of the major IDEs. We have an Eclipse plugin for Gosu, but it is still in its infancy. Similarly our IntelliJ plugin is very new.
Scala has a very complete web framework, Lift. I'm not a huge fan of their approach, but it is complete and a lot of people like it.
Gosu has a web framework as well:
http://ronin-web.org
I love Ronin's approach, but then I would, wouldn't I? Ronin is being built by guys who know Gosu very well and, thus, it leverages a lot of functionality in the language.
Hope that helps. Realistically, if I were starting a project today, I'd probably go with Scala just because of the tool support. However, if you want to strike out in another direction, particularly if your project involves web services or XSD handling, Gosu might be a rewarding language to use. In the long run I hope that Gosu will be the pragmatic choice for JVM developers, but only time will tell.
The Gosu comparison table is somewhat unfair to Scala: The transition from Java is easy (you don't have to use all of the fancy Scala stuff at the beginning), and for reified generics Scala has not a perfect, but a workable solution called Manifests. Of course categories where Scala shines are missing (pattern matching, higher kinded types...)
In this thread on the gosu-lang list, Carson Gross summarized it as follows:
The short answer is that Gosu is simpler than Scala (simpler generics, limited operator overloading) but a bit more firmly statically typed than, say, Groovy.
There's also this table, but it is one of those "our product is better than your product" comparisons; i.e. intrinsically biased.
As far as I know, Gosu is developed by Guidewire for their product-specific development and configuration of product. So all Guidewire users/ developers use Gosu for programming. That's the major reason you don't see many posts related to Gosu scripting.
I am curious about such thing... Is there a programming language that would have:
syntax such as Java and/or C++
templates/generics support
memory management (no garbage collection)
"clean syntax" (no mess like perl or c/c++)
"normal" OOP (polyphormism, interfaces, abstract classes, overloading and etc.)
(preferably) compiles to machine code
namespace support
exception support
no source preprocessor (as is in c\c++)
statically typed
Maybe ADA ? I can advice you to learn C/C++ or Java or something else and use it smartly - then you'll get everything you need.
UPD: You may be interested by D
syntax such as Java and/or C++
"clean syntax" (no mess like perl or c/c++)
So, basically you want syntax such as C++, but you don't want syntax such as C++. It should be obvious that such a language cannot possibly exist, since the intersection of the set of languages that have syntax such as C++ and the set of languages that do not have syntax such as C++ must necessarily be the empty set.
There also some other requirements that don't make sense, like this one:
(preferably) compiles to machine code
What the compiler produces as its output is a trait of the compiler, it has nothing to do with the language. Every language can be compiled to every other language, provided the target language has at least the same computational power as the source language. (Which typically means that the target language must be Turing-complete, since most source language are Turing-complete.)
What is your need for those features? Or are they things you think you need? Why not find a syntax you think you'll feel comfortable with, since that seems to be the most important thing in your list, and then explore your other application requirements
Vala - designed as unmanaged C# for gnome
D - Built on c but simpler than C++. I think it has some kind of GC though
The new versions of Delphi, doesn't have curly brace syntax though
I'm betting you'll have a hard time finding a language that meets all your criteria. However, these may be worth looking into:
Go. Clean syntax, compiles to machine code. Has GC, though. And isn't strictly O-O.
Scala addresses many, but not all, of your issues (as mentioned by others in this thread).
Haskell. Functional, not O-O. But worth looking at anyway.
D, also as mentioned by others.
It's definitely Scala. It confirms all your points
To put it bluntly: Learn C++ and use it the way it should be used.
Done.
You only get GC issues if you discard objects. Write your application to recycle object instead and you won't have any garbage collection.
You can design an application which only GC's over night for example. i.e. zero-cost during the day, but some garbage is allowed.
Perhaps you could say what your concern is with having a GC. There may be ways to work around the problem which opens up languages like C# and Java.
BTW: Java and C# is compiled to machine code at run time.
I'm writing a Java application using Struts 2, but now I'd like to make it a hybrid Java & Scala project instead. I don't have much experience with Scala, but I learned Haskell years ago at college -- I really liked the functional programmed paradigm, but of course in class we were only given problems that were supremely suited to a functional solution! In the real world, I think some code is better suited to an imperative style, and I want to continue using Java for that (I know Scala supports imperative syntax, but I'm not ready to go in the direction of a pure Scala project just yet).
In a hybrid project, how does one decide what to code in Java and what to code in Scala?
Two things:
99% of Java code can be expressed in Scala
You can write projects that support mixed Java+Scala compilation. Your Scala code can call your Java code and your Java code can call your Scala code. (If you want to do the latter, I suggest defining the interface in Java and then just implementing it in Scala. Otherwise, calling Scala code from Java can get a little ugly.)
So the answer is: whatever parts you want. Your Scala code does not need to be purely functional. Your Scala code can call Java libraries. So pretty much any parts you could write in Java you could also write in Scala.
Now, some more practical considerations. When first trying Scala, some people pick relatively isolated, non-mission-critical parts of their program to write in Scala. Unit tests are a good candidate if you like that approach.
If you're familiar with Java and have learned Haskell in the past, I suggest treating Scala as a "better Java". Fundamentally, Scala compiles to JVM bytecode that is very, very similar to what Java outputs. The only difference is that Scala is more "productive": it produces more bytecode per line of code than Java does. Scala has a lot of things in common with Haskell (first-class functions, for-comprehensions are like Haskell's do-notation, limited type inference), but it's also very different (it's not lazy by default, it's not pure). So you can use some of your insights from Haskell to inspire your Scala style, but "under the hood" it's all Java bytecode.
In the spirit of your question, I recommend you write in Scala any code that involves heavy manipulation of collections, or that handle XML.
Scala's collection library is the foremost functional feature of Scala, and you'll experience great LoC reduction through its usage. Yes, there are Java alternatives, such as Google's collection library, but you asked what you should write in Scala. :-)
Scala also has native handling of XML. You might well find the transition difficult, if you try to take DOM code and make it work on Scala. But if you, instead, try to approach the problem and the Scala perspective and write it from scratch for Scala, you'll have gains.
I'd advise using Actors as well, but I'm not sure how well you can integrate that with Struts 2 code on Java. But if you have concurrent code, give Actors in Scala a thought.
It might sound silly, but why not write your entire project in Scala? It's a wonderful language that is far more expressive than Java while maintaining binary-compatible access to existing Java libraries.
Ask these questions of your project:
"What operations need side-effects?" and "What functionality is already covered well by Java libraries?" Then implement the rest in Scala.
However I would warn that hybrid projects are by their very nature more difficult than stand alone projects as you need to use multiple languages/environments. So given you claim not much experience with Scala I'd recommend playing with some toy projects first, perhaps a subset of your full goal. That will also give you a feel for where the divide should occur.
I am a fan of static metaprogramming in C++. I know Java now has generics. Does this mean that static metaprogramming (i.e., compile-time program execution) is possible in Java? If so, can anyone recommend any good resources where one can learn more about it?
No, this is not possible. Generics are not as powerful as templates. For instance, a template argument can be a user-defined type, a primitive type, or a value; but a generic template argument can only be Object or a subtype thereof.
Edit: This is an old answer; since 2011 we have Java 7, which has Annotations that can be used for such trickery.
The short answer
This question is nearly more than 10 years old, but I am still missing one answer to this. And this is: yes, but not because of generics and note quite the same as C++.
As of Java 6, we have the pluggable annotation processing api. Static metaprogramming is (as you already stated in your question)
compile-time program execution
If you know about metaprogramming, then you also know that this is not really true, but for the sake of simplicity, we will use this. Please look here if you want to learn more about metaprogramming in general.
The pluggable annotation processing api is called by the compiler, right after the .java files are read but before the compiler writes the byte-code to the .class files. (I had one source for this, but i cannot find it anymore.. maybe someone can help me out here?).
It allows you, to do logic at compile time with pure java-code. However, the world you are coding in is quite different. Not specifically bad or anything, just different. The classes you are analyzing do not yet exist and you are working on meta data of the classes. But the compiler is run in a JVM, which means you can also create classes and program normally. But furthermore, you can analyze generics, because our annotation processor is called before type erasure.
The main gist about static metaprogramming in java is, that you provide meta-data (in form of annotations) and the processor will be able to find all annotated classes to process them. On (more easy) example can be found on Baeldung, where an easy example is formed. In my opinion, this is quite a good source for getting started. If you understand this, try to google yourself. There are multiple good sources out there, to much to list here. Also take a look at Google AutoService, which utilizes an annotation processor, to take away your hassle of creating and maintaining the service files. If you want to create classes, i recommend looking at JavaPoet.
Sadly though, this API does not allow us, to manipulate source code. But if you really want to, you should take a look at Project Lombok. They do it, but it is not supported.
Why is this important (Further reading for the interested ones among you)
TL;DR: It is quite baffling to me, why we don't use static metaprogramming as much as dynamic, because it has many many advantages.
Most developers see "Dynamic and Static" and immediately jump to the conclusion that dynamic is better. Nothing wrong with that, static has a lot of negative connotations for developers. But in this case (and specifically for java) this is the exact other way around.
Dynamic metaprogramming requires reflections, which has some major drawbacks. There are quite a lot of them. In short: Performance, Security, and Design.
Static metaprogramming (i.e. Annotation Processing) allows us to intersect the compiler, which already does most of the things we try to accomplish with reflections. We can also create classes in this process, which are again passed to the annotation processors. You then can (for example) generate classes, which do what normally had to be done using reflections. Further more, we can implement a "fail fast" system, because we can inform the compiler about errors, warnings and such.
To conclude and compare as much as possible: let us imagine Spring. Spring tries to find all Component annotated classes at runtime (which we could simplify by using service files at compile time), then generates certain proxy classes (which we already could have done at compile time) and resolves bean dependencies (which, again, we already could have done at compile time). Jake Whartons talk about Dagger2, in which he explains why they switched to static metaprogramming. I still don't understand why the big players like Spring don't use it.
This post is to short to fully explain those differences and why static would be more powerful. If you want, i am currently working on a presentation for this. If you are interested and speak German (sorry about that), you can have a look at my website. There you find a presentation, which tries to explain the differences in 45 minutes. Only the slides though.
Take a look at Clojure. It's a LISP with Macros (meta-programming) that runs on the JVM and is very interoperable with Java.
What do you exactly mean by "static metaprogramming"? Yes, C++ template metaprogramming is impossible in Java, but it offers other methods, much more powerful than those from C++:
reflection
aspect-oriented programming (#AspectJ)
bytecode manipulation (Javassist, ObjectWeb ASM, Java agents)
code generation (Annotation Processing Tool, template engines like Velocity)
Abstract Syntax Tree manipulations (APIs provided by popular IDEs)
possibility to run Java compiler and use compiled code even at runtime
There's no best method: each of those methods has its strengths and weaknesses.
Due to flexibility of JVM, all of those methods in Java can be used both at compilation time and runtime.
No. Even more, generic types are erased to their upper bound by the compiler, so you cannot create a new instance of a generic type T at runtime.
The best way to do metaprogamming in Java is to circumvent the type erasure and hand in the Class<T> object of your type T. Still, this is only a hack.
If you need powerful compile-time logic for Java, one way to do that is with some kind of code generation. Since, as other posters have pointed out, the Java language doesn't provide any features suitable for doing compile-time logic, this may be your best option (iff you really do have a need for compile-time logic). Once you have exhausted the other possibilities and you are sure you want to do code-generation, you might be interested in my open source project Rjava, available at:
http://www.github.com/blak3mill3r
It is a Java code generation library written in Ruby, which I wrote in order to generate Google Web Toolkit interfaces for Ruby on Rails applications automatically. It has proved quite handy for that.
As a warning, it can be very difficult to debug Rjava code, Rjava doesn't do much checking, it just assumes you know what you're doing. That's pretty much the state of static metaprogramming anyway. I'd say it's significantly easier to debug than anything non-trivial done with C++ TMP, and it is possible to use it for the same kinds of things.
Anyway, if you were considering writing a program which outputs Java source code, stop right now and check out Rjava. It might not do what you want yet, but it's MIT licensed, so feel free to improve it, deep fry it, or sell it to your grandma. I'd be glad to have other devs who are experienced with generic programming to comment on the design.
Lombok offers a weak form of compile time metaprogramming. However, the technique they use is completely general.
See Java code transform at compile time for a related discussion
You can use a metaprogramming library for Java such as Spoon: https://github.com/INRIA/spoon/
No, generics in Java is purely a way to avoid casting of Object.
In a very reduced sense, maybe?
http://michid.wordpress.com/2008/08/13/type-safe-builder-pattern-in-java/