On Tuesday, 25 December 2012 at 20:50:35 UTC, SomeDude wrote:
> I've seen some Python code using heavily map/filter/etc that was simply unreadable to me.



I've written Python code like that, which was also unreadable to me. 8-)

On 26 December 2012 00:54, Ali Çehreli <acehreli@yahoo.com> wrote:

> On 12/25/2012 11:37 AM, Walter Bright wrote:
>
> > http://dubhrosa.blogspot.co.**uk/2012/12/lessons-learning-**
> haskell.html?m=1<http://dubhrosa.blogspot.co.uk/2012/12/lessons-learning-haskell.html?m=1>
>
> I think I am being a troll but that page is dark white on white!
>
> Ali
>
>
It's called grey.  Or gray if you speak american. :o)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Tuesday, 25 December 2012 at 19:37:42 UTC, Walter Bright wrote:
> I've often heard that claim, but here's an article with what the substance is:
>
> http://dubhrosa.blogspot.co.uk/2012/12/lessons-learning-haskell.html?m=1
>
> Note that D offers this style of programming, with checkable purity, immutability and ranges. I think it is a very important paradigm.

Bleah, one good practice that I like to follow is to (optionaly) log what my functions do, so it doesn't match well with "IO change the type of your function"..

On Tue, 2012-12-25 at 11:37 -0800, Walter Bright wrote:
> I've often heard that claim, but here's an article with what the substance is:
> 
> http://dubhrosa.blogspot.co.uk/2012/12/lessons-learning-haskell.html?m=1
> 
> Note that D offers this style of programming, with checkable purity, immutability and ranges. I think it is a very important paradigm.

Does D do tail recursion optimisation?

Can the D compiler check to enforce *NO* (or at the worst single)
assignment to a variable?

I am guessing that the D compilers can enforce referential transparency and zero side-effects.

Functional programming is a good influence, but in it's Haskell form is liable a minority language. Clojure could make Lisp a mainstream language, but.. In the end the move to declarative expression and internal rather than external iteration is a move all languages are taking: C++, Python, D, Go, Java,..
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wed, 2012-12-26 at 01:45 +0100, so wrote:
[…]
> IMO, learning programming language X doesn't make you a better programmer. Learning X make you better X programmer. But if your existing environment/language is extremely flexible, takes code generation *very* seriously, you have a case. You gain something from learning a new feature or a paradigm. That is why lisp fascinates me, as i believe code generation is one of the most important (if not the most important) thing in a PL.

The experimental evidence from psychology of programming research is exactly that the more distinct computational models that a programmer is able to use reasonably well then the better programmer the person is in any specific programming language.

Groovy has abstract syntax transforms, Scala has followed Lisp and introduced macros – not to be confused with the C pre-processor things of similar name.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, 2012-12-25 at 21:50 +0100, SomeDude wrote:
[…]
> 
> As for being a better programmer after having used some advanced concepts, I don't know. I think every feature of a language must be used where appropriate. I've seen some Python code using heavily map/filter/etc that was simply unreadable to me. In some places, I find  it easier to understand for loops, while in other cases, using functional style programming conveys the intent better. But maybe that's just me.

Code using map/filter/reduce requires a specific reading strategy, which is fine for people coming from Lisp/Clojure/Haskell/OCaml/Groovy/Ruby but difficult for people coming from C, assembly language, Java, etc. C ++ and D are treading a middle ground.

BDFL has stated that list/dictionary/set comprehensions are to be preferred over functional chaining constructs. In general this is good advice, even for languages other than Python.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 12/26/12 9:11 AM, renoX wrote:
> On Tuesday, 25 December 2012 at 19:37:42 UTC, Walter Bright wrote:
>> I've often heard that claim, but here's an article with what the
>> substance is:
>>
>> http://dubhrosa.blogspot.co.uk/2012/12/lessons-learning-haskell.html?m=1
>>
>> Note that D offers this style of programming, with checkable purity,
>> immutability and ranges. I think it is a very important paradigm.
>
> Bleah, one good practice that I like to follow is to (optionaly) log
> what my functions do, so it doesn't match well with "IO change the type
> of your function"..

debug statements to the rescue!

Andrei

On 12/26/12 9:42 AM, Russel Winder wrote:
> On Tue, 2012-12-25 at 11:37 -0800, Walter Bright wrote:
>> I've often heard that claim, but here's an article with what the substance is:
>>
>> http://dubhrosa.blogspot.co.uk/2012/12/lessons-learning-haskell.html?m=1
>>
>> Note that D offers this style of programming, with checkable purity,
>> immutability and ranges. I think it is a very important paradigm.
>
> Does D do tail recursion optimisation?

Yah, but not tail calls. (That should be on the list...)

> Can the D compiler check to enforce *NO* (or at the worst single)
> assignment to a variable?

Only for immutable data.


Andrei

On Wednesday, 26 December 2012 at 16:01:27 UTC, Andrei Alexandrescu wrote:
> On 12/26/12 9:11 AM, renoX wrote:
>> On Tuesday, 25 December 2012 at 19:37:42 UTC, Walter Bright wrote:
>>> I've often heard that claim, but here's an article with what the
>>> substance is:
>>>
>>> http://dubhrosa.blogspot.co.uk/2012/12/lessons-learning-haskell.html?m=1
>>>
>>> Note that D offers this style of programming, with checkable purity,
>>> immutability and ranges. I think it is a very important paradigm.
>>
>> Bleah, one good practice that I like to follow is to (optionaly) log
>> what my functions do, so it doesn't match well with "IO change the type
>> of your function"..
>
> debug statements to the rescue!
>
> Andrei

Yes of course, but what I was objecting is the article's take that IO should change the type of the function: that's an oversimplification..
This is not true for debug/logging statements.

renoX

On Wed, 2012-12-26 at 11:03 -0500, Andrei Alexandrescu wrote:
> On 12/26/12 9:42 AM, Russel Winder wrote:
[…]
> > Does D do tail recursion optimisation?
> 
> Yah, but not tail calls. (That should be on the list...)

I'll have to admit confusion from the above statement: tail calls are a programmer technique, tail call optimization is a compiler / run time technique.  If a programmer uses tail calls and the compiler realizes tail call optimization then the result is equivalent to iteration.

> > Can the D compiler check to enforce *NO* (or at the worst single)
> > assignment to a variable?
> 
> Only for immutable data.

But isn't that the whole point, in functional programming there is only immutable data.  Thus a programming language that allows mutable data cannot really be said to be usable for functional programming style.

On the other hand it is 2012-12-26T16:32 and nearly time for fireworks, and drinkies. Hopefully everyone is having a peaceful and happy Solstice/Xmas/New Year/Hogmanay/<insert your personal choice of excuse for celebration>.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder