Group items tagged

There was a recent outburst in blogs on the topic of Groovy and how it compares to Java. Although I respect the youthfull entusiasim of Groovy and Co. working on this little exercise I'm just perplexed by the "WHY?" in this whole discussion. Let me just say again: W H Y ?!?! 1. Practically no one cares about Groovy (let alone Groovy++ strap-on) beyond Grails community. So this language just as "widely accepted" as Ruby (at least for enterprise software development) 2. If you know Java it's equally "challenging" to pick up either Groovy or Scala. Don't let anyone insult your intelligence by claiming that Scala syntax is somehow more complex than Groovy. In both languages you will need to adapt to functional thinking - and that's where you will have to spend a couple of weekends… 3. If you know Groovy - you already know 90% of Scala (different syntax and few extra features can be picked up in the evening) 4. Scala is designed by people who have proper academic background, experience and talent in the area of language design - Groovy has never been that way (and anyone who dares to look inside of Groovy runtime or history of changes in it will attest to that). NOTE: it did come out rather strong - but that's how I feel about it and after some thinking I'll leave as is. Nothing personal to anyone reading it… 5. Scala as a post-functional language is years ahead of Groovy (static typing with best-in-business type inference, highly tuned mix of imperative and functional styles, powerful and done-right generics, etc.) 6. Groovy will ALWAYS be slower than Scala or Java (latest benchmarks put even Groovy++ about 50 times slower than Java) just by its nature unless someone changes the language and rebuilds the runtime from the ground up. 7. Once we get decent integration with Eclipse, NetBeans and IDEA for Scala, the Groovy will lose its only serious advantage

"An "executable" UML model is one with a behavioral specification detailed enough that it can effectively be "run" as a program. This can be extremely valuable in order to test and validate the model, independently of the one or more implementation platforms to which the system being modeled will ultimately be deployed. Or, in some cases, the model itself can actually be run as the production implementation, given an appropriate execution environment. There have been model execution tools and environments for years, even before UML. However, each tool defined its own semantics for model execution, often including a proprietary action language, and models developed in one tool could not be interchanged with or interoperate with models developed in another tool. A previous post described Stephen Mellor's quest of more than a decade to change this through OMG standards for precise UML model execution semantics and a UML action language. In 2008, this led to the adoption of the Foundational UML (fUML) specification, providing the first precise operational and base semantics for a subset of UML encompassing most object-oriented and activity modeling. The fUML specification still did not provide any new concrete surface syntax, however, tying the precise semantics solely to the existing abstract syntax model of UML. This meant that, in order to fully specify a detailed behavior in a UML model - say the effect behavior of a transition on a state machine or the method of an operation of a class - one still had to draw a very detailed, graphical activity diagram. "

"Eclipse Plug-in for tailing log files and eclipse consoles (e.g. SVN, Java Stack Trace, CDT), including syntax coloring with either a regular expression or a word match. It allows you to have multiple logs open concurrently. "

Dart is an open-source, general-purpose, class-based, object-oriented language with C-style syntax which can optionally transcompile into JavaScript. It...

There is no migration system in vanilla grails (although possibly in Grails 2.0 …. ?) but there do exist several plugins that provide  some migration functionality. As of this post I am aware of three: dbMigrate, Liquibase, and Autobase. Of these, I prefer Liquibase and cannot recommend it enough. While it uses XML to describe its changesets it is a mature open-source Java project that works flawlessly (and has some excellent documentation). I did not have much luck using DbMigrate and Autobase when including in an existing project… which is a shame as Autobase (which is built on Liquibase) uses a nice DSL syntax to build the migrations.

"Support for mixed Scala/Java projects Thumb Support for mixed Scala/Java projects and any combination of Scala/Java project dependencies, allowing straightforward references from Scala to Java and vice versa. Editing Thumb A Scala editor with syntax highlighting, code completion, inferred type hovers, hyperlinking to definitions, error markers and more. Debugging Thumb Incremental compilation, application launching with integrated debugger, hyperlinking from stacktraces to Scala source, interactive console. Navigation Thumb Project and source navigation including Scala support in the Package explorer view with embedded outline, outline view, quick outline, open type, open type hierarchy."

Emfatic is a text editor supporting navigation, editing, and conversion of Ecore models, using a compact and human-readable syntax similar to Java. The EPLed Emfatic now hosted at EMFT extends the Feb 2005 alphaworks release with support for EMF Generics, folding, "red squigglies", an EMF Type Hierarchy, hyperlinks, AutoEdits, and the possibility to define templates to speed up document creation, among other usability features. The best way to gain hands-on experience with Emfatic is to right-click on any .ecore file and choose Generate Emfatic source, a similar converter works in the opposite direction. Online help is also available. Emfatic itself builds upon Gymnast, a framework for jumpstarting text editors for custom Domain Specific Languages. Documentation on how to extend Emfatic, as well as on using Gymnast, can be found in this technical report.

The Compact Namespace and Node Type Definition (CND) notation provides a compact standardized syntax for defining node types and making namespace declarations. The notation is intended both for documentation and for programmatically registering node types (if you are unfamiliar with JCR node types, you may want to read the general Node Types section first).

The most recent version updates of a programming language like Java are beneficial to many businesses trying to develop applications. These most recent Java improvements and additions have more precise syntax and provide tools to address challenging problems.

"Let's imagine we want to create an application for orders. People can sign in to the system, place orders for various items, check out and have them sent to their address. Very simple, but we can show a lot of things here. As we expect to be writing more than one application of this type and as we also would like to be able to express the structure of the application on a business level (one of the major drivers for DSLs and MDSD for that matter), we come up with the idea of using a DSL to describe what the application does. Defining the DSL is what we did last week. This week, we need to map the concepts of the DSL to some code and some APIs we're going to program against. So, we're going to create a set of code templates for a code generator that can then read our DSL models and create persistence code for us."