On Tue, 10 Apr 2012 21:02:03 +0100
Russel Winder <russel@winder.org.uk> wrote:

> Hummm... the really core issue is whether the language supports tail call optimization.  Functional programming languages demand it, C, C++, Java, Go, Python definitely don't have it, D...

Isn't it because they have to use recursion instead of iteration?


Sincerely,
Gour


-- 
As the ignorant perform their duties with attachment to results, the learned may similarly act, but without attachment, for the sake of leading people on the right path.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

On 4/10/12 3:02 PM, Russel Winder wrote:
> Hummm... the really core issue is whether the language supports tail
> call optimization.  Functional programming languages demand it, C, C++,
> Java, Go, Python definitely don't have it, D...

D has only the tail recursion, not the tail call. The latter should be easy to implement.

Andrei

On 10-04-2012 23:02, Andrei Alexandrescu wrote:
> On 4/10/12 3:02 PM, Russel Winder wrote:
>> Hummm... the really core issue is whether the language supports tail
>> call optimization. Functional programming languages demand it, C, C++,
>> Java, Go, Python definitely don't have it, D...
>
> D has only the tail recursion, not the tail call. The latter should be
> easy to implement.
>
> Andrei

One thing I think we need to do with D is actually guarantee tail calls in the situations where it makes sense. A mistake many other languages made is saying that "this may or may not be a tail call depending on the implementation". This is not enough of a guarantee to write portable programs...

-- 
- Alex

Russel Winder:

> On the JVM the interesting question is whether Clojure finally makes Lisp a mainstream language outside of one or two domains.

Clojure contains some interesting programming language design ideas.
I have written enough Scheme that now I am sure I don't like to write S-expressions. S-expressions are a puzzle-way to write expressions, and I'd like to avoid solving micro-puzzles all the time.
I've seen that idiomatic Clojure code is too much slow for my purposes (there are ways to speed up Clojure code, but only partially and the result doesn't look good). Regarding parallelism in Clojure, I am seeing single-core C/D code faster than idiomatic Clojure running on 4 or 8 cores. I have not done enough experiments, so those are just anecdotes.

Bye,
bearophile

On 11.04.2012 1:04, Alex Rønne Petersen wrote:
> On 10-04-2012 23:02, Andrei Alexandrescu wrote:
>> On 4/10/12 3:02 PM, Russel Winder wrote:
>>> Hummm... the really core issue is whether the language supports tail
>>> call optimization. Functional programming languages demand it, C, C++,
>>> Java, Go, Python definitely don't have it, D...
>>
>> D has only the tail recursion, not the tail call. The latter should be
>> easy to implement.
>>
>> Andrei
>
> One thing I think we need to do with D is actually guarantee tail calls
> in the situations where it makes sense. A mistake many other languages
> made is saying that "this may or may not be a tail call depending on the
> implementation". This is not enough of a guarantee to write portable
> programs...
>

+1 Let me correct your last statement:
"it may overflow stack or not depending on the implementation"

-- 
Dmitry Olshansky

On Tuesday, 10 April 2012 at 17:19:00 UTC, Russel Winder wrote:
> I am a fan of declarative expression, I prefer functional approaches
> over explicitly imperative ones.  For the moment though using single
> assignment in imperative languages with all the lambda/closure
> technology and using functional programming thinking is the best
> compromise.

Imperative languages only emulate functional style to some extent. They remain inherently imperative and impure. And for declarative syntax to really fly you need an FP language, purity and immutability for sure.

The Haskell version of Romans, rubies and D:

Modified version of http://www.haskell.org/haskellwiki/Roman_numerals so that it's compile time.


---------------->8---------------->8----------------
module Romans where

import Language.Haskell.TH
import Maybe


roman :: String -> ExpQ
roman s = return $ LitE (IntegerL (value s))
  where value = fromIntegral . fst
                . foldr (\p (t,s) -> if p >= s then (t+p,p) else (t-p,p)) (0,0)
                . map (fromJust . flip lookup (zip "IVXLCDM"
[1,5,10,50,100,500,1000]))
----------------8<----------------8<----------------


And actual usage:

---------------->8---------------->8----------------
{-# LANGUAGE TemplateHaskell #-}

import Romans

main = print $(roman "VIX")
----------------8<----------------8<----------------


I still like the D version though.

* Russel Winder <russel@winder.org.uk> [2012-04-10 21:02:03 +0100]:

> On Tue, 2012-04-10 at 21:22 +0200, Gour wrote:
> [...]
> > In any case, as it is often said, I got a feeling that despite its potential cleanliness, the real-world Haskell code was not so readable.
> 
> That probably comes down to familiarity and personal taste.
> 
> > By deploying some coding discipline, we tend to believe that D can serve well as FP-language for the masses. :-)
> 
> Hummm... the really core issue is whether the language supports tail call optimization.  Functional programming languages demand it, C, C++, Java, Go, Python definitely don't have it, D...
> 

I used Haskell a bit a while back, and while I enjoyed using it, and was quite capable of writing in proper functional style, I found reasoning about the programs tedious and difficult. Due to the nature of "Everything is a function" (mostly), you end up with an incredible amount of functions for the simplest tasks. And some of the most common tasks in real-world programming, string processing and IO, are significantly more difficult in Haskell.

Monads aren't a problem, the discussion of monads, by functional programmers is a problem. The moment some snobby functional programmer comes along and starts talking about category theory and some esoteric aspect of Type Algebra generalized of some field of Assholery, most people's brains turn off. It gets worse when you go: "How does this help read from a file" and they give you a long stare and start all over again, I just want to know how to read from a goddamn file!

I wish I could love Haskell, and for pure computer science, it's fine, amazing even, but for real-world programming, it just doesn't cut it. The concepts are too difficult and not explained well enough, code rapidly becomes unreadable unless you maintain super-human discipline and broken code is difficult to fix. Case in point is darcs, which is a perfect application of real-word usage, and the GHC developers are complaining of it being unstable, bloated and impossible to fix, so they are moving to git (written in C no less).

--
James Miller

James Miller:

> I wish I could love Haskell, and for pure computer science, it's fine, amazing even, but for real-world programming,
> it just doesn't cut it.

Haskell contains some ideas worth copying even in non-functional languages (or in mixed languages as D).

Enforced purity and immutability, lazy immutable lists, pattern matching, tuples and their various unpacking syntax, list comprehension, structural algebraic types, built-in currying and partial application, and so on, are handy and allow to express certain computing idioms in a succinct and clear way (and not every part of a program needs the same runtime efficiency). Scala language shows that you can put several of those things in a language that supports mutability too.

Bye,
bearophile

On 04/10/2012 12:06 PM, Paulo Pinto wrote:
>
> A curious fact is that the FP fans have much to thank to Microsoft, as
> it is the company with more FP research on their paychecks. Many open
> source fans are not aware that a few of the main developers in the Ocaml
> and Haskell communities, work for Microsoft Research labs.

I don't see any reason to thank Microsoft for this so much as to be wary of it. The same people that were getting paid to work on this stuff at universities in Europe, where software patents don't exist, are now getting paid to work at Microsoft, where patenting software is expected as part of the job.

Microsoft has also in recent years been very aggressive with their patent portfolio, rattling their saber at Linux and suing Android distributors.