Hacker News Reader

"dynamic and functional"

I don't understand what you've said here. The two terms are entirely orthogonal. There are functional langauges which are dynamically "typed", and there are functional languages which are statically typed. Lumping the two terms together is misleading and useless.

Static typing (done correctly) is just straight up better than dynamic typing. End sentence. I cannot count the number of times I have had errors at runtime working in python that simply would not have existed at all if I was using a statically typed language. With a sufficiently expressive type system, the types do not get in the way, but you still get compile-time enforced correct static semantics.

I agree. Static typing is great. I don't know why all these scripting languages choose to throw out static typing. If a variable is always going to be an integer I don't know why its important to be able to stick characters, strings or objects into it without seeing any errors. It's good for a beginning programmer perhaps, but even with that I tend to disagree since it encourages bad practices.

At some point I just got tired of seeing the same types of errors and wanted my tools to work a lot better. Python / PHP / Ruby aren't improved by lacking static types. How hard would it be to add static types into PHP, Ruby, or Python?

http://stackoverflow.com/questions/1365333/will-php-become-a...

I'm a big static typing fan, but the facts are out there, startups use Rails and Django, and front end is JavaScript, all are dynamically typed, yet very popular.

A good static typed language that the only difference between it and Ruby / Python is the type system, has a good chance in being accepted by a larger audience of developers, both enterprise and startups.

People prefer dynamic as they don't like to compile, and it provides rapid code / refresh cycles, I don't think anyone would say no to less bugs and better refactoring, and to self explanatory APIs using content assist.

I meant to say "more inclined toward dynamic over static, functional over object oriented." didn't mean to tie functional and dynamic together, thanks for the clarification.

Scala is a great statically typed functional, object oriented language, which allows most people to enjoy both worlds.

By the way, I agree with all you said, I hope it's evident I'm a big static typing fan.

what languages, if any, do you think get static typing right?

Haskell and SML both have sufficiently expressive type systems that I do not ever find myself writing correct code that fails to typecheck. If the code fails to typecheck, I have done something wrong.

(If the code does typecheck, then I have guaranteed a lot of static properties of my code, but it may still be incorrect in terms of dynamic semantics.)

This is probably sounds insulting, but I just wanted to give you a warning.

I spent some time deciding if your first sentence was a parody (Look at us new vim mac users with functional languages and git and startups).

Very sorry that I am a C++ programmer, working in visual studio, as opposed to writing the latest to-do app in scala using vim.

I'm using eclipse, and I can't leave my IDE, but I admire people who managed to free themselves from being dependent on an IDE, autocomplete / content assist. I tried VIM / Emacs / TextMate, didn't work for me, but perhaps I'm too old for new tricks, and already hooked to eclipse's shortcuts (ctrl+1 has no equivalent, I hardly need to write code, it's 50% shortcuts) I did like SublimeText 2, and use it for sass / scss / CoffeeScript and node development.

No parody was intended, I have all respect to all developers where ever they are and what ever IDE / non-IDE they chose to work with.

Half the people pushing Scala tout Scala's tooling ecosystem.

I use IntelliJ IDEA with the Scala plugin and you get code-complete and type aware tooling.

In fact every developer I know that writes production Scala code uses an IDE.

I have fuckall of a clue what an IDE has to do with Scala except for some sort of lifestyle statement.

> Scala does a wonderful thing, it allows enterprise developers to taste some of the goodies of Ruby / Python but stay in static Java land.

rpearl already made a similar objection, but I think you're confusing things a bit here. How much of Scala is influenced by Ruby and Python? Aren't the main goodies in Scala related to the type system?

Programmers using those "mainstream" dynamically typed languages don't have terribly much to be smug about, sure they're less verbose than Java, but I'd suggest they should also invest in learning a functional language or two, like Scala.

scala offers a syntax of programming similar to ruby especially in terms of collection operations. i found this to be a big win over java.

scala: List(54,2,46).filter(x => x == 2) ruby: [54,2,46].select{|x| x == 2}

C#: new List<int>{54, 2, 46}.Where(x => x == 2)

It's kind of interesting to see that the myth that functional and object-oriented programming are somehow mutually antagonistic is so readily accepted that it can even be perpetuated in an ode to an object-oriented functional language such as Scala.

"Scala does a wonderful thing, it allows enterprise developers to taste some of the goodies of Ruby / Python but stay in static Java land. which is great news for everyone."

Groovy does the same thing with less friction and switching overhead.

Nanana... I know both, and Scala and Groovy are complety different tools

Groovy is great to Websites and fast development they remove the code complexity and verbosity of java using type inference, some functional goodies like closures and add DSL capabilities,I use it everyday and it's a very nice tool.

Scala is another kind of tool, it also does type inference and add functional goodies and support DSL BUT it have a deep love to parallelism (actors and non mutable objects as an example) and is way closer to the functional paradigm than Groovy, but it's more complex.

So you gotta choose wisely so you don't end up with the hammer to a screw kind of problem.

My view:

Groovy is for fast development and WEB stuff mainly because of Grails which is an awesome tool as well.

Scala is more a backend tool when you need Horse Power, but that's because the lang is more complex, I don't like Play and Lift is not as easy to understand as Grails.

Again no Flamewars please.

Wasn't trying to start a flamewar. Yes, they're completely different tools. Per the original quote though

"it (scala) allows enterprise developers to taste some of the goodies of Ruby / Python"

Groovy fits that bill far better than Scala if you're primarily looking for a taste, without having to adopt the complexity of a new worldview.

I am sorry I said no flamewars because of what I was saying, to point that I didn't want to start one.

Your answer was not the flamewars kind at all.

And yes Groovy fits perfectly in that statement.

> Scala is another kind of tool, it also does type inference and add functional goodies and support DSL BUT it have a deep love to parallelism (actors and non mutable objects as an example)

I believe Groovy also supports actor concurrency via gPars. That said, I still haven't seen anything like Akka on any other language, specifically its distributed processing p2p feature. To me Akka is Scala's 'killer app'. I agree I don't like the new Play framework. I didn't mind the magic being taken away but with taking the magic out, they also killed any form of convenience without providing a replacement.

" I stil haven't seen anything like Akka on any other language".

You can use Akka from java but the messages are effectively dynamically typed which isn't a big deal. However, as Rich Hickey said, a queue is simpler than an actor (Go understands this also). Java has excellent blocking queue implementations. In fact java has libs that support all kinds of concurrent solutions and they are not that complex.

I still like Scala though (and really like Go but my work is on the jvm)

> You can use Akka from java

True, but I just got sick of Java being a 2nd class citizen on Akka.

> In fact java has libs that support all kinds of concurrent solutions and they are not that complex.

hmmm does java have a distributed concurrent solution that isn't complex? Aside from Akka, I am not aware of any.

I like Groovy, but I think even the author said once that if he knew about scala, he might have not invented Groovy (if anyone knows the link to the quote, and if it's indeed true, please comment)

It was James Strachan who said that. He is credited with the initial idea and set the project in motion in 2004. He stopped commiting in 2005 and Groovy 1.0 was released in 2007.

He made the scala statement in 2009. He's certainly entitled to his opinion. But I find the title "Author" or "Creator" a little harsh to people like Guillaume Laforge and others who have really brought the project from beta to 2.0 in the 7 years since he quit.

James Strachan set the Groovy project in motion in mid-2003, not 2004. He stopped posting to the mailing list in December 2005. James credits Bob McWhirter as being his co-creator.

Jochen Theodorou led the technical effort on Groovy since then. Other major committers over the last 5 years include Paul King, Alex Tkachman, Cedric Champeau, and Jeremy Rayner. I don't know for sure about before that. Guillaume Laforge's main technical effort was writing some utility functions very early on.

Although Guillaume has the title "Project Manager", he's really No.2 to the real management force behind Groovy, i.e. Graeme Rocher, who leads the Grails development. If Grails switched languages, Groovy would disappear almost overnight as it's not used much in anything else significant. OReilly's total worldwide book sales of Groovy (all titles) over 12 months is 1205 books (http://radar.oreilly.com/2012/04/computer-book-market-2011-p...).

> really brought the project from beta to 2.0 in the 7 years since

A few weeks before Groovy 2.0's "final release" in June this year, Grales 2.1, Griffon 1.0 and Gradle 1.0 were all released, bundling Groovy 1.8. Listen to what Groovy's users are doing, not what its fanboys are saying. Groovy 2.0 is nothing more than beta-quality software offered to production users so they'll "unit test" it in their workplaces. No-one should be using Groovy 2.x until Grails bundles it.

"Groovy 2.0 is nothing more than beta-quality software offered to production users"

Unlike, of course, every other piece of software's x.0 release, which are always 110% battle hardened and tested through years of rigorous process, ensuring no downtime, data loss or corruption, and smooth sailing. Yea, groovy's totally unique in that. I bet they just made some random commits during the final 2.0 bundling without even looking at the keyboard while they typed as well.

Groovy book sales were down. So what? Maybe groovymag has had an adverse impact on oreilly? :)

When Groovy's two biggest users (i.e. Grails and Gradle) each release a major point version (Grails 2.1 and Gradle 1.0) less than a month before Groovy 2.0's release, that says more about what their project managers think about Groovy 2.0's production-readiness than anything they or anyone else might say.

Groovy 2.0 bundles two jars, one for Groovy scripts using Java 7's invoke-dynamic, the other for scripts using type-checking and static compilation available via optional annotations. Invoke-dynamic and type-checking/compilation _can't_ be used together: you need to choose only one jar to use. The roadmap plan is for them to be merged together in Groovy 2.1. Groovy 2.0 should never have been released until it was a single functioning jar.

I don't see the lack of faith thing as much as you. I see it as the features those projects have been working on don't rely on any Groovy 2.0 functionality, so they'll push it out sooner and give people more functionality in those projects now, and explore the impact on Groovy2 on their respective projects after it's release and shakes out.

> Groovy does the same thing with less friction and switching overhead.

Are you the same M.Kimsal who sells subscriptions to "groovymag" ?

Yes I am. To the extent I have a vested interest in Groovy, it may or may not be relevant to my original post. My larger point was, as I said before, if the purpose is to offer a 'taste' of dynamic functionality, a la ruby/python, to Java developers, Groovy is a much simpler way to go about it. Should people then get a real hankering for it, you've got more options, either with more groovy, or jruby or jython or scala or what have you. Nothing more.

Umm, so you're saying vi is "new wave"?

No, but having young fresh out of college developers prefer it over eclipse/VS, is new (to me), but I have a very narrow point of view of only the people I know from college / work / online.

I don't understand why the RoR community needs to endorse Scala as sucking less than Java?

Not every amazing new technology is a Bootstrap website fronting a Facebook for ferrets social network game, my friend

hey that's a good idea. the ferret industry clearly is ripe for market disruption.