Love Drools. The consultancy I worked for made so many happy customers by just simplifying a lot of complex optimization use cases with Drools. Hard to do better than Drools for rule-based anything if you’re on the JVM.
I’ve been using this in our Python project via clipspy (https://github.com/noxdafox/clipspy) and it’s been pretty nice. Clips is really REPL-centric and provides a lot of good debugging tools. It’s powerful and fast. The maintainer (Gary Riley) also does a great job answering questions on SO. Pretty happy with it.
Gary was also one of the first and primary authors of CLIPS.
If I recall correctly, a summer intern in the AI section under the Mission Planning Directorate, whose name I have forgotten, developed a prototype or a proof-of-concept of CLIPS. At the time, 1984-ish, the AI group at JSC had many expensive Symbolics and Lisp Machine computers running ART. The intern's project showed that a pattern matching rules based engine could be developed in a conventional programing language for distribution to traditional cost effective hardware.
> a conventional programing language for distribution to traditional cost effective hardware.
In 1984, C was considered a new programming language. The VAX first came out in 1977, and the Sun 1 in 1982. Traditional hardware in 1984 would be an IBM mainframe.
I don't understand the question, beyond the fact that Spring and Grails both had the same corporate sponsorship at one point in the past.
Spring Boot is a rapid, flexible, and fairly tight (as far as Java frameworks go) foundation for building Java applications. Grails is a Groovy-based wrapper layer around Spring and Hibernate.
So if you want to use Groovy for application development, then Grails is certainly there for you. However, I don't think it's the most competitive option. I think Groovy's great as a scripting language, and I use it for things like automated testing, but I wouldn't enjoy using it for primary application development because it's not a statically-typed language.
Although recent versions of Groovy allow you to designate typesafe "areas" within your code, it is still fundamentally non-typesafe. Because of this, tooling is always going to be weaker than it is for typesafe languages. IntelliJ is probably the best Groovy IDE out there, and it's still frustrating to work with because it can't detect autocomplete options most of the time.
If you're doing development on the JVM in the first place, then odds are you favor static typing. Plain Java, or Scala, or most of the fringe options like Kotlin or Ceylon. If you're in the minority camp who want to use a language with dynamic typing, even THEN there are better options than Groovy for application development. JRuby has a much broader and more active community, and Clojure will give you more "Internet cool points" on HN or Reddit or wherever.
Finally, the last time I looked at Grails, it was FAT. Building an application took forever. I'm sure they've (hopefully) optimized or rebuilt things since then. However, since it's a wrapper around Spring and Hibernate, it's never going be any lighter or faster than Spring and Hibernate.
I don't mean any disrespect to Groovy. I've been using it forever, and it comes in handy with certain use cases. However, it's primary niche is being the dynamic JVM language that most "enterprise" shops have become comfortable with... and so if you're trapped in an "enterprise" shop and are dying to use something other than plain Java, it's the thing you'd most likely be allowed to use.
Web Front End: Angular, Backbone, React
Web Back End: Spring Boot, Grails
Data Stores: Elasticsearch, Postgres, MongoDB, Redis, Couchbase, Neo4J
Clustered Systems: Mesos, Marathon
Systems Management: AWS, Docker, Docker Compose (Fig), Vagrant, Puppet
Build Automation/CI: Gradle, Grunt, CircleCI, Jenkins, Sonar
Test Automation: Spock, Selenium, Mocha, Jasmine
Who we are
============
Spantree is a boutique software engineering firm based in Chicago, with some members scattered around the western hemisphere. We're looking for an engineer who's not afraid to tinker and break things. You should enjoy solving tough problems, coming up with novel solutions and delivering a polished product.
We're a small team with a fairly flat organizational structure. Everyone has specialties, but everyone is encourage to work on every aspect of a project.
We love sharing and open source. We constantly hunt for better and smarter ways to do things. And, since we're often pushing our software and our systems, you should feel comfortable communicating with developers in the open source community. Pull requests to open source projects are highly encouraged.
What we work on
==============
Our clients range from small and scrappy startups to large enterprise companies. We have 3-7 projects going at any point in time. We tend to focus on greenfield development, building web applications from the ground up. We also work on integrating the old with the new, bringing technologies like Mesos, Elasticsearch and Drools to large companies. Helping people make better decisions is the central theme of most of our projects. This can take the form of a search engine to help people find interesting stuff to do on a Saturday night, a complex rules-oriented workflow management system for evaluating health insurance claims, helping people find the right doctor, or a matchmaking and scheduling system to help people book face-to-face meetings at conferences. In the next year or two, we also plan to get into product development, taking our experiences solving the same sort of problems for multiple clients and rolling them into a generic framework which we plan to open source and support directly for our clients and the rest of the world.
Contact us
==========
Drop us a line at [email protected] and tell us a bit about yourself. If you have a resume or CV, feel free to pass that along as well. Github and LinkedIn profiles are also helpful. We're looking forward to hearing from you!
Same thoughts here... been trying to move exclusively over to IJ since 4.x series but two (really dumb) things send me back to Eclipse every time: Javadoc formatting and Web Project module support.
I mean "really dumb" in the sense that these things shouldn't be so important to me, but as someone who writes a novel's worth of documentation inside his code, subpar Javadoc formatting doubles my workload.
The project model thing is my own problem trying to mentally map the whole project/module/artifact abstraction IJ has... I don't understand it, never have, doesn't seem intuitive and mostly just frustrated me.
I think more of this has to do with the layout of the project properties dialog than anything combined with my own mental reluctance to understand what they are proposing here.
That said, the code quality of the product seems to be excellence. Very smooth, no surprise exceptions during use (Which is par for the course in Eclipse).
Some day I'll sit down and figure it out, but until then I will continue to be confused and stick to my simple, flat, POM-defined life in Eclipse and cry every time I load up 4.2 and wonder why I am doing this to myself (if you haven't used Eclipse 4.x series yet, you don't understand how much pain there is waiting for you).
Have you ever tried to import a project in IntelliJ just by opening the POM file? I find it imports the project structure from the Pom very well.
I agree that Idea makes it's project layout very hard to understand for beginners and struggled with it myself until I realized you could just import a Pom file and be done with it all.
> if you haven't used Eclipse 4.x series yet, you don't understand how much pain there is waiting for you
Wow. I thought Eclipse would have gotten better along the years. Back when I switched to IDEA at version 4.x, the difference between them was like night and day - IDEA was so much better.
Could you tell me a bit about the pain of Eclipse? It's quite surprising if they haven't managed to produce a solid IDE yet.
I agree that IDEA's way of organizing things is kind of clunky. In a way, a "project" can be thought of as "metadata about stuff I'm working on", instead of the more intuitive "a project is a directory on my hard drive".
Once you set up a project, you can then bring stuff into it with "modules". For example, you may want to include source code trees and/or JARs from multiple locations.
Eclipse is the non-commercial result of a committee of developers so wide and uninvolved in each other's greater visions and monetization strategies, that the user-experience of the base platform is "functional" at best.
I can cope with just "functional" (and stable) but Eclipse is "functional" only -- the core platform (UI, plugin framework, all core Java/source tools, etc.) are really stable and robust.
Everything else built ontop of them (custom editors/designers, Web tools, all of WTP, Maven tooling) basically all the ++ resources are unbelievably memory hungry (turn on the heap monitor and watch it when you run the Update Manager > Check for Updates... seriously, just watch how many objects are instantiated and GC'ed in that simple cycle, 100s of MBs) and generally broken.
To that point, the "design by committee" environment leads to overengineering that you cannot fully appreciate until you start trying to build ontop of those APIs. If you hate yourself, try and build something ontop of WTP from scratch (like custom tech support, like a Play IDE).
Also interacting with the Update Manager concept that has tried to become so much more but has been hammered into this "jack of everything-even-stuff-no-one-needs, master of nothing especially the thing it is suppose to do"
The intelligence needed to correctly calculate an update plan based on plugin versions and interdependencies is worthy of a PHD -- if you've used Eclipse for an extended period of time and upgraded yourself into a corner that the Update Mangaer cannot update you out of, then you know what I mean. If you are a long-time user you've heard "Try a new workspace" or "Do a new install" more times than you can count as far as trouble shooting first-steps.
Eclipse is an odd ecosystem. The only money to make by EVERY company involved is in +1 features that have not been commoditized by the platform.
Unfortunately these are ALL the developers contributing to the core platform, the same ones trying to keep their pay checks by developing tools ontop of the core. There is no desire to cannibalize their own products and markets by contributing that stuff unless they absolutely have to (for fame or strategic reasons, take your pick).
The move to 4.x was a total redesign of the platform to make it "Web friendly" I think, I have no idea... but it was a major-major overhaul of the core platform and the result is a buggy/slow/mess even at the core level that has long since stabilized.
Anything beyond "core tooling" available in the open-source bundle is going to be what I would consider a "best intention" implementation. Not good enough to put anything commercial out of business and not bad enough to be berated or ignored completely... just bad enough to make you crazy with rage if you depend on it day in and day out, but good enough to seem cool if you are doing a tool evaluation. That said the stuff that gets used by EVERYONE (e.g. Java code tools) is great because it is in every contributor's best interest to have that stuff rock (their day jobs). For the tooling that is very specific to a team or company, definitely not the case.
IJ on the other hand is a single product backed by a single company with the sole focus of being as-good-as-it-needs-to-stay-commercially-competitive. JetBrains has to spend money to convince people to spend THEIR money... the market is forcing this product to get better and better and those developers appreciate things like rewriting a plugin framework to keep it fast, rewriting the code-completion parser to update faster, etc... the kind of stuff that is huge technical debt after 8 years that an OS project can almost never justify sticking on someone's bottom line to rewrite.
That said, I actually dislike some of the core project paradigms used in IJ which is the only reason I don't swear by it heart-and-soul. The dev experience is much more stable, performant and consistent.
If you want a corollary of what I mean about "paradigms" consider the IJ UI builder compared to the NetBeans one -- NetBeans when NaturalLayout came out was all about "Drag and drop with snap-to rules" -- it was intuitive as all hell.
IJ on the other hand was all about FormLayout-like behavior and a way more technical experience with weighting and splits and bindings.
Both were pretty stable and worked great, but took very different approaches. If you bought into the IJ model it was awesome and you had a great time using it.
If you were like me and wanted the preferred-spacing snap-tos guiding your design, it was a pain and you much preferred the NetBeans UI designer.
So if you are doing core Java dev work, Eclipse and IJ are both awesome. If you are doing Web Dev/Spring/JavaEE/JSF work -- try them both, the bugs in Eclipse will eventually drive you crazy I imagine though and I am NOT saying IJ is better, it is different, and in some design/paradigm ways less intuitive in my opinion which is what keeps me from just recommending it to everyone I meet on the street.
NetBeans falls somewhere in here... I think in a lot of ways it is an unsung hero, has some nice polish that the others don't, very human friendly but is also missing some hard-core functionality that you find after about a month of use in my experience. Back in the day the real-time compile and auto-complete speed of Eclipse kept me away from NetBeans. The "based on Ant/maven" building design was a decent call I think, I get why they made it when they did, but it did cost them some things.
The NB team has shored up the editors quite a bit so I think most is caught now during editing. I am meaning to try the 7.2 beta so maybe I'll be happily surprised.
I haven't used the last 2 versions of NetBeans though -- the Javadoc formatting always moved me away from that one as well.
What a silly reason, I know -- should stop writing so many comments :)
Your description of Eclipse hits the nail on the head. +1 For the comment on updating yourself into a corner. Eclipse plugins make it insanely easy to shoot yourself in the foot and get the IDE into an unusable state. Eclipse has an amazing variety of plugins, but sadly 99.9% of eclipse plugins give the other 0.1% a bad name.
From what I've seen many folks have started using IntelliJ due to the top-notch Scala plugin which Jetbrains provides for free.
It's all very simple. The trick to always succeeding is to take all your failures and make yourself think they're successes. If you can't fail, you've got no fear. Being delusional or mentally/emotionally unstable helps.
This entire exchange read almost exactly like an exchange from the comic Dilbert, to the point that I still have a bit of a suspicion that it might be.
Well, I don't know how you got that assertion about the normal distribution. But, one reason you could think it's not a simple normal distribution is that computer science classes often have bimodal grade distributions.
