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

51–60 of 82 posts

Re: Advanced programming languages

#51

Post by Artemidoros »

chc wrote: post #44
Artemidoros wrote: post #33

Earlier quoted context omitted.

Using implicits is really nice to clean up the interface to some Java APIs (especially for APIs making heavy usage of anonymous inner objects) but I experienced more ugly boilerplate than I would like when having to use Java collection classes from Scala, too. 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…

Out of curiosity, what do you mean by "fixing typing"? (I'm genuinely curious. I don't know Scala and F# well enough to really understand.)

e.g. is SomeCollection a subtype of SomeCollection (using Java like Syntax)? For some type of collections in some kind of circumstance this might be sensible (e.g. when your collections are immutable), sometimes having an inverse relationship might be appropriate and in some case you don't want these two types to be related at all (like Java collections - Arrays being the exceptions).

Co/Contravariance (maybe View Bounds?) in Scala enable you to encode this relationship, but from my understanding are somewhat handicapped by type erasure.

Another problem Scala tackles is that using inheritance as a 'code sharing facility' is a bit tricky (e.g. tractability and fragile base class problem) and not composable. Scala's traits and Self Types are a real improvement in this regard. That the order of mixing in traits can have an influence the objects behavior while not its type can be seen as a problem though.

F# takes the .Net object system 'as is' and introduces 'types' more aligned to functional programming (aka. discriminated unions) as separate entities. It does not try to integrate both concepts as does Scala with its case classes.

Re: Advanced programming languages

#52

Post by Artemidoros »

crux_ wrote: post #48
Artemidoros wrote: post #33

Earlier quoted context omitted.

Using implicits is really nice to clean up the interface to some Java APIs (especially for APIs making heavy usage of anonymous inner objects) but I experienced more ugly boilerplate than I would like when having to use Java collection classes from Scala, too. 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…

> 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)

Re: Advanced programming languages

#53

Post by Artemidoros »

crux_ wrote: post #50
chc wrote: post #44

Earlier quoted context omitted.

Out of curiosity, what do you mean by "fixing typing"? (I'm genuinely curious. I don't know Scala and F# well enough to really understand.)

My guess as to what the poster was about (warning: sleep deprived today, rambling ahead): F# has basically two type systems -- the O'Caml/ML one, and C#'s. As a plus, you get full type inference so long as you stick with ML discriminated unions or records; as a minus, you lose the ability to apply concepts from OO without converting them to classes -- in which case you lose the ability to apply some handy ML-isms. Sc…

yes thats about what I meant, and more concise than my own explanation :-)

Re: Advanced programming languages

#54

Post by Artemidoros »

KirinDave wrote: post #43
Artemidoros wrote: post #34

Earlier quoted context omitted.

Your friend might be wasting a lot of effort (apart from his personal learning experience), as Phil Bagwell is working on Scala's collection library.

“A lot of effort?” Wrapping the PersistentMaps took like less than 200 lines of code: http://github.com/codahale/yoink

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.

Re: Advanced programming languages

#55

Post by KirinDave »

Artemidoros wrote: post #54
KirinDave wrote: post #43

Earlier quoted context omitted.

“A lot of effort?” Wrapping the PersistentMaps took like less than 200 lines of code: http://github.com/codahale/yoink

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.

Re: Advanced programming languages

#56

Post by chc »

jmillikin wrote: post #49
chc wrote: post #45

Earlier quoted context omitted.

To give a concrete example: The printf function in Haskell takes on the responsibilities of both the traditional printf (printing to the screen) and sprintf (generating a formatted string). Haskell knows which it's supposed to do based on whether the return value is used in an IO context or as a string.

Which is, when you think about it, not a good idea. If 'sprintf' is defined, then 'printf' ought to be simply 'putStr . sprintf'.

But sprintf is not defined in Haskell, nor is it really needed. printf returns a typeclass that includes both 'String' and 'IO a'.

Re: Advanced programming languages

#57

Post by barrkel »

ekiru wrote: post #30
barrkel wrote: post #16

I smiled when I read this: Haskell's type system literally allows the compiler to infer the correct code to run based on its type context It literally has overloading! Imagine that!

How many other programming languages have a type system that supports overloading on both parameter types and the desired return type?

Languages with operator overloads, including typecast ops.

Re: Advanced programming languages

#58

Post by jmillikin »

chc wrote: post #56
jmillikin wrote: post #49

Earlier quoted context omitted.

Which is, when you think about it, not a good idea. If 'sprintf' is defined, then 'printf' ought to be simply 'putStr . sprintf'.

But sprintf is not defined in Haskell, nor is it really needed. printf returns a typeclass that includes both 'String' and 'IO a'.

My point is that there should be no typeclass; there's no reason to combine IO and formatting in the same function, and doing so makes it more difficult to read and modify code.

Re: Advanced programming languages

#59

Post by DrSprout »

xi wrote: post #32
DrSprout wrote: post #28

Earlier quoted context omitted.

It's rather semantic, but I would differentiate typed from untyped by type checking vs. type being an inherent property of a variable. So you have something in Scheme like: (define foo 1) (define bar "1") And that is typed, the former being a number, the latter a string. If you try to subsequently do: (+ foo bar) the program will error out. Contrast this with what I would consider an untyped language like Python or P…

Python is as strongly typed as Scheme; 1+"1" will produce an exception in Python.

Thanks. Point stands on Perl. Also... BASIC, among others.

Re: Advanced programming languages

#60

Post by codahale »

Artemidoros wrote: post #54
KirinDave wrote: post #43

Earlier quoted context omitted.

“A lot of effort?” Wrapping the PersistentMaps took like less than 200 lines of code: http://github.com/codahale/yoink

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.

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.

Post reply on HN