On Tue, 10 Apr 2012 18:06:37 +0200
Paulo Pinto <pjmlp@progtools.org> wrote:

> Scala, Clojure and Ocaml also do have quite industry support already.

How does the GUI world of Ocaml look like?


Sincerely,
Gour

-- 
According to the three modes of material nature and the work associated with them, the four divisions of human society are created by Me. And although I am the creator of this system, you should know that I am yet the nondoer, being unchangeable.

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

On Tuesday, 10 April 2012 at 16:30:34 UTC, Gour wrote:
> On Tue, 10 Apr 2012 18:06:37 +0200
> Paulo Pinto <pjmlp@progtools.org> wrote:
>
>> Scala, Clojure and Ocaml also do have quite industry support already.
>
> How does the GUI world of Ocaml look like?
>
>
> Sincerely,
> Gour

GTK

Two quite interesting points to make here:

1.  OCaml has a GIL and so, like CPython (*), is forced to use operating system processes to obtain parallelism. Also OCaml has imperative features, it is not a pure functional language.  Clojure followed this route as well, using STM to deal with locking issues.

2. Haskell is a lazy language which means:
	a. it can work with infinite data structures; and
	b. it is incredibly difficult to create parallel codes.

Simon Peyton Jones and Simon Marlow have had to do a great deal of very clever work to make Data Parallel Haskell, but it is to Haskell what NumPy is to Python.

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.  OCaml (and its clone F#) and Haskell are likely to remain tiny bit part players for a long while.

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


(*) PyPy is experimenting with STM to replace use of a GIL.
-- 
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, 10 Apr 2012 19:01:07 +0200
"bls" <bls@orange.fr> wrote:

> GTK

Then, D is better even in that regard. ;)


Sincerely,
Gour


-- 
Whenever and wherever there is a decline in religious practice, O descendant of Bharata, and a predominant rise of irreligion — at that time I descend Myself.

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

Microsoft is taking a careful approach with F# in what concerns GUIs.

Actually they are promoting C# or VB.NET code for the GUI part, while
leaving all the business code for F#.

This approach seems to cater more for the business audience, as to
have the GUI also written in F#.

--
Paulo

On Tuesday, 10 April 2012 at 17:42:24 UTC, Gour wrote:
> On Tue, 10 Apr 2012 19:01:07 +0200
> "bls" <bls@orange.fr> wrote:
>
>> GTK
>
> Then, D is better even in that regard. ;)
>
>
> Sincerely,
> Gour

My favourite FP language is Haskell, but I doubt most "code
monkeys"
will ever be able to grasp it, while impure ones are more
approachable
in enterprise environments.

The issues you point out are actually more implementation
issues than language related, right?

--
Paulo

On Tuesday, 10 April 2012 at 17:19:00 UTC, Russel Winder wrote:
> Two quite interesting points to make here:
>
> 1.  OCaml has a GIL and so, like CPython (*), is forced to use operating
> system processes to obtain parallelism. Also OCaml has imperative
> features, it is not a pure functional language.  Clojure followed this
> route as well, using STM to deal with locking issues.
>
> 2. Haskell is a lazy language which means:
> 	a. it can work with infinite data structures; and
> 	b. it is incredibly difficult to create parallel codes.
>
> Simon Peyton Jones and Simon Marlow have had to do a great deal of very
> clever work to make Data Parallel Haskell, but it is to Haskell what
> NumPy is to Python.
>
> 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.  OCaml (and its clone F#) and Haskell are likely to remain
> tiny bit part players for a long while.
>
> On the JVM the interesting question is whether Clojure finally makes
> Lisp a mainstream language outside of one or two domains.
>
>
> (*) PyPy is experimenting with STM to replace use of a GIL.

On Tue, 10 Apr 2012 20:19:13 +0200
"Paulo Pinto" <pjmlp@progtools.org> wrote:

> My favourite FP language is Haskell, but I doubt most "code monkeys" will ever be able to grasp it, while impure ones are more approachable in enterprise environments.

That's right...I tried with Haskell, liked its syntax a lot, but was not sure I really grokked monads. Moreover, I lost few potential contributors because of insisting on Haskell.

Now, I hope to get some of the FP features by using Haskell and have easier time not to think about unsafePerformIO & co. :-)


Sincerely,
Gour


-- 
The senses, the mind and the intelligence are the sitting places of this lust. Through them lust covers the real knowledge of the living entity and bewilders him.

On Tue, 2012-04-10 at 20:46 +0200, Gour wrote:
[...]
> That's right...I tried with Haskell, liked its syntax a lot, but was not sure I really grokked monads. Moreover, I lost few potential
[...]

The biggest problems with monads are that most imperative programmers think they are some massive high magic that is incomprehensible to mere mortals, and  most functional programmers think they are simple and that they understand them.

Monads are just things with a couple of methods of certain signatures and that have behaviour not unrelated to continuations.  If you get higher order functions, currying and partial evaluation, then monads come naturally (*).

(*) But only once they were initially thought of as programming entities rather than some aspect of Category Theory.

-- 
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, 10 Apr 2012 20:13:45 +0100
Russel Winder <russel@winder.org.uk> wrote:

> The biggest problems with monads are that most imperative programmers think they are some massive high magic that is incomprehensible to mere mortals, and  most functional programmers think they are simple and that they understand them.

Indeed.

> If you get higher order functions, currying and partial evaluation,
> then monads come naturally (*).

I believe I got HoFs, currying & partial evolution, but maybe I was
missing (*)

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.

By deploying some coding discipline, we tend to believe that D can serve well as FP-language for the masses. :-)


Sincerely,
Gour

-- 
When your intelligence has passed out of the dense forest of delusion, you shall become indifferent to all that has been heard and all that is to be heard.

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

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...

-- 
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