Wow Monads!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

David McClain
Around that time, I only first heard about commercial Lisp systems from Franz (VAX), HP (their own minicomputers), and Symbolics. It was around 1988 when I first saw a Lisp Machine, at a defense contractor (SAIC), after they showed me how defense spending under Pres. Reagan was in the exponential knee of increase. But the fad seemed to be hugely focused on VAX/VMS, not Lisp.

Over in the commercial realm, the fad seemed to be with TRS-80, Atari, Mac (?), definitely IBM/PC’s, Pascal, then Object Pascal. Even C wasn’t getting much traction, and C++ was just a gleam in the envious C community’s eyes - largely a preprocessor of some sort. Smalltalk was a fascinating curiosity, and only tinkerers were playing with it.

- DM


On Apr 19, 2017, at 05:56, David McClain <[hidden email]> wrote:


On Apr 19, 2017, at 05:42, Joachim Durchholz <[hidden email]> wrote:

Yeah, I was assuming that macros are global.
It's very old Lisp experience from the days when Common Lisp and Scheme were new fads, when Lisp machines were still a thing, and had to be rebooted on a daily basis to keep them running.

Was Lisp ever a fad? I’m shocked to hear that. Seriously!

I only got into Lisp after several years of mild nagging by one of my former employees, who studied Lisp and Proof Systems for his graduate CS Degree from U.Oregon, sometime back in the early 80’s, late 70’s. Turns out everything he said was true, and more.

- DM
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

Sergiu Ivanov-2
In reply to this post by Joachim Durchholz

Thus quoth  Joachim Durchholz  at 07:51 on Wed, Apr 19 2017:
> Am 18.04.2017 um 23:33 schrieb Sergiu Ivanov:
>
>> Haskell or OCaml type systems are usually not used for writing such
>> exact specifications, because they are not expressive enough.
>
> I have read statements that Haskell code still tends to "just work as
> expected and intended", and see that attributed to the type system.
[...]
> So the sentiment was that it's not the same but close enough to be the
> same in practice.

Sure, this "close enough" bit is one of the things which make Haskell
very attractive.

Now, it's not "close enough" for critical systems (satellites, nuclear
reactors, etc.), from what I know.

> Seemed to be related to Haskells expressivity, with the type system
> pretty much preventing the typical errors that people make.

I tend to see Haskell's type system as very restrictive and only
allowing behaviour which composes well.  It's also rich enough to allow
specification of quite a wide variety of behaviour.

However, there are a couple big "backdoors", like the IO monad.
Typechecking gives zero guarantees for functions of type IO (), for
example.

> Though I doubt that that will hold up once you get more proficient in
> Haskell and start tackling really complicated things

To me, it really depends on the kind of complicated things.  If you
manage to explain the thing at the type level, then typechecking may
give you pretty strong guarantees.  I'm thinking of parsing and
concurrency as positive examples and exception handling as a somewhat
negative example.

> but "simple stuff in Haskell" tends to get you farther than anybody
> would expect, so it's still a net win.

Absolutely.

>> Thus, in general, showing that Haskell or OCaml code typechecks is
>> weaker than proving that it has a certain property (like not
>> failing).
>
> That a code type checks in Haskell still gives you a whole lot of
> guarantees. Such as "it doesn't have IO in the type signature so there
> cannot be any side effect deep inside".

Right, of course.

> (Ironically, people instantly started investigating ways to work around
> that. Still, the sort-of globals you can introduce via the State monad
> are still better-controlled than the globals in any other language.)

In fact, I believe having pure functions does not so much target
removing state as it does making the state _explicit_.  Thus, the State
monad is not a work-around to purity, it's a way of purely describing
state.

And then, if the State monad is too lax for one's purposes, one can use
Applicative or even define more specific typeclasses.

> (Aside note: I don't know enough about OCaml to talk about its
> properties, but I do believe that they are much weaker than in Haskell.)

That's what I tend to believe as well from looking over people's
shoulders.

>>> And I think you can trace that to the need to interface with the real
>>> world.
>>
>> I have the same gut feeling.
>
> I think interfacing with the outside world (still not "real" but just
> bits inside the operating system and on disk) is one major source of
> unreliability, but not the only one, and not necessarily the primary one.
> YMMV.

Yes, that unreliability comes with crossing the frontier between
theoretical and applied computer sciences (that's an imprecise
metaphor :-) )

--
Sergiu

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

David McClain
In reply to this post by David McClain
Ah Yes… I do now remember the “Race for the 5th Generation”, us against Japan. Lisp against Prolog. That was a fad? Maybe in academic circles and the deep bowels of a handful of defense contractors. Meanwhile the rest of us were busily attaching chains of AP Array Processors on the back of VAX machines. Fortran still ruled the day. Nicholas Wirth had just invented Modula-2 to replace Pascal, as bleeding edge compiler technology. Wow, what memories you sparked...

- DM

On Apr 19, 2017, at 06:08, David McClain <[hidden email]> wrote:

Around that time, I only first heard about commercial Lisp systems from Franz (VAX), HP (their own minicomputers), and Symbolics. It was around 1988 when I first saw a Lisp Machine, at a defense contractor (SAIC), after they showed me how defense spending under Pres. Reagan was in the exponential knee of increase. But the fad seemed to be hugely focused on VAX/VMS, not Lisp.

Over in the commercial realm, the fad seemed to be with TRS-80, Atari, Mac (?), definitely IBM/PC’s, Pascal, then Object Pascal. Even C wasn’t getting much traction, and C++ was just a gleam in the envious C community’s eyes - largely a preprocessor of some sort. Smalltalk was a fascinating curiosity, and only tinkerers were playing with it.

- DM


On Apr 19, 2017, at 05:56, David McClain <[hidden email]> wrote:


On Apr 19, 2017, at 05:42, Joachim Durchholz <[hidden email]> wrote:

Yeah, I was assuming that macros are global.
It's very old Lisp experience from the days when Common Lisp and Scheme were new fads, when Lisp machines were still a thing, and had to be rebooted on a daily basis to keep them running.

Was Lisp ever a fad? I’m shocked to hear that. Seriously!

I only got into Lisp after several years of mild nagging by one of my former employees, who studied Lisp and Proof Systems for his graduate CS Degree from U.Oregon, sometime back in the early 80’s, late 70’s. Turns out everything he said was true, and more.

- DM
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

Joachim Durchholz
In reply to this post by David McClain
Am 19.04.2017 um 14:56 schrieb David McClain:

>
>> On Apr 19, 2017, at 05:42, Joachim Durchholz <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Yeah, I was assuming that macros are global.
>> It's very old Lisp experience from the days when Common Lisp and
>> Scheme were new fads, when Lisp machines were still a thing, and had
>> to be rebooted on a daily basis to keep them running.
>
> Was Lisp ever a fad? I’m shocked to hear that. Seriously!

Common Lisp and Scheme were, in their first years.
They both managed to transition from "fad" to "production-ready" AFAICT,
probably after a stabilization period (I dimly recall having read
versioned standardization documents).

Lisp as such... probably. Whenever people with enough raw horsepower to
use Lisp in practice met people who didn't, because then it would be a
fad from the latter ones. Which pretty much meant everybody who didn't
have access to abundant corporate-sponsored or state-sponsored hardware.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

Joachim Durchholz
In reply to this post by Sergiu Ivanov-2
Am 19.04.2017 um 15:13 schrieb Sergiu Ivanov:
>
>> Seemed to be related to Haskells expressivity, with the type system
>> pretty much preventing the typical errors that people make.
>
> I tend to see Haskell's type system as very restrictive and only
> allowing behaviour which composes well.

 From a library writer's and library user's perspective, that would
actually be a Good Thing.

> However, there are a couple big "backdoors", like the IO monad.

Well, it's so awkward that people don't *want* to use it.

> Typechecking gives zero guarantees for functions of type IO (), for
> example.

That doesn't match what I hear from elsewhere.
I don't know what is the cause for that difference though.

>> Though I doubt that that will hold up once you get more proficient in
>> Haskell and start tackling really complicated things
>
> To me, it really depends on the kind of complicated things.  If you
> manage to explain the thing at the type level, then typechecking may
> give you pretty strong guarantees.  I'm thinking of parsing and
> concurrency as positive examples and exception handling as a somewhat
> negative example.

That matches what I heard :-)

>> (Ironically, people instantly started investigating ways to work around
>> that. Still, the sort-of globals you can introduce via the State monad
>> are still better-controlled than the globals in any other language.)
>
> In fact, I believe having pure functions does not so much target
> removing state as it does making the state _explicit_.

Except State tends to make state implicit again, except for the fact
that there *is* state (which might be actually enough, I don't have
enough insight for any judgemental statements on the issue).

 > Thus, the State
> monad is not a work-around to purity, it's a way of purely describing
> state.

True.

>>>> And I think you can trace that to the need to interface with the real
>>>> world.
>>>
>>> I have the same gut feeling.
>>
>> I think interfacing with the outside world (still not "real" but just
>> bits inside the operating system and on disk) is one major source of
>> unreliability, but not the only one, and not necessarily the primary one.
>> YMMV.
>
> Yes, that unreliability comes with crossing the frontier between
> theoretical and applied computer sciences (that's an imprecise
> metaphor :-) )

:-D
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

MarLinn
In reply to this post by David McClain
On 2017-04-19 15:14, David McClain wrote:
> Ah Yes… I do now remember the “Race for the 5th Generation”, us
> against Japan. Lisp against Prolog. That was a fad?

I have read Haskell being described as "what M-expressions where
supposed to be". Granted, it's not compiled down to S-expressions – but
to the comparably simple Core, so the analogy has a bit more substance
than the visible sentimentality.
At the same time, in a way, our type system is a kind of Logic
Programming language. We state facts about our programs as well as rules
how to derive new facts, and the type checker tries to prove our system
to be either inconsistent or incomplete. The syntax is not as simple as
Prolog's, but that's partly due to the domain, partly because our type
language is a grown one.

In other words: After their feud, Lisp and Prolog must have made up and
spent a hot few nights together, probably in a seedy conference room in
Portland. Haskell is one of the results. Is it a perfect blend of its
parents' strengths? Ah, hell no. But no child ever is.

Which leads me to the question: Why the hell isn't there a sitcom about
programing languages yet?

Cheers,
MarLinn
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

MarLinn
In reply to this post by Joachim Durchholz
On 2017-04-19 15:58, Joachim Durchholz wrote:
> Am 19.04.2017 um 15:13 schrieb Sergiu Ivanov:
>> However, there are a couple big "backdoors", like the IO monad.
>
> Well, it's so awkward that people don't *want* to use it.

That's partly because IO isn't very well defined, and therefore used as
a catch-all. It's like the "other mail" folder, a stuff-drawer in the
kitchen or that one room in the basement: random things tend to
accumulate and rot in there because they don't have a better place.

One of the worst offenders from my perspective is (non-)determinism.
Randomness can be seen as non-deterministic, but it doesn't need IO. At
the same time, many things that are in IO are practically not less
deterministic than pure functions with _|_ – once you have a good enough
model. In other words, these things could be separated. It needs work,
to model the real world, to go through all the stuff that's in that
black box, to convince people to not use IO if they don't need to, to
change the systems to even allow "alternative IOs"… so it's nothing
that'll change soon.

But my point is: The type system can only help you if there are precise
definitions and rules, but IO is the "here be dragons" on our maps of
the computational world – for one, because the open work I mentioned is
one of the ways to explore that boundary between theoretical and applied
computer sciences.
IO is the elephant in the room of type-supported hopes of correctness.
But then I agree with Joachim: it's also right in the center of the room
where everyone can see, acknowledge, and avoid it.

Cheers,
MarLinn
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

Sergiu Ivanov-2
In reply to this post by Joachim Durchholz

Thus quoth  Joachim Durchholz  at 13:58 on Wed, Apr 19 2017:
> Am 19.04.2017 um 15:13 schrieb Sergiu Ivanov:
>>
>> However, there are a couple big "backdoors", like the IO monad.
>
> Well, it's so awkward that people don't *want* to use it.

Interesting point of view, I've never thought of the relative
awkwardness of IO as of an educational measure.

>> Typechecking gives zero guarantees for functions of type IO (), for
>> example.
>
> That doesn't match what I hear from elsewhere.
> I don't know what is the cause for that difference though.

I'm probably shouting my "zero" too loudly.

I wanted to say that, when the typechecker sees a function of type
IO (), it only knows that it _may_ have side effects, but it cannot
verify that these effects compose correctly with the effects coming from
other functions in the IO monad.

Of course, the return type IO () still gives a lot of information (e.g.,
it says the function is only useful for its side effects) and the type
system will ensure that any computation actually using this function
must be declared as (potentially) having side effects.  Yet, you have no
guarantees that such effects are composed correctly.

>> In fact, I believe having pure functions does not so much target
>> removing state as it does making the state _explicit_.
>
> Except State tends to make state implicit again, except for the fact
> that there *is* state (which might be actually enough, I don't have
> enough insight for any judgemental statements on the issue).

Well, a typical definition of State is parameterised in the type of the
state, so you know what it is.

Sure, a typical definition of State does not let you know whether and
how the state was modified, but if one wants that information, one can
"just" define a custom "StateLog" monad, for example, or even use
Applicative to statically "record" the effects on the state (I hear
that's one use of Applicative).

--
Sergiu

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

Sergiu Ivanov-2
In reply to this post by MarLinn

Thus quoth  MarLinn  at 15:10 on Wed, Apr 19 2017:

> On 2017-04-19 15:58, Joachim Durchholz wrote:
>> Am 19.04.2017 um 15:13 schrieb Sergiu Ivanov:
>>> However, there are a couple big "backdoors", like the IO monad.
>>
>> Well, it's so awkward that people don't *want* to use it.
>
> That's partly because IO isn't very well defined, and therefore used as
> a catch-all. It's like the "other mail" folder, a stuff-drawer in the
> kitchen or that one room in the basement: random things tend to
> accumulate and rot in there because they don't have a better place.
Exactly.

> One of the worst offenders from my perspective is (non-)determinism.

Oh, right, interesting!

> Randomness can be seen as non-deterministic, but it doesn't need IO. At
> the same time, many things that are in IO are practically not less
> deterministic than pure functions with _|_ – once you have a good enough
> model. In other words, these things could be separated. It needs work,
> to model the real world, to go through all the stuff that's in that
> black box, to convince people to not use IO if they don't need to, to
> change the systems to even allow "alternative IOs"… so it's nothing
> that'll change soon.

I tend to see monads like STM (software transactional memory) and ST
(strict state threads) as a kind of "add structure to IO" effort.

Also, there's Eff (algebraic effects), but I still haven't had the time
to read the seminal work beyond introduction:

  http://www.eff-lang.org/


> IO is the elephant in the room of type-supported hopes of correctness.

I like this image :-)

--
Sergiu

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

Joachim Durchholz
In reply to this post by Sergiu Ivanov-2
Am 19.04.2017 um 17:56 schrieb Sergiu Ivanov:
>
> I wanted to say that, when the typechecker sees a function of type
> IO (), it only knows that it _may_ have side effects, but it cannot
> verify that these effects compose correctly with the effects coming from
> other functions in the IO monad.

Ah right.
Even Haskell's type system is not able to classify and characterize side
effects properly.
I don't think that that's a defect in the type system though; I've had
my own experiences with trying to do that (based on design by contract,
if anybody is interested), and I found it's pretty much uncontrollable
unless you go for temporal logic, which is so hard to reason about that
I do not think it's going to be useful to most programmers. (Temporal
logic exists in several variants, so maybe I was just looking at the
wrong one.)

>>> In fact, I believe having pure functions does not so much target
>>> removing state as it does making the state _explicit_.
>>
>> Except State tends to make state implicit again, except for the fact
>> that there *is* state (which might be actually enough, I don't have
>> enough insight for any judgemental statements on the issue).
>
> Well, a typical definition of State is parameterised in the type of the
> state, so you know what it is.
>
> Sure, a typical definition of State does not let you know whether and
> how the state was modified, but if one wants that information, one can
> "just" define a custom "StateLog" monad, for example, or even use
> Applicative to statically "record" the effects on the state (I hear
> that's one use of Applicative).

Thanks, that's going to guide me in future attempts at understanding all
the strange and wondrous (and sometimes awesome) things you can find in
the Haskell ecology.

Regards,
Jo
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

Richard A. O'Keefe
In reply to this post by Joachim Durchholz

> On 20/04/2017, at 1:52 AM, Joachim Durchholz <[hidden email]> wrote:
>
> Common Lisp and Scheme were, in their first years.
> They both managed to transition from "fad" to "production-ready" AFAICT, probably after a stabilization period (I dimly recall having read versioned standardization documents).
>
> Lisp as such... probably. Whenever people with enough raw horsepower to use Lisp in practice met people who didn't, because then it would be a fad from the latter ones. Which pretty much meant everybody who didn't have access to abundant corporate-sponsored or state-sponsored hardware.

Truly strange.  You really did not need "horsepower" to use Lisp in practice.
There were several Lisp implementations for CP/M, and CP/M machines
were hardly "raw horsepower" by any stretch of the imagination.

OK, a University lab of cheap 8086 PCs does technically count as
state-sponsored, but hardly "raw horsepower".  I suppose the price
of TI PC-Scheme (USD95) would have put it out of reach of hobbyists
/sarc.  (I would definitely call PC-Scheme "production-ready" for
its day.)

The problem with Lisp was never garbage collection, or speed, or availability.
It was *unfamiliarity*.  As soon as things like TCL and Python became available,
they were adopted gladly by many programmers, despite being less efficient than
typical Lisps.  To this day, Python forcibly discourages recursive programming
by enforcing a small stack depth, even on machines with abundant memory, thus
ensuring that Python keeps its reassuringly familiar imperative style.  (Yep,
ran into this the hard way, trying to implement a dynamic programming algorithm
in Python.)

I'm very sad to see FUD about Lisp surviving this long.
Much the same FUD was spread about Prolog, despite there being decent
Prolog implementations for cheap 16-bit machines.

It is *bitterly* ironic to see Java adopted by people critical of Lisp.
It just goes to show that the old hardware saying, "you can make a
brick fly if you strap on a big enough jet engine" is true of programming languages.



_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

Joachim Durchholz
Am 20.04.2017 um 02:51 schrieb Richard A. O'Keefe:

>
>> On 20/04/2017, at 1:52 AM, Joachim Durchholz <[hidden email]> wrote:
>>
>> Common Lisp and Scheme were, in their first years.
>> They both managed to transition from "fad" to "production-ready" AFAICT, probably after a stabilization period (I dimly recall having read versioned standardization documents).
>>
>> Lisp as such... probably. Whenever people with enough raw horsepower to use Lisp in practice met people who didn't, because then it would be a fad from the latter ones. Which pretty much meant everybody who didn't have access to abundant corporate-sponsored or state-sponsored hardware.
>
> Truly strange.  You really did not need "horsepower" to use Lisp in practice.
> There were several Lisp implementations for CP/M, and CP/M machines
> were hardly "raw horsepower" by any stretch of the imagination.

If that had been universally true, nobody would have bothered to think
about, let alone buy those Lisp machines.

> OK, a University lab of cheap 8086 PCs does technically count as
> state-sponsored, but hardly "raw horsepower".  I suppose the price
> of TI PC-Scheme (USD95) would have put it out of reach of hobbyists
> /sarc.

Nah, it simply wasn't available unless you knew it existed.
(I certainly didn't know.)

> The problem with Lisp was never garbage collection, or speed, or availability.
> It was *unfamiliarity*.

Nope.
Actually, the first actual project I ever built was a (primitive) Lisp
interpreter. I would have liked to work with it, but I lost access to
the machine (that was in the pre-PC era), plus I didn't know enough to
devise a way to integrate it into the surrounding operating system.

 > As soon as things like TCL and Python became available,
> they were adopted gladly by many programmers, despite being less efficient than
> typical Lisps.

I don't know what motivated anybody to ever use TCL. It's an abomination.
Python doesn't count, it wasn't even thought about in the IBM PC days.

> I'm very sad to see FUD about Lisp surviving this long.

Enough of this kind of slur.
I'm not adhering to "FUD", I am reporting personal experience.
I have been refraining from responding in kind, because some unfriendly
things could be said about your mindset.

> Much the same FUD was spread about Prolog, despite there being decent
> Prolog implementations for cheap 16-bit machines.

Sorry, Prolog simply didn't work. As soon as you tried to do anything
that was prone to combinatoric explosion, you had to resort to cuts and
essentially revert to a uselessly complicated imperative programming
model just to keep that under control.
I am well aware that Prolog can be an excellent tool, but only for tasks
that it fits. Unfortunately, most paid jobs are too simple to actually
need Prolog, and of the complicated ones, only a small fraction can even
be adequately captured using Horn clauses.

I'm not talking from theory here. I tried to adopt a simple distance
calculation in a hexagonal lattice with it. I realized that to make it
reversible I'd need have it do the inverse of finding the distance of
two known points, namely find the list of distance-N points from a given
centerpoint, which I liked because I needed that anyway; however, it
turned out to be O(N^6) because it would explore ALL the paths inside
the radius-N circle, and that was useless.
Making it avoid that involved cuts, which would make the ruleset
non-reversible, and hence non-composable under standard Prolog semantics
(you'd be unable to add rules that would e.g. exempt blockaded points
from the pathfinding). In other words, the resulting code would be an
imperative program, shoehorned into a Prolog ruleset, giving me the
worst of both worlds.
No I'm fully aware that I might be able to find better solutions now,
some three decades of experience later. But I don't think that Prolog's
approach will scale to teams of average programmers, and I doubt you can
find enough programmers to staff any project worth doing, unless your
tasks are a natural fit to Prolog. (Of course there are people who do
non-Horn-clause-ish things with Prolog, and successfully so. If all you
have a hammer, then every problem starts looking like a nail.)

> It is *bitterly* ironic to see Java adopted by people critical of Lisp.

I was forced to. I'd really love to live off Haskell programming.
I'd even be happy doing Scala - it's far from perfect, but it integrates
well with Java libraries, and that's a huge bonus that people without
experience in a JVM language seem to be unable to appreciate; I suspect
the Blub paradox at work here.

> It just goes to show that the old hardware saying, "you can make a
> brick fly if you strap on a big enough jet engine" is true of programming languages.

Exactly.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

Sergiu Ivanov-2
In reply to this post by Joachim Durchholz

Thus quoth  Joachim Durchholz  at 18:39 on Wed, Apr 19 2017:

> Am 19.04.2017 um 17:56 schrieb Sergiu Ivanov:
>>
>> I wanted to say that, when the typechecker sees a function of type
>> IO (), it only knows that it _may_ have side effects, but it cannot
>> verify that these effects compose correctly with the effects coming from
>> other functions in the IO monad.
>
> Ah right.
> Even Haskell's type system is not able to classify and characterize side
> effects properly.
The language Eff seems to be built around an algebraic characterisation
(according to the author, I haven't yet had the time to check) and
handling of effects:

  http://www.eff-lang.org/

According to the page, the proposed formalism allows doing elegantly
what in Haskell is typically done with monad transformers.

I actually started thinking about porting the algebraic handling of
effects to Haskell, which may be possible since its type system seems to
be expressive enough, but my time is quite limited these days.

> I don't think that that's a defect in the type system though; I've had
> my own experiences with trying to do that (based on design by contract,
> if anybody is interested), and I found it's pretty much uncontrollable
> unless you go for temporal logic, which is so hard to reason about that
> I do not think it's going to be useful to most programmers. (Temporal
> logic exists in several variants, so maybe I was just looking at the
> wrong one.)

Temporal logics kind of require guys with PhDs in your team :-) From
what I know, the usual approach is designing (or adapting) a temporal
logic for your specific task, since general properties are often
undecidable.

Your experience of handling effects seems interesting to me.

--
Sergiu

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

Richard A. O'Keefe
In reply to this post by Joachim Durchholz

> On 20/04/2017, at 8:21 PM, Joachim Durchholz <[hidden email]> wrote:
>>
>> Truly strange.  You really did not need "horsepower" to use Lisp in practice.
>> There were several Lisp implementations for CP/M, and CP/M machines
>> were hardly "raw horsepower" by any stretch of the imagination.
>
> If that had been universally true, nobody would have bothered to think about, let alone buy those Lisp machines.

You seem to be confusing the horsepower required to run *LISP*
with the horsepower required to run *an IDE*.
I never used an MIT-family Lisp machine, but I spent a couple
of years using Xerox Lisp machines.
Those machines had 16-bit (yes, 16-bit) memory buses (so to
fetch one tag+pointer "word" of memory took three memory
cycles: check page table, load half word, load other half),
and into 4 MB of memory fitted
 - memory management (Lisp)
 - device drivers (Lisp)
 - network stack (Lisp)
 - (networked) file system (Lisp)
 - bit mapped graphics (Lisp; later models added colour)
 - structure editor (Lisp)
 - WYSIWIG text editor with 16-bit character set (Lisp)
 - compiler (Lisp)
 - automatic error correction DWIM (Lisp)
 - interactive cross reference MasterScope (Lisp)
 - dynamic profiling better than anything I've used since (Lisp)
and -- this is what I was working on --
 - 1 MB dedicated to Prolog, including Prolog compiler (Prolog)

In terms of memory capacity and "horsepower", the D-machines were
roughly comparable to an M68010-based Sun workstation.

But the memory and "horsepower" weren't needed to run *Lisp*,
they were needed to run all the *other* stuff.

Interlisp-D was a very nice system to use.  It was forked from
Interlisp, which ran on machines with less than a megabyte of memory,
but lacked the IDE, network stack, &c.

I never had the pleasure of using an MIT-family Lisp machine,
although I worked with two people who had, so I can say it was
the same issue there.  They did *everything* in an *integrated*
way in Lisp.  Complaining that those machines needed "horsepower"
is like complaining that Eclipse needs serious horsepower (my
word, doesn't it just) and blaming the C code you are editing in
it.

Heck, there was even a Scheme system for the Apple ][.

>
>> OK, a University lab of cheap 8086 PCs does technically count as
>> state-sponsored, but hardly "raw horsepower".  I suppose the price
>> of TI PC-Scheme (USD95) would have put it out of reach of hobbyists
>> /sarc.
>
> Nah, it simply wasn't available unless you knew it existed.
> (I certainly didn't know.)

No, that's not what "available" means.  It was offered for sale.
It was advertised.  There was a published book about how to use
it.  It really was not at all hard to find if you looked.
>
>> I'm very sad to see FUD about Lisp surviving this long.
>
> Enough of this kind of slur.

When you say that Lisp was not used because it required serious "horsepower",
you say what is not true.  Lisp did not require serious "horsepower".
Some of the *applications* that people wanted to write in Lisp required
serious "horsepower", but they would have required such no matter what the
programming language, and the relevance of Lisp was simply that it made
such applications *thinkable* in a way that most other languages did not.

As for Python, if we define "PC days" to include 1988, when there
were about a dozen Lisps running on 286s, so yes, Python began in
late 1989 and 1.0 was released in 2004, so you're right.  But I never
said Python was eagerly adopted in the "PC days".  

> I have been refraining from responding in kind, because some unfriendly things could be said about your mindset.

My mindset is that SML is better than Lisp and Haskell is better than SML
and there are languages pushing even further than Haskell in interesting
directions.  I stopped counting how many programming languages I had tried
when I reached 200.

Things have changed a lot.  We now have compilers like SMLtoJs
http://www.smlserver.org/smltojs/
so that we can compile statically typed mostly-functional code into
dynamically typed strange code so that we can run it in a browser.

All the old complaints about Lisp, and we end up with JavaScript.
But that's OK because it has curly braces. (:-(

We have massive amounts of software in the world these days,
and as far as I can tell, all of it is more or less broken.
Read about the formal verification of seL4.  It is downright
scary how many bugs there can be in such a small chunk of code.
And it's interesting that the people who did it now believe that
formal verification can be *cheaper* than testing, for a given
target error rate.

The great thing about Lisp in the old days was that it could massively
reduce the amount of code you had to write, thus reducing the number
of errors you made.

The great thing about Haskell is that it pushes that even further,
and the type system helps to catch errors early.
And QuickCheck!  What a feature!

There are other things, like PVS and Coq, which push verification
at compile time further than Haskell (I never did manage to use
the PVS verifier, but there's a great book about Coq), and if it
turns out that bog standard programmers can't cope with that, then
hiring superstandard programmers able to produce closer-to-verified
code may be well worth the price.  I often struggle to follow the
things the brilliant people on this list do with Haskell's type
system, but I very much appreciate their aim of producing correct
code.



_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Wow Monads!

Joachim Durchholz
I'm not going to continue this, you keep insisting that I'm somehow
either an idiot or acting maliciously, and neither is a role that I like
to be in.
I'm slightly pissed off, and that's not a good basis for continuing a
constructive exchange, and there's too much risk that we're really mad
at each other if we continue this.

Regards,
Jo
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
123