View mode: basic / threaded / horizontal-split · Log in · Help
April 10, 2012
Re: The Downfall of Imperative Programming
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
April 10, 2012
Re: The Downfall of Imperative Programming
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
April 10, 2012
Re: The Downfall of Imperative Programming
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
April 10, 2012
Re: The Downfall of Imperative Programming
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
April 11, 2012
Re: The Downfall of Imperative Programming
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
April 11, 2012
Re: The Downfall of Imperative Programming
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.
April 11, 2012
Re: The Downfall of Imperative Programming
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.
April 12, 2012
Re: The Downfall of Imperative Programming
* 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
April 12, 2012
Re: The Downfall of Imperative Programming
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
April 12, 2012
Re: The Downfall of Imperative Programming
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.
1 2 3 4
Top | Discussion index | About this forum | D home