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

61–70 of 82 posts

Re: Advanced programming languages

#61

Post by jacquesm »

francoisdevlin wrote: post #7
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.

I seriously think Clojure is too much to take in at the first introduction. It's really hard to get your brain around everything done right, when compared to traditional programming. You need to use it for a while to really get why it's approach to state (not concurrency) is awesome.

I keep asking for, and I will do so again here, a non-toy web application written in clojure as a study object for newbies to dissect. That would help a lot.

Re: Advanced programming languages

#62

Post by swannodette »

jacquesm wrote: post #61
francoisdevlin wrote: post #7

Earlier quoted context omitted.

I seriously think Clojure is too much to take in at the first introduction. It's really hard to get your brain around everything done right, when compared to traditional programming. You need to use it for a while to really get why it's approach to state (not concurrency) is awesome.

I keep asking for, and I will do so again here, a non-toy web application written in clojure as a study object for newbies to dissect. That would help a lot.

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?

Re: Advanced programming languages

#64

Post by silentOpen »

barrkel wrote: post #57
ekiru wrote: post #30

Earlier quoted context omitted.

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.

Most languages with operator overloads don't have inferred static type-checking woven through them, though.

Re: Advanced programming languages

#65

Post by Artemidoros »

codahale wrote: post #60
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.

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?

Re: Advanced programming languages

#66

Post by barrkel »

silentOpen wrote: post #64
barrkel wrote: post #57

Earlier quoted context omitted.

Languages with operator overloads, including typecast ops.

Most languages with operator overloads don't have inferred static type-checking woven through them, though.

On the contrary, almost all statically typed languages with overloaded operators use type inference to type subexpressions; it's how they do type checking and produce type errors. Type inference for named values, or locations, or functions is one thing; but type inference of expressions is everywhere. If you consider '+' as overloaded on ints, floats etc., even C uses type inference to infer a type for '4 + 0.5'.

Re: Advanced programming languages

#67

Post by loewenskind »

jmillikin wrote: post #58
chc wrote: post #56

Earlier quoted context omitted.

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.

Agreed. This is something I dislike about Haskell. After seeing the regex class and it tons of contexts I was just thinking "didn't they learn anything from perl?".

Re: Advanced programming languages

#68

Post by jacquesm »

swannodette wrote: post #62
jacquesm wrote: post #61

Earlier quoted context omitted.

I keep asking for, and I will do so again here, a non-toy web application written in clojure as a study object for newbies to dissect. That would help a lot.

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.

Re: Advanced programming languages

#69

Post by silentOpen »

barrkel wrote: post #66
silentOpen wrote: post #64

Earlier quoted context omitted.

Most languages with operator overloads don't have inferred static type-checking woven through them, though.

On the contrary, almost all statically typed languages with overloaded operators use type inference to type subexpressions; it's how they do type checking and produce type errors. Type inference for named values, or locations, or functions is one thing; but type inference of expressions is everywhere. If you consider '+' as overloaded on ints, floats etc., even C uses type inference to infer a type for '4 + 0.5'.

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, enforce contracts, and define the very laws of mathematics.

Perhaps if you don't know Haskell, you should learn Haskell to understand what the article is saying.

Edit: This might help: http://www.haskell.org/tutorial/classes.html

Re: Advanced programming languages

#70

Post by barrkel »

silentOpen wrote: post #69
barrkel wrote: post #66

Earlier quoted context omitted.

On the contrary, almost all statically typed languages with overloaded operators use type inference to type subexpressions; it's how they do type checking and produce type errors. Type inference for named values, or locations, or functions is one thing; but type inference of expressions is everywhere. If you consider '+' as overloaded on ints, floats etc., even C uses type inference to infer a type for '4 + 0.5'.

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 add more constraints to an inferred type (e.g. use an operator or function defined on a typeclass not previously brought in), and consequently break clients of the module.

Post reply on HN