Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advanced programming languages

matt.might.net

Post reply on HN
Print view View original

71–80 of 82 posts

Re: Advanced programming languages

#71

Post by swannodette »

jacquesm wrote: post #68
swannodette wrote: post #62

Earlier quoted context omitted.

What would qualify as non-toy? With Ring and a routing library like Moustache what more do you really need for building a non-trivial web application in Clojure?

Well, you outline the problem really nicely there. Never heard of Moustache, and the problem is in figuring out how all the bits go together and what is the 'best' way of doing this in clojure. The learning curve for the language alone is steep enough that having a non-trivial example would do wonders in terms of understanding how a clojure based website works under the hood.

If you've ever worked with light weight http framework in Python or Ruby, it works exactly the same way.

http://mmcgrana.github.com/2010/03/clojure-web-development-r... http://github.com/cgrand/moustache

There isn't a mature web framework for Clojure yet (for obvious reasons), so there isn't a popular "way". At the moment you have a lot of good libraries and you can put your app together in whatever way seems most sound to you.

Re: Advanced programming languages

#72

Post by Artemidoros »

KirinDave wrote: post #55
Artemidoros wrote: post #54

Earlier quoted context omitted.

Yes, 'a lot' is quite relative. :-) From my point of view 200 LoC giving me something I already have is a lot. From the point of view of your friend 200 LoC might be a very small price to pay for a good learning experience.

The back of your hand is going to get sore with all those compliments.

I did not have the intention of backhanding you or your friend. If my post had the appearance of doing so, I apologize.

I just wanted to point out the (for me at least) non obvious fact that the mind behind the theory of Clojure's persistent datastructures is working on Scala's collection library and that Scala's hash maps are already backed by hash tries - http://www.scala-lang.org/archives/downloads/distrib/files/n...

Re: Advanced programming languages

#73

Post by codahale »

Artemidoros wrote: post #65
codahale wrote: post #60

Earlier quoted context omitted.

I invite you to benchmark the two. I'm also slightly confused as to why you think reusing stable, proven, and reviewed data structure implementations is a "good learning experience" as opposed to being SOP.

scala.collection.immutable is/will not be stable, proven and reviewed?

The hash array mapped trie was committed to trunk 3 months ago and was first released in 2.8.0.RC1 (which no one uses due to various bugs) and is now available in 2.8.0.RC2 (which very few people are using due to binary incompatibility).

In contrast, Clojure's PersistentHashMap dates back to 2007 and was in both the 1.0 and 1.1.0 releases.

Re: Advanced programming languages

#74

Post by Artemidoros »

codahale wrote: post #73
Artemidoros wrote: post #65

Earlier quoted context omitted.

scala.collection.immutable is/will not be stable, proven and reviewed?

The hash array mapped trie was committed to trunk 3 months ago and was first released in 2.8.0.RC1 (which no one uses due to various bugs) and is now available in 2.8.0.RC2 (which very few people are using due to binary incompatibility). In contrast, Clojure's PersistentHashMap dates back to 2007 and was in both the 1.0 and 1.1.0 releases.

Is it unreasonable to expect that Scala's persistent collections will work comparably to Closure's when 2.8 final is released?

Re: Advanced programming languages

#75

Post by KirinDave »

Artemidoros wrote: post #72
KirinDave wrote: post #55

Earlier quoted context omitted.

The back of your hand is going to get sore with all those compliments.

I did not have the intention of backhanding you or your friend. If my post had the appearance of doing so, I apologize. I just wanted to point out the (for me at least) non obvious fact that the mind behind the theory of Clojure's persistent datastructures is working on Scala's collection library and that Scala's hash maps are already backed by hash tries - http://www.scala-lang.org/archives/downloads/distrib/files/n…

Good for Scala. When it's ready, people can use that. Until then, there are interim solutions.

And it's pretty neat to see a scala proponent call a scala project a "waste of time." Way to represent for your community, bro.

Re: Advanced programming languages

#76

Post by KirinDave »

mbrubeck wrote: post #27
KirinDave wrote: post #5

And a strong sell for Scala and no mention of Clojure. It confuses the hell out of me; clojure is fast, mature, and has a OO syntax and model to rival CLOS. It's got built in laziness and te best concurrency primitives I've seen to date (and I was a professional Erlang programmer). What does it take to break into the general public's consciousness? Clearly it's not the parens.

This article is from December 2008, when both languages were fairly young but Scala had been around significantly longer than Clojure.

Good point. I hadn't noticed that.

Re: Advanced programming languages

#77

Post by codahale »

Artemidoros wrote: post #74
codahale wrote: post #73

Earlier quoted context omitted.

The hash array mapped trie was committed to trunk 3 months ago and was first released in 2.8.0.RC1 (which no one uses due to various bugs) and is now available in 2.8.0.RC2 (which very few people are using due to binary incompatibility). In contrast, Clojure's PersistentHashMap dates back to 2007 and was in both the 1.0 and 1.1.0 releases.

Is it unreasonable to expect that Scala's persistent collections will work comparably to Closure's when 2.8 final is released?

That doesn't sound unreasonable, no -- at some point in the future, Scala's hash array mapped trie will be robust and highly optimized. If your plan is to wait until then, you might be able to speed things up by helping them out yourself.

In the meantime, I benchmarked Yoink's PeristentHashMap against 2.8.0.RC2's immutable.HashMap by a) creating a map of 100,000 sequential keys and then removing them all, and b) creating a map of 100,000 random keys and then removing 100,000 random keys. In the first case, Yoink was 20.7041% (±1.83693%) faster. In the second case, Yoink was 24.7834% (±4.17055%) faster. (Student's t distribution, 95% confidence interval, source is in src/test on the GitHub project and I used ministat for the statistical analysis [a cross-platform port of which is also available on my GitHub page].)

So to summarize, I have a provably faster hash array mapped trie at almost zero cost right now because I spent a few hours with a "good learning experience."

Re: Advanced programming languages

#78

Post by silentOpen »

barrkel wrote: post #70
silentOpen wrote: post #69

Earlier quoted context omitted.

I don't know if I'd call that "inference" so much as coercion, precedence and propagation. The exciting thing about Haskell type classes is precisely the integration with the type system and its modified HM type inference -- if you don't think the Haskell type system is cool, you probably won't be impressed much by its fairly elegant support for an abstraction that lets you overload operators, perform multidispatch,…

I already know Hindley-Milner type inference, and I do know Haskell well enough to understand typeclasses, monads, etc. I also believe that type inference is of limited practical application at scale. On a local level, internal to a module or function, it can make a lot of sense, but it's at risk of underspecification at the module interface level. For example, when you modify function bodies, you may inadvertently a…

This is definitely something that any interface author must deal with and is very closely related to the more OO-specific skill of "good interface design". It is important to include in an interface those types and type constraints that effectively and efficiently describe your problem domain.

OCaml (and potentially Haskell, though I haven't used this feature in Haskell) ameliorates this problem by giving the programmer the facility to specify (or generate and edit based on inference) module signatures that are then checked against. With this approach, I would argue that type inference actually makes your large-scale code more robust and easier to modify than without it due to the automatic verification of module signature. If you inadvertently introduce extra type constraints to your module's interface, the type-checker will tell you and save you from releasing a module that is incompatible with previous versions of the same module.

Without type inference, you're either annotating types everywhere (looking at you Java...) or waiting until runtime (or production!) to find out you've made an error (e.g. perl, python, ruby and on and on).

I really don't see how type inference and its associated program analysis and verification is anything but good.

Re: Advanced programming languages

#79

Post by Artemidoros »

codahale wrote: post #77
Artemidoros wrote: post #74

Earlier quoted context omitted.

Is it unreasonable to expect that Scala's persistent collections will work comparably to Closure's when 2.8 final is released?

That doesn't sound unreasonable, no -- at some point in the future, Scala's hash array mapped trie will be robust and highly optimized. If your plan is to wait until then, you might be able to speed things up by helping them out yourself. In the meantime, I benchmarked Yoink's PeristentHashMap against 2.8.0.RC2's immutable.HashMap by a) creating a map of 100,000 sequential keys and then removing them all, and b) crea…

I'm not disputing that Clojure's data structures right now are more performant than Scala's or that your project was worthless. I even apologized in case my original post was badly worded.

What I wanted to confer was that, you _might_ have been wasting a lot of effort because I assumed that you might not have been informed about work of the Scala team that has a high likelihood of obsoleting your project in the near future. Obviously you were informed and my notice was inappropriate. Be assured it won't happen again.

If increasing the performance by about 1/4 for your use cases - compared to the current beta - is valuable for you, great! For me it wouldn't have been worth a few hours. 'A good learning experience' would have. But obviously your values are different.

Re: Advanced programming languages

#80

Post by crux_ »

Artemidoros wrote: post #52
crux_ wrote: post #48

Earlier quoted context omitted.

> To be more specific, when I want to transform a collection given by a Java library in a functional manner, I usually ended up with one or two localized import statements - to avoid e.g. scala.collection.mutable leaking into my other methods - and additional calls to convert the Java collection into a Scala specific and back again. I think the other poster was right about this being more of a library issue than a la…

In my experience it was rare to do more than wrap Java collections to or from an Iterable[] Could you give me a simple example how say filtering and mapping a collection received by a java library and pushing it back to a method expecting a collection of the original type would look like? (quite likely that I overcomplicate this in my own code)

Sorry for the late reply.

Assuming you want your maps and filters to be purely functional, you need only two simple methods: One that constructs an object that implements the Iterable[X] trait from the java object, and another that constructs an instance of the java collection from an Iterable[X]. All the implementation that you'd like is already done for you in the iterable trait, but you can always selectively override them if you'd like to provide a more tailored implementation.

Then it's up to your taste whether you'd like the conversion methods to be implicit (and thus available with a single import but making your code more 'magic') or explicit (single import + adding calls to wrap/unwrap methods).

Total overhead: centralized conversion methods, assuming you write them yourself = implementation of elements(), and in the iterator, next() and hasNext(). One import per module that uses the conversions, and optionally, explicit calls to perform the conversion.

Post reply on HN