Backward compatibility

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

Re: Backward compatibility

Ben Doyle
> What pray tell are those missing pieces? Aren't they mostly building a browser based ide > plus doing training courses ?

Sure, and I believe they plan to have that browser-based IDE talk to a virtual server, with a compiler and set of libraries they maintain. That'd solve Adrian's problems, no? So long as he can bring himself to use Yesod over WASH?

Perhaps more importantly, they're well-spoken and business-savvy, and they can persuasively promise that they'll make a risk-averse corporation's (overblown) worries go away. If he's in a management battle, he ought to know where to hire some mercenaries. 



On Sat, May 4, 2013 at 2:03 PM, Carter Schonwald <[hidden email]> wrote:

What pray tell are those missing pieces? Aren't they mostly building a browser based ide plus doing training courses ?

On May 4, 2013 1:42 PM, "Ben Doyle" <[hidden email]> wrote:
You might want to check out FPComplete, if you haven't already. They're far more focused on making it easy for organizations to adopt Haskell than the community can be. As they say: "Where the open-source process is not sufficient to meet commercial adoption needs, we provide the missing pieces."

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Fwd: Backward compatibility

Adrian May
In reply to this post by Niklas Hambüchen
Oops, forgot hit hit reply-all the first time, well spotted by Niklas...

---------- Forwarded message ----------
From: Adrian May <[hidden email]>
Date: 5 May 2013 14:22
Subject: Re: [Haskell-cafe] Backward compatibility
To: Niklas Hambüchen <[hidden email]>



The fact that it doesn't build and that the last change is from 2007 the
*is* the warning that it is completely unmaintained and not the way to
do things today.

(One could even say that by making it build on 7.6, I have removed this
warning and given the illusion that everything is fine.)

That only makes sense if you assume everybody is familiar with Haskell and its culture. But that neglects trying to make it attractive to people who aren't.

Of course I agree that it would be better if there were warnings on
their web sites that said "sorry guys, this project is dead now".

I would even be happy with newhackage sending every package maintainer a
quarterly question "Would you still call your project X 'maintained'?"
for each package they maintain; Hackage could really give us better
indications concerning this.


Something like that would make a lot of sense to me. 
 
Still I'd say that in this case, the fact that it did not build, hasn't
had a single change in the last half decade, and that you cannot find
any recent discussion about it anywhere on the Internet, make it pretty
clear what is going on here, even for non-technical people.

Half a decade is nothing to most programming cultures.
A newbie looks for sample code and blames himself if he can't get it working.
 
> Please don't say that it's my culture's fault.

From your story it sounds like you have a problem with developer
simplemindedness and management wars idiocy. Nobody is forcing 
you to be part of that. There are a lot of places ...

Perhaps I'd rather help those who need it than preach to the converted.

You summed it up nicely as two problems: (1) bitchy managers and (2) untrained programmers. I'd like to use Haskell to help with (2) but I still have to work around (1). My plan is to start by winning the hearts and minds of the developers before sticking my neck out far enough to get it severed. There's another plan where I'm pitching VCs about a start up, in which case I'd have a lot more control, but I'd still have to prove that my elite imperative squad were willing and able to learn a new trick before committing myself.

I've actually learned quite a lot from this discussion and that largely enables me to preempt any Rails-day problems. But that's only me. Lots of people might be flirting with Haskell just out of curiosity and bouncing off it for these reasons. There have been a lot of good ideas suggested about how to minimise that, and I'd also throw in that it would be cool if people could tell the compiler to behave as it did half a decade ago when the code was written so people could prove to themselves that the code works in principle, then they could clock the compiler forward little by little, reading its release notes along the way. That's a lot friendlier than being confronted with an apparently endless series of error messages when you've barely learned to read them, and not even knowing if you're making things better or worse. If the desired compiler/modules version was in the makefile, that, I think, would be a general solution.

The FPComplete thing also looks helpful. I could use that to sell the language to newbies. The mercenaries would come later though. 

Thanks to everybody for helping out with this. 

Adrian.






_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Backward compatibility

Simon Marechal
On 05/05/2013 11:41 AM, Adrian May wrote:
> Half a decade is nothing to most programming cultures.
> A newbie looks for sample code and blames himself if he can't get it
> working.

I ran into this kind of trouble when I was starting to learn Haskell. I
had error messages like that :

test.hs:1:8:
    Could not find module `List'
    It is a member of the hidden package `haskell98-2.0.0.2'.
    Use -v to see a list of the files searched for.

I then proceeded to figure how to include this haskell98 package, and
later ran into other problems. Perhaps this message could be hard coded
to tell the user that this is deprecated code, and he should use
Data.List instead. This certainly would be friendlier, but I am unsure
it would change anything about adoption:
* all major tutorials are up to date
* almost everyone understands the concept of bit rot, and, as it has
been demonstrated, it is much more manageable than with other
"production ready" languages
* google works fairly well

Everything changes all the time in the javascript and ruby world, but
this doesn't seem to reduce adoption.

There have been several people pointing out the case of PHP. I would say
that with an ageing codebase, you can't upgrade your distribution
because the little things that change will break your code in places you
don't even imagine. With a 10 years old Haskell program, you can choose
to upgrade the codebase, or you can stick with your old binary.

> it would be cool if people could tell the compiler to behave as it did
> half a decade ago when the code was written so people could prove to
> themselves that the code works in principle, then they could clock the
> compiler forward little by little, reading its release notes along the way.

But how would that work ? You would need some archaeologist to tell you
how old the code is so that you could give the proper flags to the
compiler. But if you know how to do that, then you know exactly how to
fix the code.

But you already can do this all by yourself : just install every compilers.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Backward compatibility

Raphael Gaschignard


On Sun, May 5, 2013 at 8:25 PM, Simon Marechal <[hidden email]> wrote:
I ran into this kind of trouble when I was starting to learn Haskell. I
had error messages like that :

test.hs:1:8:
    Could not find module `List'
    It is a member of the hidden package `haskell98-2.0.0.2'.
    Use -v to see a list of the files searched for.

I then proceeded to figure how to include this haskell98 package, and
later ran into other problems. Perhaps this message could be hard coded
to tell the user that this is deprecated code, and he should use
Data.List instead.

Forgive me if I'm wrong, but I feel like I've seen such "suggestions" in GHC errors before.

If so, does that mean there's some sort of mechanism in the compiler already in place for such error recognition? Like some simple pattern stuff?  If not, I think that it might not be bad to consider this stuff (misused packaged, changed semantics that create compiler errors), and to put something into place for future modifications. This could make it a lot easier to deal with unmaintained code.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Backward compatibility

amindfv
+1

Tom


El May 5, 2013, a las 7:55 AM, Raphael Gaschignard <[hidden email]> escribió:



On Sun, May 5, 2013 at 8:25 PM, Simon Marechal <[hidden email]> wrote:
I ran into this kind of trouble when I was starting to learn Haskell. I
had error messages like that :

test.hs:1:8:
    Could not find module `List'
    It is a member of the hidden package `haskell98-2.0.0.2'.
    Use -v to see a list of the files searched for.

I then proceeded to figure how to include this haskell98 package, and
later ran into other problems. Perhaps this message could be hard coded
to tell the user that this is deprecated code, and he should use
Data.List instead.

Forgive me if I'm wrong, but I feel like I've seen such "suggestions" in GHC errors before.

If so, does that mean there's some sort of mechanism in the compiler already in place for such error recognition? Like some simple pattern stuff?  If not, I think that it might not be bad to consider this stuff (misused packaged, changed semantics that create compiler errors), and to put something into place for future modifications. This could make it a lot easier to deal with unmaintained code.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Backward compatibility

Brandon Allbery
In reply to this post by Raphael Gaschignard
On Sun, May 5, 2013 at 7:55 AM, Raphael Gaschignard <[hidden email]> wrote:
Forgive me if I'm wrong, but I feel like I've seen such "suggestions" in GHC errors before.

If so, does that mean there's some sort of mechanism in the compiler already in place for such error recognition? Like some simple pattern stuff?  If not, I think that it might not be bad to consider this stuff (misused packaged, changed semantics that create compiler errors), and to put something into place for future modifications. This could make it a lot easier to deal with unmaintained code.

There's some very limited capability now; the GHC folks are tossing around ideas for something more general like that.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Backward compatibility

Alberto G. Corona
The case of WASH is a pity. Architecturally It was more advanced that many recent haskell web frameworks.  The package would have been a success with little changes in the DSL syntax.

I suspect that there are many outstanding packages with great ideas abandoned, like WASH
 


2013/5/5 Brandon Allbery <[hidden email]>
On Sun, May 5, 2013 at 7:55 AM, Raphael Gaschignard <[hidden email]> wrote:
Forgive me if I'm wrong, but I feel like I've seen such "suggestions" in GHC errors before.

If so, does that mean there's some sort of mechanism in the compiler already in place for such error recognition? Like some simple pattern stuff?  If not, I think that it might not be bad to consider this stuff (misused packaged, changed semantics that create compiler errors), and to put something into place for future modifications. This could make it a lot easier to deal with unmaintained code.

There's some very limited capability now; the GHC folks are tossing around ideas for something more general like that.


--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Alberto.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Backward compatibility

Darren Grant-2

Just to be clear,  is WASH beyond redemption,  or would it be worth reviving again? If so,  why?

Cheers,
Darren

On 2013-05-05 1:48 PM, "Alberto G. Corona" <[hidden email]> wrote:
The case of WASH is a pity. Architecturally It was more advanced that many recent haskell web frameworks.  The package would have been a success with little changes in the DSL syntax.

I suspect that there are many outstanding packages with great ideas abandoned, like WASH
 


2013/5/5 Brandon Allbery <[hidden email]>
On Sun, May 5, 2013 at 7:55 AM, Raphael Gaschignard <[hidden email]> wrote:
Forgive me if I'm wrong, but I feel like I've seen such "suggestions" in GHC errors before.

If so, does that mean there's some sort of mechanism in the compiler already in place for such error recognition? Like some simple pattern stuff?  If not, I think that it might not be bad to consider this stuff (misused packaged, changed semantics that create compiler errors), and to put something into place for future modifications. This could make it a lot easier to deal with unmaintained code.

There's some very limited capability now; the GHC folks are tossing around ideas for something more general like that.


--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Alberto.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Backward compatibility

Tom Ellis
In reply to this post by Alberto G. Corona
On Sun, May 05, 2013 at 10:46:23PM +0200, Alberto G. Corona  wrote:
> The case of WASH is a pity. Architecturally It was more advanced that many
> recent haskell web frameworks.  The package would have been a success with
> little changes in the DSL syntax.

Could you briefly summarise the difference between WASH's approach and that
of the more recent frameworks?

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Backward compatibility

Alberto G. Corona
Well, the main one is  that is in the group of continuation based frameworks, like other advanced web frameworks such are seaside (smalltalk) ocsigen (ocaml) or coccoon (JavaScript)  . That means that it is not based on the event model, and the  flow is in a single procedure. This makes the navigation much more readable, as a console application. But WASH is  not continuation based, but log based, and the log was stored in the client, that means that it was also restful to a certain level. That approach solved the big problems of memory usage and serialization of continuation based frameworks.
 
It also solved the problem of form safety before the development of formlets and the widespread of applicative functors.
 
But I do not pretend to resucitate WASH. I just miss a continuation of this line of work , but this was not the case. 
 
I  took a deeper look at WASH after developping MFlow, years after the discontinuation of WASH. MFlow coincidentally, is log based in a different way. I supposed that it was based on continuations, and I didn't like them, but it was not. If the project would have been prosecuted, who knows...It had a edge over other web developments in other languages, but it was hard to understand, just because the approach was original and unique. 
 
I consider MFlow as a continuation of WASH in "philosophical" terms.


2013/5/6 Tom Ellis <[hidden email]>
On Sun, May 05, 2013 at 10:46:23PM +0200, Alberto G. Corona  wrote:
> The case of WASH is a pity. Architecturally It was more advanced that many
> recent haskell web frameworks.  The package would have been a success with
> little changes in the DSL syntax.

Could you briefly summarise the difference between WASH's approach and that
of the more recent frameworks?

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Alberto.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12345