Disqus - Latest Comments for Daniel Spiewak

Re: Google IG and Sudoku - Miguel de Icaza

Daniel Spiewak — Sat, 17 May 2008 22:22:52 -0000

For the record, the "bug" has been examined and duly considered by the Firefox team. As it turns out, this is actually a problem with the Silverlight detection script shipped by Microsoft. Apparently, the whole thing hinges on a private API with undefined behavior. Naturally, it's annoying that Firefox 3 doesn't support Silverlight, but putting the blame on Mozilla is misleading at best.

Re: Beware of polyglot programming

Daniel Spiewak — Wed, 11 Jun 2008 14:57:35 -0000

While I agree that polyglot programming is over-hyped and dangerous, I'm not sure that your reasoning is sound. As a previous commenter pointed out, a lot of the "polyglot languages" being pushed these days already run on the JVM. Some of these languages (such as Scala, Clojure, Groovy, etc) even go so far as to use the same call-stack and internal runtime semantics as Java. For such languages, the intrinsic performance penalty is extremely minimal. Obviously Groovy imposes all the overhead of a dynamic language, but Scala is just as fast as Java (even faster for some operations). Interop between such languages really seems to be the only significant overhead (loading the extra support libs, etc), but because the call stack is shared, "polyglot calls" are really just the same as normal Java method invocations.

Your arguments also make the assumption that developers are jumping into polyglotism blindly without considering the performance implications at all. I don't think this is the case. When I use Ruby for something, I'm well aware that there are much faster (in terms of runtime performance) options. Given the vociferous nature of most language proponents, it's hard *not* to be aware of the performance minutia of modern languages, especially as they compare to old stand-bye languages like Java.

There are a lot of reasons to be wary of polyglot programming, but I don't think performance is one of them.

Re: Beware of polyglot programming

Daniel Spiewak — Wed, 11 Jun 2008 17:42:21 -0000

Ruby documentation: http://ruby-doc.org/core/

The problem with benchmarking this sort of thing on JRuby is the platform has significant overhead, both in startup time and invocation cost. Ruby is an almost excessively dynamic language. It lends itself extremely nicely to metaprogramming and other nifty tricks, but this dynamic nature also precludes use of the native JVM call stack for most situations. For this reason, JRuby has quite a bit more overhead associated with a simple call than does Scala or Clojure. Also, JRuby has a fairly large runtime (including JIT) which must be init'd prior to doing anything. Groovy has something similar, but with Scala it's all just part of the JVM. Scala *literally* compiles down to Java-equivalent bytecode, there is no runtime or indirection layer other than the JVM itself.

I think I agree with your central point, that the use of additional languages just to be "trendy" introduces unnecessary overhead and performance costs, but when judiciously applied, this overhead can be acceptably mitigated or even less-costly than the same algorithm handled in the single "main" language.

Re: Java : the perpetually undead language

Daniel Spiewak — Thu, 11 Dec 2008 12:56:18 -0000

I would be curious how you consider other JVM languages or even Python on the JVM (Jython). The main reason you listed for choosing Java over Python is portability and long-term relevance. In order for Java to make it for the next 10 years, the JVM will also need to stick around. If that's the case, then other languages like Jython, JRuby, Groovy and *especially* Scala will be able to run without a hitch. (I say "especially" because Scala's output bytecode is much closer to Java's than the other three languages, meaning that future changes to the JVM intended for Java will affect it less).

Re: http://brizzled.clapper.org/id/87

Daniel Spiewak — Sun, 15 Feb 2009 02:56:37 -0000

Have you considered SBT? It's basically what you just wrote, except with some more time in grade. Personally, I use Buildr for my Scala projects. It's not a Scala-based build script specification (it's based on Rake), but it is quite concise and manageable.

Re: Functional code != Good code

Daniel Spiewak — Thu, 14 Aug 2008 23:49:25 -0000

I've seen a fair bit of code which over-uses functions like fold and flatMap. Heck, I've even *written* code like that! I think the reason it exists is a lot of people using functional programming in any language (including Scala) are those who learned its precepts under the cruel lash of a more strict language. Think about it, if you learned how to code in Haskell or even Lisp and then tried to learn Scala, you would end up producing some hideously functional code. Now, this isn't as bad as it could be in languages like Java using its sorry-excuse-for-a-lambda, but it is still a problem (if nothing else, because non-trivial Scala is much more verbose than the equivalent Haskell or ML, partially due to the differences in type inference algorithms).

I think that your point is spot on: don't marry yourself to a particular methodology just because it solves *some* problems well (or even worse, just because it's "hip"). Even Scala's standard library adheres to this principle, implementing functional constructs (like everyone's favorite persistent collection: List) using imperative algorithms for efficiency.

While I think that it is *rare* that a trivial computation such as the ones you illustrated can be cleaner imperatively than in the functional style, there do exist many examples of a non-trivial nature for which this holds. The beauty of Scala is that it doesn't restrict you to one or the other, letting you mix and match, getting the best of both worlds. I suppose that sounds like PR, but it really does solve this problem of divergent methodologies quite nicely.

Re: Functional code != Good code

Daniel Spiewak — Fri, 15 Aug 2008 13:19:35 -0000

WRT the implementation of sum, I would *like* to do it this way (doesn't compile):

type T = { def +[A <% T](o: A): T }
def sum(nums: Iterable[T]) = nums.reduceLeft[T](_+_)

Scala doesn't support self-referencing types (classes are fine, types are not). I'm sure there's some deep theoretical reason why this is, but it does get a little annoying for situations like this one.

Re: Is Maven going away?

Daniel Spiewak — Sun, 06 Jul 2008 13:20:14 -0000

You should give Buildr a try. I've had some issues with it (particularly installation), but they seem to be working hard to resolve them. It's somewhat similar to Gradle in that it is a drop-in replacement for Maven2, but quite a bit more concise (at least based on the examples I've seen).