On 12/27/2012 12:53 AM, Andrei Alexandrescu wrote:
> On 12/26/12 6:13 PM, Timon Gehr wrote:
>>> But D also does something I think is fairly unique. A function can be
>>> pure, but inside that function, mutation is allowed as long as that
>>> mutation does not "leak" outside of the function. A pure function with
>>> immutable parameters does completely specify the function in its
>>> signature. What happens inside the function is not relevant, it is not
>>> necessary that locals be immutable.
>>>
>>
>> Haskell has this.
>
> This would necessitate a bit of qualification :o).
>
> Andrei

http://www.haskell.org/haskellwiki/Monad/ST

On 2012-11-26 00:12, Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/25/2012 11:57 AM, Jakob Bornecrantz wrote:
>> On Tuesday, 25 December 2012 at 19:37:42 UTC, Walter Bright wrote:
>>> Note that D offers this style of programming, with checkable purity,
>>> immutability and ranges. I think it is a very important paradigm.
>> I think you missed a big part here, the by default of purity. It is in D more
>> work to enforce purity of functions then not.
>
> I think optional purity is pretty powerful. You can have the advantages of either, at your choice.

Absolutely. But whether purity should be the default or not is orthogonal
to this.

I would have preferred opt-out purity to opt-in, but it's not exactly
make or break.

-- 
Simen

On 12/26/12 7:11 PM, Timon Gehr wrote:
> On 12/27/2012 12:53 AM, Andrei Alexandrescu wrote:
>> On 12/26/12 6:13 PM, Timon Gehr wrote:
>>>> But D also does something I think is fairly unique. A function can be
>>>> pure, but inside that function, mutation is allowed as long as that
>>>> mutation does not "leak" outside of the function. A pure function with
>>>> immutable parameters does completely specify the function in its
>>>> signature. What happens inside the function is not relevant, it is not
>>>> necessary that locals be immutable.
>>>>
>>>
>>> Haskell has this.
>>
>> This would necessitate a bit of qualification :o).
>>
>> Andrei
>
> http://www.haskell.org/haskellwiki/Monad/ST

That's not the same!

Andrei

Simen Kjaeraas:

> Absolutely. But whether purity should be the default or not is orthogonal to this.
>
> I would have preferred opt-out purity to opt-in, but it's not exactly make or break.

The colourful Erik Meijer says that specifying what functions are not pure is better than specifying what functions are pure:

http://www.youtube.com/watch?v=z0N1aZ6SnBk#t=54m53s

Bye,
bearophile

On Thursday, 27 December 2012 at 00:56:02 UTC, Andrei Alexandrescu wrote:
> On 12/26/12 7:11 PM, Timon Gehr wrote:
>> On 12/27/2012 12:53 AM, Andrei Alexandrescu wrote:
>>> On 12/26/12 6:13 PM, Timon Gehr wrote:
>>>>> But D also does something I think is fairly unique. A function can be
>>>>> pure, but inside that function, mutation is allowed as long as that
>>>>> mutation does not "leak" outside of the function. A pure function with
>>>>> immutable parameters does completely specify the function in its
>>>>> signature. What happens inside the function is not relevant, it is not
>>>>> necessary that locals be immutable.
>>>>>
>>>>
>>>> Haskell has this.
>>>
>>> This would necessitate a bit of qualification :o).
>>>
>>> Andrei
>>
>> http://www.haskell.org/haskellwiki/Monad/ST
>
> That's not the same!
>
> Andrei

It is isolated state mutation inside a pure function, which is what Walter emphasized on.

On 12/26/12 8:43 PM, Timon Gehr wrote:
> It is isolated state mutation inside a pure function, which is what
> Walter emphasized on.

Point taken, but claiming it's the same thing is a bit of a stretch.

Andrei

On Thursday, December 27, 2012 02:22:44 bearophile wrote:
> Simen Kjaeraas:
> > Absolutely. But whether purity should be the default or not is orthogonal to this.
> > 
> > I would have preferred opt-out purity to opt-in, but it's not exactly make or break.
> 
> The colourful Erik Meijer says that specifying what functions are not pure is better than specifying what functions are pure:
> 
> http://www.youtube.com/watch?v=z0N1aZ6SnBk#t=54m53s

It probably would be better for stuff like @safe and pure to be the default, but it's far too late for that now, regardless of how good an idea it would have been. Live and learn.

- Jonathan M Davis

On Wed, 2012-12-26 at 22:48 +0100, bearophile wrote:
> Russel Winder:
> 
> > Clojure could make Lisp a mainstream language,
> 
> Many things I read in blogs and Reddit about Clojure are wrong, or nearly wrong.

Reddit appears to be full of bluster, bullshit and rubbish which is why
it is entirely ignorable.

Practical experience, i.e. actually using it for real on real projects,
indicates that Clojure is an excellent language and very usable.
Moreover many people (*) building systems are actually working with
Clojure and finding it a huge boon. Also Uncle Bob tells us it is the
final programming language ;-)

The JVM language set is definitely now Java, Scala, Groovy, Clojure.


(*) OK mostly young entrepreneurial types doing start-ups.
-- 
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

Russel Winder:

> Practical experience, i.e. actually using it for real on real
> projects, indicates that Clojure is an excellent language and
> very usable.

In my very limited Clojure experience I've seen that it uses a LOT of memory even for my small programs, sometimes almost ten times more than equivalent Python programs (like 120 MB for a small program that processes small genomic text files). And I've seen to write fast Clojure programs I have to add a ton of annotations to the code. So I have not used it further.

Bye,
bearophile

On Thursday, 27 December 2012 at 11:45:45 UTC, Russel Winder wrote:
> On Wed, 2012-12-26 at 22:48 +0100, bearophile wrote:
>> Russel Winder:
> Practical experience, i.e. actually using it for real on real projects,
> indicates that Clojure is an excellent language and very usable.
> Moreover many people (*) building systems are actually working with
> Clojure and finding it a huge boon. Also Uncle Bob tells us it is the
> final programming language ;-)
>
> The JVM language set is definitely now Java, Scala, Groovy, Clojure.
>
>
> (*) OK mostly young entrepreneurial types doing start-ups.

It all depends on who you are catering for and what you are developing. If you have to develop cross-platform applications with (possibly) graphical user interfaces any Java based technology (ironically enough!) can quickly turn into a nightmare. There's always at least one serious pitfall and I have learned that you cannot pass the burden of dealing with things like JVMs on to the user. Also, over the years I have taken a dislike to "ideological" languages that dictate a certain paradigm or coding style (Python). What attracted me to D was the lack of "ideology" (multi-paradigm) and its natively-compiled cross-platform approach with easy C/C++-integration. Before I discovered D I was at a loss trying to find a modern language (= concise and productive) that would work natively on different platforms, because I am working in a small team and "write once run everywhere" is really important. All other features like pure and safe programming, unit tests, contract programming etc. are nice and helpful (_optional_) features but were not a top priority. From my point of view the only really important issue is concurrency programming, multithreading and everything related to it.

One of the biggest strengths of D is the philosophy "Well, you needn't...but you can of course"