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

Don't Be Distracted by Superior Technology

prog21.dadgum.com

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Don't Be Distracted by Superior Technology

#61

Post by lutusp »

calopetreep wrote: post #51
lutusp wrote: post #50

Earlier quoted context omitted.

Java can produce any result that Haskell can produce. End of story, full stop. All non-broken computer languages are Turing machines. This is not to suggest that someone would want to use Java for anything sufficiently sophisticated, unless one is a masochist, but then, that wasn't your claim. > As far as I'm aware in Java, there's no way to write a function with a signature that says "Take two numeric arguments of a…

> Java can produce any result that Haskell can produce. End of story, full stop. Yes, I'm not disputing this- I'm fully in agreement that all turing-complete languages can compute all turing-computable computations. I've never been trying to argue against that. I'm sorry if I haven't explained myself clearly enough- let me give it another shot. In Haskell, I can write a function operating on numbers like this: f x =…

> As far as I'm aware, it's not possible to write this code in Java- you can't get the differentiated version of a Java function this way.

No. The algorithms for symbolic differentiation are well-known, they aren't unique to Haskell. They happen not to be present in any Java library AFAIK, but that's because no one is sufficiently masochistic to code them there.

(long pause ...)

Whoops -- I was wrong:

https://code.google.com/p/javacalculus/

> You can write a library which differentiates string-representations-of-functions, but you can't write one that differentiates first-class-Java-functions ...

I think we're getting into a moot area now. If the end result is symbolic differentiation, the specifics become irrelevant. And, since Java bytecode can be converted into a textual representation, it can also be symbolically differentiated by conventional means.

Also, we've left the original topic, which was that Haskell has properties not present in other languages and/or outcomes not possible in other languages.

In a larger sense, wouldn't it be more praiseworthy to say that Haskell does exactly what other languages do, but much better? That time spent programming in Haskell is more productive when measured by bug-free lines of code and concise expressions? Or that, when parallel processing finally arrives in full force, functional programming will not longer be optional?

Re: Don't Be Distracted by Superior Technology

#62

Post by tikhonj »

lutusp wrote: post #60
tikhonj wrote: post #58

Earlier quoted context omitted.

Turing-completeness is a red herring. All it talks about is what a machine can compute, not how . This is an important distinction because libraries can be used for things like meta-programming. It's completely possible to have a Turing-complete method of computation that does not allow the equivalent of self-modification, for example. And then you won't be able to write a library for self-modifying code! You can't r…

> Turing-completeness is a red herring. No, as a matter of fact, it's the point. A Turing-complete system can compute anything that any other Turing-complete system can. > It's completely possible to have a Turing-complete method of computation that does not allow the equivalent of self-modification ... Speaking of red herrings?

It's a red herring because the original claim was not "Haskell can compute function Java cannot" but rather "there are many libraries in Haskell which aren't even possible to write in Java".

The point is that libraries do more than just compute stuff. If all we cared about was what you could compute, there are plenty of interesting libraries that wouldn't count for anything! Any library exporting new types of control flow, for example.

The argument is that there are libraries you can write in Haskell that you can't write in Java. And since libraries can do meta-programming which is possible in Haskell but not in Java, this is accurate. Similarly, since self-modification is something a library can do, possible on one model but not another, it isn't a red-herring.

Hmm, how can I make my point clearer? Let me give you a very specific example then: a library with new syntax sugar would be impossible to write in Java. Sure, this does not allow you to compute anything different, but it's still very important and has a practical effect. Let's take a very trivial library of this sort: a library only providing an "unless" statement like Perl's. Possible in some languages, not possible in others.

Some of the examples in the original post also fall into this category. The lenses library, for example, just allows you to write composable accessors and mutators. It does not compute anything new. But it's still very useful because it makes your code simpler and gives you new ways to express yourself. You could not write anything like it in Java.

Hopefully that cleared things up a bit.

Re: Don't Be Distracted by Superior Technology

#63

Post by lutusp »

lelele wrote: post #52
lutusp wrote: post #50

Earlier quoted context omitted.

Java can produce any result that Haskell can produce. End of story, full stop. All non-broken computer languages are Turing machines. This is not to suggest that someone would want to use Java for anything sufficiently sophisticated, unless one is a masochist, but then, that wasn't your claim. > As far as I'm aware in Java, there's no way to write a function with a signature that says "Take two numeric arguments of a…

> Java can produce any result that Haskell can produce. End of story, full stop. But can average Java programmers produce any result that average Haskell programmers can produce? I'd bet they can't. Haskell programmers are self-selecting: if you can grasp Haskell and be productive in it then you are an elite programmer. Not so if you can grasp Java.

> if you can grasp Haskell and be productive in it then you are an elite programmer.

Somehow I knew this was where it was going.

> Not so if you can grasp Java.

Compared to a cabbage or a turnip? I've been told you can't teach calculus to a horse. Elitism is like an onion ... and feel free to imagine that tedious conversation.

Re: Don't Be Distracted by Superior Technology

#64

Post by lutusp »

tikhonj wrote: post #62
lutusp wrote: post #60

Earlier quoted context omitted.

> Turing-completeness is a red herring. No, as a matter of fact, it's the point. A Turing-complete system can compute anything that any other Turing-complete system can. > It's completely possible to have a Turing-complete method of computation that does not allow the equivalent of self-modification ... Speaking of red herrings?

It's a red herring because the original claim was not "Haskell can compute function Java cannot" but rather "there are many libraries in Haskell which aren't even possible to write in Java". The point is that libraries do more than just compute stuff. If all we cared about was what you could compute, there are plenty of interesting libraries that wouldn't count for anything! Any library exporting new types of control…

> It's a red herring because the original claim was not "Haskell can compute function Java cannot" but rather "there are many libraries in Haskell which aren't even possible to write in Java".

That's false. It's as false as the other claims.

> The argument is that there are libraries you can write in Haskell that you can't write in Java.

Still false.

> Similarly, since self-modification is something a library can do, possible on one model but not another, it isn't a red-herring.

It's a red herring because libraries do not ever self-modify. Not. Ever.

> Hopefully that cleared things up a bit.

Oh, it definitely did.

Re: Don't Be Distracted by Superior Technology

#65

Post by calopetreep »

lutusp wrote: post #61
calopetreep wrote: post #51

Earlier quoted context omitted.

> Java can produce any result that Haskell can produce. End of story, full stop. Yes, I'm not disputing this- I'm fully in agreement that all turing-complete languages can compute all turing-computable computations. I've never been trying to argue against that. I'm sorry if I haven't explained myself clearly enough- let me give it another shot. In Haskell, I can write a function operating on numbers like this: f x =…

> As far as I'm aware, it's not possible to write this code in Java- you can't get the differentiated version of a Java function this way. No. The algorithms for symbolic differentiation are well-known, they aren't unique to Haskell. They happen not to be present in any Java library AFAIK, but that's because no one is sufficiently masochistic to code them there. (long pause ...) Whoops -- I was wrong: https://code.go…

> If the end result is symbolic differentiation (...)

Ah, I see the problem- automatic differentiation is not the same as symbolic differentiation- see wikipedia: http://en.wikipedia.org/wiki/Automatic_differentiation This certainly isn't a moot point :)

> Also, we've left the original topic (...)

No- again, I've been saying the same thing all along. In fact I'm only using Haskell as an example. There are things which cannot be expressed in Haskell, too- for example dependent typed programs as you might find in Agda or Idris.

> In a larger sense, wouldn't it be more praiseworthy to say that Haskell does exactly what other languages do, but much better?

This is a separate conversation entirely. My aim is not to "praise Haskell". I have used Haskell and Java only as examples.

Re: Don't Be Distracted by Superior Technology

#66

Post by tikhonj »

lutusp wrote: post #64
tikhonj wrote: post #62

Earlier quoted context omitted.

It's a red herring because the original claim was not "Haskell can compute function Java cannot" but rather "there are many libraries in Haskell which aren't even possible to write in Java". The point is that libraries do more than just compute stuff. If all we cared about was what you could compute, there are plenty of interesting libraries that wouldn't count for anything! Any library exporting new types of control…

> It's a red herring because the original claim was not "Haskell can compute function Java cannot" but rather "there are many libraries in Haskell which aren't even possible to write in Java". That's false. It's as false as the other claims. > The argument is that there are libraries you can write in Haskell that you can't write in Java. Still false. > Similarly, since self-modification is something a library can do,…

False, is it? I'm quoting the opening comment directly: "There are many libraries in Haskell which aren't even possible to write in Java". So that is the initial argument. It says nothing about computable functions and everything about possible libraries.

Or do you mean the argument itself is false? Well, a library providing new control structures certainly fits that! But yes, it's as false as my other claims--not false at all.

There are Turing-complete languages where you cannot add new control structures. (Or even ones where the concept of "control structure" does not apply.) So a library providing control structures would be impossible. And Haskell has a slew of libraries for control flow: everything in the Control.* namespace.

So both languages are Turing-complete and equally powerful, and yet certain libraries can only be written in one. This only makes sense for self-referential things, where the library somehow affects the language.

As far as self modifying code goes--it's not that the library modifies itself; rather, the library gives you tools for writing self-modifying code. If your language does not have this capability, such a library could not exist. But the language would still be Turing-complete!

The post seems to have cleared up nothing. Ah well, c'est la vie.

Re: Don't Be Distracted by Superior Technology

#67

Post by miga »

coldtea wrote: post #7
miga wrote: post #3

Times change. Interestingly enough, "fringe" languages were breathed new life with introduction of LLVM, and Haskell is no longer research project, so there are industry job offers there too. And we know what happened with "winners" within a wave of dynamic languages: JavaScript, Python and Ruby developers are quite often paid higher wages, than old-style C programmers.

> Haskell is no longer research project, so there are industry job offers there too. Well, there are far fewer Haskell job offers than Haskell programmers. > And we know what happened with "winners" within a wave of dynamic languages: JavaScript, Python and Ruby developers are quite often paid higher wages, than old-style C programmers. Are they? I'm not so sure a competent C programmers earns less than a Javascript/…

An example HN article about that: http://firstround.com/article/The-inside-story-of-how-382-re...

Re: Don't Be Distracted by Superior Technology

#68

Post by miga »

doktrin wrote: post #4
miga wrote: post #3

Times change. Interestingly enough, "fringe" languages were breathed new life with introduction of LLVM, and Haskell is no longer research project, so there are industry job offers there too. And we know what happened with "winners" within a wave of dynamic languages: JavaScript, Python and Ruby developers are quite often paid higher wages, than old-style C programmers.

This is sort of like pointing out the obvious, but that's just a change in the market, and has comparatively little to do with the languages themselves. There's no reason C programmers can't easily transition into web development. The inverse, assuming that the market for C development will remain static is just illogical (likewise for the current in-demand languages). Developers are developers IMHO. Languages are to…

Tool is subject to change, particularly when change looks like an upgrade.
Post reply on HN