Fwd: [Haskell-cafe] Haskell as a religion
But many features need other features. For example, the option to use
referential transparency will be common in future languages for multicore
programming purposes. This creates the problem of separating
side-effect-free code from side-effect code. For this purpose, a strong type
system at compile time is needed, which indeed need automatic type inference
or, else, the user will be too busy with the details. The type inference
open the door for experimenting with complex data types. class types is a
logical step after that. Monads are the best option for many problems once
the programmer have all te above. higuer order functions are being taken
seriously in other languages. this goes to the need of currying and lists.
optional lazyness and tail recursion is the most elegant option for
expressing lists managing code. Will all the above, explicit loops will be
avoided by the programmer, this will end up in mode declarative programming
style.
I think that once the average programmer start to use one or two of these
features, he will feel a bit frustrated if its language don´t have all the
others, specially if he know haskell. Probably, he will use haskell for fun.
This is the best way for the takeover of the industry, because this has been
so historically.
2008/12/18 John Goerzen
Don Stewart wrote:
I think of Haskell more as a revolutionary movement
LOL! Longest revolution EVER, eh? I mean, how long ago was its dogma first codified? ;-)
Lisp has been around for how long now? Measured in decades. We don't even have our version of a Symbolics machine yet!
Basically, Haskell will never be popular, but its coolest ideas will be stolen by everybody else and passed off as their own. :-(
Well, in a sense, if that happens, we would have won, right? We'd have created a situation where "paradigm shift" would mean more than just a buzzword on some CEO's presentation slide ;-)
In another sense, isn't this what Haskell was explicitly created to do? (Combine ideas from a bunch of similar languages into one standard one)
Some ideas in Haskell are easy to integrate into other languages: see list comprehensions in Python. I don't see Perl picking up pervasive laziness anytime soon, nor Python compile-time type inference.
-- John _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Alberto G. Corona schrieb:
But many features need other features. For example, the option to use referential transparency will be common in future languages for multicore programming purposes. This creates the problem of separating side-effect-free code from side-effect code.
In C/C++ referential transparent functions code can be declared by appending a 'const' to the prototype, right?
I think that once the average programmer start to use one or two of these features, he will feel a bit frustrated if its language don´t have all the others, specially if he know haskell. Probably, he will use haskell for fun. This is the best way for the takeover of the industry, because this has been so historically.
Extrapolating the habit of programmers from the past to the future, I predict that Haskell can only become a mainstream language once there is a cleaner, simpler, safer and more powerful programming language than Haskell.
On Thu, Dec 18, 2008 at 4:15 PM, Henning Thielemann
Extrapolating the habit of programmers from the past to the future, I predict that Haskell can only become a mainstream language once there is a cleaner, simpler, safer and more powerful programming language than Haskell.
And so, finally, we find the fatal flaw in trying to create the ultimate programming language. --Max
Henning Thielemann wrote:
Alberto G. Corona schrieb:
But many features need other features. For example, the option to use referential transparency will be common in future languages for multicore programming purposes. This creates the problem of separating side-effect-free code from side-effect code.
In C/C++ referential transparent functions code can be declared by appending a 'const' to the prototype, right?
not quite. GCC allows __attribute__((__const__)) or __attribute__((__pure__)), to declare that, though (one of them allows reading global variables, the other doesn't, I forget which). In C and C++ per standard, "const" can only be applied to types, e.g. function arguments (including C++'s implicit *this, via funny location of "const"). Maybe C99 made up an additional way to use it, as it introduced "restrict", I forget -Isaac
On Thu, Dec 18, 2008 at 4:15 PM, Henning Thielemann
In C/C++ referential transparent functions code can be declared by appending a 'const' to the prototype, right?
For one thing, some fields in a const C++ object can be explicitly set mutable. mutable is sometimes used in C++ a similar way to unsafePerformIO in Haskell. You have something that uses mutability in its internals but that mutability shouldn't be observable to the caller. In both cases you have no means of actually ensuring that the mutability is actually unobservable. -- Dan
Henning Thielemann
In C/C++ referential transparent functions code can be declared by appending a 'const' to the prototype, right?
No. $ cat x.cc int f() const; int f() { return 3; } $ gcc x.cc x.cc:1: error: non-member function ???int f()??? cannot have cv-qualifier You can define a const member function, but it can call rand() just fine. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig If you want to go somewhere, goto is the best way to get there. Ken Thompson.
participants (6)
-
Alberto G. Corona -
Chung-chieh Shan -
Dan Piponi -
Henning Thielemann -
Isaac Dupree -
Max Rabkin