command to connect to the same kernel that the browser is attached to. I can do more complicated coding in that repl (inside of emacs). Then, when I need visual feedback, I do some kind of one liner plot and hit play in the browser.
It works pretty well, but maybe this will make the whole thing smoother.
>In general though Groovy/Grails is actually surprisingly good.
I'll second that. Groovy is amazing but under appreciated on places like hacker news. Interesting that you bring up python because I find groovy very pythonic in some ways. Even more so with the new type hinting stuff python is introducing.
Although for lighter weight web stuff I've been watching the http://ratpack.io/ project.
> I'll second that. Groovy is amazing but under appreciated on places like hacker news
Did you know that VMWare pulled its funding for their 6 developers working on Groovy and Grails last March? Two of them got jobs as Grails consultants for Object Computing, two of them (one former Groovy tech and one former Grails) got jobs at Gradleware working on Gradle, one (the former Groovy P.M.) an unrelated job in France, and I don't know about the other one. There might not be much more work or maintenance done on either Groovy or Grails from now on.
>Did you know that VMWare pulled its funding for their 6 developers working on Groovy and Grails last March?
Because they shifted their focus to CloudFoundry only. This does not mean that Groovy or Grails are going to die.
>There might not be much more work or maintenance done on either Groovy or Grails from now on.
Yes. I am closely following grails development and you are true in this regards. There was no doubt a disturbance in community and even we were concerned about its future when we were in initial stages of our project. Right now, we are confident that this duo won't die anytime soon.
>Two of them got jobs as Grails consultants for Object Computing,
Good for Grails future as OCI has been providing grails based services in the past and is committed to grails future.
>two of them (one former Groovy tech and one former Grails) got jobs at Gradleware working on Gradle
Gradle being Groovy based is being used in Grails as well. Again it is good for the duo.
>one (the former Groovy P.M.) an unrelated job in France
> Because they shifted their focus to CloudFoundry only
Although VMWare/Pivotal said they were pulling their funding for Groovy and Grails in order to shift their focus to CloudFoundry only, that doesn't explain why they held onto Spring. Groovy/Grails and Spring were managed and promoted together, and the more likely reason is the Spring team didn't want Groovy/Grails attached and petitioned the VMWare managers to dump them. Perhaps the Groovy and/or Grails people were trying to take over in some way. Grails 3.0 released in March now bundles Gradle as well as Groovy and Spring from before, perhaps another predatory move. It could explain why Gradleware recently employed two of the retrenched Groovy/Grails developers from VMWare, to help in protecting their product against takeover by bundling.
I am not a rails developer but I have seen that rails developer have alot of inertia and they won't switch to grails. Grails is only attracting Java developers who are fed up of exhaustive configurations. Unfortunately books written for grails also assume that you are switching from one of java to grails.
I think you are right that there are a lot of developer worker bees in MN who are not excellent.
However, there is a somewhat tight-knit subpopulation of developers that are forward thinking, talented and excellent at CS. You will find them at various tech meetups or at events like minnedemo. A lot of them are alums or connected to alums of some of the startups here (yes we do have them!). I'm thinking of Bloom Health, SmartThings, HomeSpotter, Code42, Gravie and a few others I'm forgetting.
The key to finding talent in MN is a little bit of networking, it is definitely out there.
I've heard of them before. Seems like they are largely for bigger players with offline touchpoints. How do they do with online SaaS companies with sales cycles 30-90 days out and a variety of content efforts, social media, video campaigns, etc.?
Also, would I need an ad server in place to properly attribute display or can they handle that on their own?
I think you are right they are targeting large advertisers with significant spend.
It's a unique approach in that they don't need a lot of granular attribution data, but instead use higher level aggregate data. As a result it's easier to integrate with all kinds of media campaigns.
You need to be able to provide impressions over time for your early funnel ads and conversions over time for your late funnel touchpoints. They use some econometric time series techniques to analyze and estimate the impact so you can focus on whats working.
Interesting, thanks for the details. Right now I'd give anything for a dynamic attribution solution that didn't cost an arm and a leg and could be used at the level of volume a SMB deals with.
GA's attribution tools are fun to play with, but at the end of the day they are still static models that don't evolve over time as they collect data.
I certainly appreciate the syntactic sugar of Groovy as a clear improvement over vanilla Java. But with time as a scarce resource I've opted to learn Scala and Clojure instead. It would be great if somehow we could smush Gradle and sbt together to build a best of all possible worlds build system for Scala.
Back in 2009, James Strachan (the creator of Groovy) stated that if he'd known about Scala first he probably wouldn't have built Groovy [1]. This Dr. Dobb's article [2] also has some good points on evaluating Groovy and whether or not it will continue to thrive. The simplicity of its syntax vs scala is a great point for Groovy though.
> It would be great if somehow we could smush Gradle and sbt together to build a best of all possible worlds build system for Scala
www.gradle.org/overview does say "The Gradle design is well-suited for creating another build script engine in JRuby or Jython. It just doesn't have the highest priority for us at the moment. We happily support any community effort to create additional build script engines."
I have looked at the Gradle source code and Groovy seems to be tightly entangled in it, and it would be difficult to get Gradle to use another DSL language. I'm also doubtful about what they say about happily supporting community effort to create other script engines. Based on my previous experience with the people behind Groovy, not only with regards to the Groovy++ fiasco of mid- to late-2011 but many times before, that line could easily mean "We're happy to hear about any community effort to create additional build script engines so we can scuttle your attempt before it gets very far."
> The simplicity of its syntax vs scala is a great point for Groovy though
Did you say Groovy's syntax is simple? The Gradle DSL is just a tiny subset of Groovy's grammar, see [1]. It's also still stuck on Antlr 2 because no-one wants to try upgrading it to Antlr 4. Scala was designed so its grammar would be light and the functionality residing in the libraries.
Thank you for these links! I love programming history and the many things you can learn about your tools.
I am stuck on a few projects at work using Groovy/Grails. Groovy itself has been fine and I regularly switch between Groovy, Python and JavaScript with little more than a Google to double check syntax.
However dealing with Grails is a damn nightmare. I recently ran into a bug where grails parsed a parameter query variable containing a nbsp symbol. Instead of giving me a string with an nbsp character, it inserted an "A" with an accent mark in addition to the ndbsp character. Two for the price of one!
The best part was, this only happened after I compiled the app to a war file so it didn't show up in development.
This is the 3rd parsing bug in grails I have found in the last few months alone.
Another one was the when using "render as obj as JSON" shortcut for controllers. The parser was converting "</" characters into a single Unicode character. Causing the HTML string I was trying to render break. However doing the conversion to JSON manually in a service class and setting the right response headers then returning the JSON string worked fine.
The third one was XML builder. Errors are thrown if I have empty leaf nodes (at a minimum I need to add {} to the end of leaf nodes). Only works in dev however as gain when I build the war it does not work at all. Instead I just build my XML string manually.
The final thing I don't care for is the GORM. We have never gotten DB auto reconnect to work with any MSSQL server or DB2 in the last 2 years (that we have been actively trying to get it to work) across 4+ applications.
> Back in 2009, James Strachan (the creator of Groovy) stated that if he'd known about Scala first he probably wouldn't have built Groovy [1].
I wish people would stop quoting this as if it is some kind of damning evidence against Groovy as a language. It is sad because I often want to say generous things about frameworks and tools that are competitors to ones I am involved in, but then I remember how ruthlessly and persistently people exploit this line (almost guaranteed to get quoted in every Scala discussion if someone mentions Groovy) and I realise that in the real world you can pay a lot for being generous at the wrong time.
Very True. I'm pretty sure that quote wasn't meant to be a critique of the Groovy language, just an expression of interest in Scala. Yet its brought out every time somebody wants to dismiss Groovy.
Compare that quote to this[1] presentation where Paul Phillips lays in to scala for 50 minutes. Even when somebody does criticize their own creation I doubt they mean "Hey everybody, that thing I spent a bunch of time on? Throw it all in the garbage, its pointless".
Don't most people in the JVM ecosystem know about groovy by now? I first heard about it when Maven 2 betas were coming out and it was the preferred way to write a plugin.
Our startup is writing "enterprisey" B2B knowledge management software, but almost all of our code is written in Groovy. But I'm "hip to it" enough to at least own several Clojure and Scala books and have both on my "to learn" list. shrug
Personally I'm a big fan of Groovy. It gets an awful lot of things right, IMO. The syntax is mostly a superset of plain Java, but a lot of things that are required in Java are optional in Groovy. But Groovy is dynamic and has meta-programming, closures, dynamic typing, etc. For my money, it really hits the sweet spot. Easy to learn for a Java person, but way more productive than Java.
> Enterprisey J2EE people regard it as a new fangled something they don't have time for.
Back when I was part of a project that was developing a JSF framework on top of RichFaces, I started pushing for Groovy support on our SDK.
This was 2009, Groovy was everywhere on JUG talks in Germany, most talking about Grails success stories. On the same year while attending JSF Days in Austria there were some Oracle guys showing how to do JSF applications in Groovy and the possible inclusion the the next J2EE revision.
Other team on the same company was replacing the Perl battle tested installation scripts by Groovy ones.
Nowadays, if it wasn't for Android Studio and its dependency on Gradle, I would hardly notice its use.
Names do have some importance. Calling your programming language Groovy is like calling it "Sweet Hotness." Nobody wants to explain to their boss that they think they should write something in Sweet Hotness, and likewise Groovy.
as another "enterprisey" type I vastly prefer clojure or scala. either go full on static typing or full expressivness. groovy is too middle of the road for me.
I've used Groovy extensively for 4 years or so now. A product we used that ran on JBoss decided to use it as the plugin language to extend / use internal APIs. I really pity Java people who don't know or haven't used Groovy yet. It's like embedding Lua into your C app. Why people still write the bulk of their code in pure Java is beyond me.
The other day I learned that Solr supports Groovy as an embedded language to write extensions in. It's amazing.
You say that with intent to imply it must be a bad reason, it's a little underhand. There are lots of reasons Groovy is not well appreciated. It's name is terrible, the community has always had a somewhat amateurish image (in stark contrast to the actual professionalism of what they do), it's choice to blend in seamlessly with Java and adopt as much Java syntax as possible made it decidedly unsexy with the crowd want to push new language concepts. It got a bad reputation for being slow early on (quite undeserved since it was always about as fast as comparable languages).
I think it's actually used incredibly widely but people don't even know it, Gradle being an example, but lots of other similar cases. Groovy just doesn't get credit a lot of the time because it embeds so seamlessly in to the Java world.
I think this due to Groovy's fragmented ecosystem (Groovy's 2 big recognizable projects, Grails and Gradle, don't play well together) combined with the fact that you can't use Groovy everywhere you use Java.
No. L2 regularization (ridge regression) also has an analytical solution, and L1 regularization (lasso) can be more efficiently solved using the LARS (least-angle regression) algorithm.
Gradient descent would work for ridge regression (it would just be slow). It wouldn't even work for lasso, because the penalty function isn't differentiable at the origin.
I'm not sure about haskell, but in clojure the, run code, reason, run more code cycle is very much supported with the repl.
In fact I find the nature of functional code very much helps out here. With clojure, in a complicated system I can typically take any subcomponent and run it in the repl without much fuss/mocking or worrying about the state of the system. Since usually functions aren't modifying state I can rerun, modify, rerun over and over again without restarts.
Like Clojure (which I have used a lot), Haskell development uses a repl (with really nice emacs support). For bottom up coding, I place a main function in every file with my test and experiments code; with an active repl in emacs it just takes a few seconds for the edit/run loop. In lower level code, I leave these main functions in place even though I am unlikely to need them once the code is working.
So, yes, Haskell and Clojure development has a similar flow.
Oh, absolutely. But I wasn't counting Clojure as FP in my comment. There is no definition for FP, and the OP seemed to be talking about the statically typed, pure FP, of Haskell and scalaz. Clojure is certainly not that kind of FP, as it's neither statically typed nor pure.
It's not the only functional language by any means, but it is the strictest (he he.) It's silly arguing which is worth more, but it's also silly saying "Clojure is just as good as Haskell at separating effects."
You end up with broken code. If you are lucky it has a syntax error. If you are not lucky you get mysterious bugs.
The work around is to go back and try re-editing the file to retrigger a sync.
There are lots recommendations to try Fusion over Vbox but I think this issue makes it a wash.