Backward compatibility

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

Re: Backward compatibility

Guy
David Thomas wrote:

> I'd also like to see these two.  It occurs to me there may be language tweak that could reduce breakage and add some
> convenience in both cases.  It would not surprise me at all if this has been thought of, examined, and discarded, but I
> don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know
> where.
>
> The idea is to allow definitions of superclass operations in subclass instances.  If there are such definitions, it's
> treated as if there were instances defined for each class (potentially a source translation, even).  I think default
> definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the
> superclass, and only if the superclass didn't have a default for that).
>
> This should allow existing instances of Num to just work (and I think Monad too, with some care).  It would also mean if
> you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit
> of boilerplate.  At the same time, you'd have the flexibility to just use the superclasses where you just want pieces.

http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances

I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind
of class hierarchy clean-up without breaking lots of code.


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

Re: Backward compatibility

David Thomas
That's approximately what I was describing, yes.  Thanks!


On Fri, May 3, 2013 at 7:54 AM, Guy <[hidden email]> wrote:
David Thomas wrote:
I'd also like to see these two.  It occurs to me there may be language tweak that could reduce breakage and add some
convenience in both cases.  It would not surprise me at all if this has been thought of, examined, and discarded, but I
don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know
where.

The idea is to allow definitions of superclass operations in subclass instances.  If there are such definitions, it's
treated as if there were instances defined for each class (potentially a source translation, even).  I think default
definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the
superclass, and only if the superclass didn't have a default for that).

This should allow existing instances of Num to just work (and I think Monad too, with some care).  It would also mean if
you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit
of boilerplate.  At the same time, you'd have the flexibility to just use the superclasses where you just want pieces.

http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances

I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind of class hierarchy clean-up without breaking lots of 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: Backward compatibility

Adrian May
In reply to this post by Guy
I'm having a bit of trouble getting my brain around that, but if anybody cares about attracting new users, that might be relevant in itself. Perhaps I could be seen as an example of your swing-state. I'm no Haskell expert but I'd like to push it if I could cos I'm so sick of seeing huge codebases land in the dustbin due to the evils of imperative coding. The version-controlled modules thing is immediately comforting for me cos I know what it is and I could fire it at the manager next door who doesn't know much but fancies my job. 


On 3 May 2013 22:54, Guy <[hidden email]> wrote:
David Thomas wrote:
I'd also like to see these two.  It occurs to me there may be language tweak that could reduce breakage and add some
convenience in both cases.  It would not surprise me at all if this has been thought of, examined, and discarded, but I
don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know
where.

The idea is to allow definitions of superclass operations in subclass instances.  If there are such definitions, it's
treated as if there were instances defined for each class (potentially a source translation, even).  I think default
definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the
superclass, and only if the superclass didn't have a default for that).

This should allow existing instances of Num to just work (and I think Monad too, with some care).  It would also mean if
you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit
of boilerplate.  At the same time, you'd have the flexibility to just use the superclasses where you just want pieces.

http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances

I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind of class hierarchy clean-up without breaking lots of 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: Backward compatibility

David Thomas
In reply to this post by Guy
That's approximately what I was describing, yes.  Thanks!


On Fri, May 3, 2013 at 7:54 AM, Guy <[hidden email]> wrote:
David Thomas wrote:
I'd also like to see these two.  It occurs to me there may be language tweak that could reduce breakage and add some
convenience in both cases.  It would not surprise me at all if this has been thought of, examined, and discarded, but I
don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know
where.

The idea is to allow definitions of superclass operations in subclass instances.  If there are such definitions, it's
treated as if there were instances defined for each class (potentially a source translation, even).  I think default
definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the
superclass, and only if the superclass didn't have a default for that).

This should allow existing instances of Num to just work (and I think Monad too, with some care).  It would also mean if
you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit
of boilerplate.  At the same time, you'd have the flexibility to just use the superclasses where you just want pieces.

http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances

I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind of class hierarchy clean-up without breaking lots of 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: Backward compatibility

Brandon Allbery
In reply to this post by Guy
On Fri, May 3, 2013 at 10:54 AM, Guy <[hidden email]> wrote:

I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind of class hierarchy clean-up without breaking lots of code.

IIRC they've been tried and found to actually cause more backward compatibility issues than they solve because there are so many packages which have created their own instances, and nobody's found a workaround that doesn't either do that or lead to bizarre type errors.

--
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: Backward compatibility

Tobias Dammers
In reply to this post by Ozgur Akgun
On Fri, May 03, 2013 at 03:35:08PM +0100, Ozgur Akgun wrote:

> Hi,
>
> On 3 May 2013 11:43, Tobias Dammers <[hidden email]> wrote:
>
> > > PS The proposal to fix Functor => Applicative => Monad has patches
> > > attached for GHC and base, but the backwards compatibility bogeyman
> > > always seems to trump something that will break a lot of code.
> >
> > This kind of "breaks everything" changes would require something similar
> > to what Python is doing with the 2 -> 3 transition, and considering how
> > painfully slowly it is progressing there, I understand perfectly well why
> > people don't want to go there.
> >
>
> There is one very big advantage in the Haskell-world though.
> Most of the struggle will be at the compile time. The biggest headache
> caused by
> the Python 2 -> 3 transition is how you get a runtime error 2 weeks after
> you think
> you've fixed everything!
>
> (Yeah, I know code coverage analysis is an option when you don't have static
> type checking, but ...)

Well; this is an additional problem that comes with the pragmatic choice
for a language that doesn't believe in type checking and compile-time
guarantees, but I think it is largely orthogonal. At least
theoretically, you could have 100% test coverage, which would put the
Python project in the same situation as the Haskell one (except that the
tests themselves would also have to be converted...)

The problem I'm talking about, though, is that such a change would split
the ecosystem in two (say, "Traditional Haskell" and "Functor-Correct
Haskell"), just like the 2/3 separation is all over the Python ecosystem
and causes all sorts of headaches. "Should I be using Python 2 or 3" is
not a question that has a simple answer, and that *is* a problem.

>
> Cheers,
> Ozgur

> _______________________________________________
> 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: Backward compatibility

Niklas Hambüchen
In reply to this post by Adrian May
While I certainly enjoy the discussion, how about addressing one of the
original problems:

On 02/05/13 13:27, Adrian May wrote:
> I just tried to use Flippi. It broke because of the syntax change so I
> tried WASH. I couldn't even install it because of the syntax change.

I just fixed that in https://github.com/nh2/flippi (note that I have
never seen this code before nor even known about it).

https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313d

Had to delete 5 imports and convert one time value.

Took me around 3 minutes.

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

Re: Backward compatibility

Edward Kmett-2
In reply to this post by Adrian May
"Tantamount to a new language" to fix a minor detail in a typeclass hierarchy? That is just histrionic. No language is that stable.

Scala makes dozens of changes like that between minor versions, and while I hardly hold up their development practices as the best in the industry it is still somehow seen as enterprise ready.

-Edward



On Fri, May 3, 2013 at 6:52 AM, Adrian May <[hidden email]> wrote:

PS The proposal to fix Functor => Applicative => Monad has patches attached for GHC and base, but the backwards compatibility bogeyman always seems to trump something that will break a lot of code.

I think that should be fixed as well, but it would be tantamount to a new language. 

I guess you need some kind of versioning system for the libraries. Why not put them all in a public source control server and have ghc force people to say which snapshot they wanted. That would be your final breaking change, and it's a one-liner in the Makefile. Then you could thrash around as much as you liked and people like me would have nothing to complain about. Naturally, the compiler itself should keep supporting old modes.

Adrian.

 


_______________________________________________
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



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

Re: Backward compatibility

Edward Kmett-2
In reply to this post by Niklas Hambüchen
So basically it boiled down drop the haskell98 package dependency and use the new exception system, and import the right things to avoid the use of the no longer exported Prelude catch?


On Fri, May 3, 2013 at 12:44 PM, Niklas Hambüchen <[hidden email]> wrote:
While I certainly enjoy the discussion, how about addressing one of the
original problems:

On 02/05/13 13:27, Adrian May wrote:
> I just tried to use Flippi. It broke because of the syntax change so I
> tried WASH. I couldn't even install it because of the syntax change.

I just fixed that in https://github.com/nh2/flippi (note that I have
never seen this code before nor even known about it).

https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313d

Had to delete 5 imports and convert one time value.

Took me around 3 minutes.

_______________________________________________
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: Backward compatibility

Bardur Arantsson-2
In reply to this post by Niklas Hambüchen
On 05/03/2013 06:44 PM, Niklas Hambüchen wrote:

> While I certainly enjoy the discussion, how about addressing one of the
> original problems:
>
> On 02/05/13 13:27, Adrian May wrote:
>> I just tried to use Flippi. It broke because of the syntax change so I
>> tried WASH. I couldn't even install it because of the syntax change.
>
> I just fixed that in https://github.com/nh2/flippi (note that I have
> never seen this code before nor even known about it).
>
> https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313d
>
> Had to delete 5 imports and convert one time value.
>
> Took me around 3 minutes.
>

+1



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

Re: Backward compatibility

Bardur Arantsson-2
In reply to this post by Edward Kmett-2
On 05/03/2013 06:49 PM, Edward Kmett wrote:
> "Tantamount to a new language" to fix a minor detail in a typeclass
> hierarchy? That is just histrionic. *No* language is that stable.
>
> Scala makes dozens of changes like that between *minor* versions, and while
> I hardly hold up their development practices as the best in the industry it
> is still somehow seen as enterprise ready.
>
> -Edward

Indeed. It's all turned into absurd hyperbole at this point.

Regards,



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

Re: Backward compatibility

amindfv
In reply to this post by Adrian May
On Thu, May 2, 2013 at 9:48 PM, Adrian May <[hidden email]> wrote:


Is anybody in the Haskell community still interested in attracting new users? If so I suggest you go play with Ruby on Rails. Then you'll know what it's like to approach a complex and unfamiliar system where every crumb requires a precise version of every other. If you had my job, you'd find out what you needed to know within half an hour.
 


Rails is in many ways as (more?) backwards-incompatible as Haskell. E.g., Rails 4 requires(!) Ruby 1.9.3+. 1.9.3 was released in the fall of 2011. When new major versions of Rails or Ruby come out, developers are generally expected to make the incremental changes to keep up. It's the "donkey in a well" thing -- you never get buried if you make small changes over time.

Tom

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

Re: Backward compatibility

Hilco Wijbenga
In reply to this post by Niklas Hambüchen
On 3 May 2013 09:44, Niklas Hambüchen <[hidden email]> wrote:

> While I certainly enjoy the discussion, how about addressing one of the
> original problems:
>
> On 02/05/13 13:27, Adrian May wrote:
>> I just tried to use Flippi. It broke because of the syntax change so I
>> tried WASH. I couldn't even install it because of the syntax change.
>
> I just fixed that in https://github.com/nh2/flippi (note that I have
> never seen this code before nor even known about it).
>
> https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313d
>
> Had to delete 5 imports and convert one time value.
>
> Took me around 3 minutes.

It seems fair to say that Haskell's designers lean more to evolution
than maintaining backward compatibility. This reminds me of "Go" (the
programming language). The approach chosen by Go's designers was to
create a tool (gofix) that would automatically fix one's code to
comply with the latest standard. See
[http://talks.golang.org/2012/splash.article#TOC_17.] (yes, include
that last period).

Given the apparent simplicity of the changes needed to keep one's
Haskell code up to snuff and the strong typing inherent in Haskell
code, would it not be possible to create something similar? If there
is a tool that moves (most of) one's code from Haskell version n to
n+1 then making breaking changes would be even less of an issue.

Just an idea, I have no clue about its feasibility...

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

Re: Backward compatibility

Nicolas Trangez
On Fri, 2013-05-03 at 10:40 -0700, Hilco Wijbenga wrote:

> On 3 May 2013 09:44, Niklas Hambüchen <[hidden email]> wrote:
> > While I certainly enjoy the discussion, how about addressing one of the
> > original problems:
> >
> > On 02/05/13 13:27, Adrian May wrote:
> >> I just tried to use Flippi. It broke because of the syntax change so I
> >> tried WASH. I couldn't even install it because of the syntax change.
> >
> > I just fixed that in https://github.com/nh2/flippi (note that I have
> > never seen this code before nor even known about it).
> >
> > https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313d
> >
> > Had to delete 5 imports and convert one time value.
> >
> > Took me around 3 minutes.
>
> It seems fair to say that Haskell's designers lean more to evolution
> than maintaining backward compatibility. This reminds me of "Go" (the
> programming language). The approach chosen by Go's designers was to
> create a tool (gofix) that would automatically fix one's code to
> comply with the latest standard. See
> [http://talks.golang.org/2012/splash.article#TOC_17.] (yes, include
> that last period).
>
> Given the apparent simplicity of the changes needed to keep one's
> Haskell code up to snuff and the strong typing inherent in Haskell
> code, would it not be possible to create something similar? If there
> is a tool that moves (most of) one's code from Haskell version n to
> n+1 then making breaking changes would be even less of an issue.
>
> Just an idea, I have no clue about its feasibility...

I mentioned the same on #haskell today. Something like Coccinelle
(http://coccinelle.lip6.fr) "semantic patches" could be really useful to
automate (some) API & language changes. Somewhat like (but better than)
the Python '2to3' tool.

I think some message about a GSoC project regarding an AST-based
refactoring tool was posted to this list. That might be a useful
building block for such tool?

Imagine one day whenever a new HP release is made, GitHub pull-requests
are created automatically based on a automatically-generated patch
verified through a compilation&test-cycle on TravisCI for GH-hosted
packages published on Hackage.

Nicolas


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

Re: Backward compatibility

Niklas Hambüchen
On 04/05/13 01:52, Nicolas Trangez wrote:

> On Fri, 2013-05-03 at 10:40 -0700, Hilco Wijbenga wrote:
>> Given the apparent simplicity of the changes needed to keep one's
>> Haskell code up to snuff and the strong typing inherent in Haskell
>> code, would it not be possible to create something similar? If there
>> is a tool that moves (most of) one's code from Haskell version n to
>> n+1 then making breaking changes would be even less of an issue.
>>
>> Just an idea, I have no clue about its feasibility...
>
> I mentioned the same on #haskell today. Something like Coccinelle
> (http://coccinelle.lip6.fr) "semantic patches" could be really useful to
> automate (some) API & language changes. Somewhat like (but better than)
> the Python '2to3' tool.
>
> I think some message about a GSoC project regarding an AST-based
> refactoring tool was posted to this list. That might be a useful
> building block for such tool?

Yes, I proposed that.

It seems to be already in the making by some, but seems to need more
concentrated community effort/support/contribution.

It would also *hugely* reduce the time spent on what my next email is about.

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

Re: Backward compatibility

Niklas Hambüchen
In reply to this post by Adrian May
All right, here you go: https://github.com/nh2/WashNGo

https://github.com/nh2/WashNGo/commit/08010e7404219470a827f3e4172004f9d2aedc29

Took me around 75 minutes.

Think about it a bit:

I just ported thirty thousand lines of code that I have never seen
before and that has bit-rotted for over six years to the latest
programming environment.

It being Haskell, I am pretty confident it does *exactly* what it's
supposed to do.

I want to see anyone do that with an equivalently sized + outdated Ruby
/ Python project.


On 02/05/13 13:27, Adrian May wrote:
> I just tried to use Flippi. It broke because of the syntax change so I
> tried WASH. I couldn't even install it because of the syntax change. I
> persisted for a while but gave up because getPackageId doesn't exist in
> any form at all anymore. This was only the install script: what would
> WASH itself have in store for me to get my brain around?

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

Re: Backward compatibility

Adrian May
Well I'm enormously grateful to Niklas for fixing those two things. Simon was right that people are very supportive around here. 

Even though I've been advised against WASH already, it seems important to fix that stuff because it's a liability to Haskell to have broken code kicking around where people might find it. I found flippi just by googling for "haskell wiki engine", in fact I think I was pointed there by wikipedia, and there's nothing on the WASH page to warn anybody. So it's great that Niklas fixed it, thereby preventing impressionable people from having a Rails-day like I did.

But is it correct to extrapolate from the fact that people like you can fix it in 5 and 75 minutes, that everybody else can and that's how industry should calculate its maintenance costs? You guys all know a hell of a lot more about Haskell than I do, but I've been playing with it for a few years now, and I never met anybody independently of Haskell who had even heard of it. 

On 3 May 2013 16:44, Ertugrul Söylemez <[hidden email]> wrote:
If it's your decision, you shouldn't be afraid to make it.  You are the
manager of your team!  Don't let yourself be stabbed by another manager.
Recognize that your choice can lead to higher productivity

Middle management in big companies isn't really about minimising maintenance costs, or even getting anything done. It's about building yourself a botnet of colleagues you can trigger to DDoS one another. You don't need much of a trigger: it's the timing that counts: every bot has to perceive the attack to be already underway and successful by the time you trigger them. Then they'll be grateful that you pointed out something they hadn't noticed before, after all, they wouldn't want to screw up with any other bot. The main reason you'd want to DDoS somebody at all is so that all your bots know the network is operational and that they're safer on the inside. That's why most managers spend more time trying to sabotage one another's projects than doing anything useful themselves, and why the most useless of them always wind up at the top.

It's in that context that I'd like you to try and imagine why my priorities might be different from yours. Please don't say that it's my culture's fault. That would be true, but it wouldn't be helpful because if nothing improved in the last 3000 years it probably won't in the next 3000 either.

Whether a manager wants to behave in this Machiavellian way or not, he'd better assume that he's surrounded by botnets that want him on the inside. If he has any aspirations to keep both his job and a modicum of autonomy, he wouldn't want to give them a trigger on a plate. Backward compatibility is a very potent trigger because everybody knows what it means, and it would be potty to imagine you could convert somebody else's botnet into mutinying against the controller with the notion that backward compatibility doesn't matter. Referential transparency is not a very good defence because nobody knows what you're talking about.

Take a guess how fast I can hire programmers here in Taiwan: about once every 3 months. I turn down 90% of applicants cos I know they'd waste more of my time than they save. I'm talking about the kind of people who can spend a whole week wondering why the bug never changes before I come along and ask them if they're even editing the right file. It's not obvious to people in my position why writing a coding standard that says "nobody is allowed to write anything that a monkey wouldn't understand" is a bad idea.

Hopefully I've now shown that I must be nuts to be interested in Haskell at all. So why am I? Well I described my OP as a lullaby, not a rant. If you want to hear a rant, ask me what I think of imperative programming. Last time I saw an 8 million line project land in the bin, I could have said that I'd told them so 2 years earlier, but instead, I actually shed tears for all the developers who'd been stuck in that office til 11 every night, chasing bugs around in circles that could never be fixed. For the guy who was publicly humiliated for giving a presentation about how to track a bug down through all that spaghetti and then fix it by wrapping "if (p!=NULL)" around the crash instead of wondering what was null or why, when in all fairness, that was the only thing any of them ever did. For that whole quirky culture that refers to bugs by a six-digit ID beginning with 3, and that doesn't lose it's cool even after two months unable to even build the thing, followed by another two when it can't make it to the idle screen without crashing. Of course I knew it would be pointless to ask those self-satisfied architects if they'd finally figured out that it wasn't smart to riddle the build system with cyclic dependencies so the testers didn't even know what they were testing, or to chop the whole thing into a guzzillion separate pseudo-processes so every debugger would spend 90% of his time trying to single-step over those asynchronous interfaces. Did they fail? I'm afraid not. The controllers just rounded up their best bots, found another venture capitalist and proudly boasted about how they'd turned 2 million lines into 8 in only two years. How would the VC know to ask why they needed all those lines if no new features were coming out? 

You thought I was pissed off with Haskell? Oh no. That's not what I'm pissed off about.

But I'm still not crazy enough to start a project at work in Haskell: what I'm debating is whether or not to give people a few presentations and a few hours in the week to study your language in the hope that it will improve their imperative code, plant a seed of suspicion that OO might not be the last word, nurture a healthy fear of data, and perhaps one day take over Haskell stuff that I might foolishly dare to write for the company. This language has got an important message for the world, and the reason I'm trying to tell you guys this stuff is that I want it to get through.

Once they sent a security consultant to lecture us about how to avoid writing vulnerabilities through which people could jailbreak their phones from the network. Towards the end of the day when he'd explained how buffer overflows work, he dropped "using a language other than C/C++" into his list of possible remedies. The whole room was immediately filled with uproarious laughter. I have to go at this gently and ensure that the carrot looks bigger than the stick at all times. And I can't make myself vulnerable to easy pot-shots about backward compatibility or anything else. 

So what would their first impression be? They'd be dazzled but scared. ***Please bear in mind that if I scare a report by making him feel that his job security depends on him learning something new or taking more responsibility, then he's liable to throw a tantrum and plot against me in self defence.*** If most of his colleagues also think I'm crazy to be going on about this offbeat language, then I'm toast. At the beginning they'll spend a lot of time feeling humiliated by it always saying No, and there'll be a strong tendency for them to say:
 
    "It's not my fault: none of the examples on the web work either, and not even Adrian can make them work." 

At that point I look like an idiot and Haskell at that company will be caught in the crossfire of my assassination. That's why breaking old code is best avoided (as long as it doesn't conflict with progress) especially in a world where lots of unmaintained stuff is still on the web. 

That's why I'm very grateful to Niklas for fixing that prehistoric code. And why I think it's better only to deprecate things if you really need to. Does that make me ultra-conservative? Where I work, conservative is when you're still worried about how long it takes to dereference a virtual.

Do you finally see where I'm coming from? If you want this language to catch on, you have to think about programming the people, not just the computers. You could also just soldier on as a brilliant microculture until you get swamped by something like F# that's not even where you were in 98, and one day people will tell you "Haskell? Monads? That's not what I mean by FP. FP is something like F#." (Apologies to anybody who works on F#: my issue with it is that nobody I know is likely to figure out the functional way to do something if it's that easy for them to bottle out and do it the imperative way.)

Maybe that is the new plan. Maybe Haskell already gave up wanting to be anything but a research platform. Maybe you guys calculate that if I really want to push FP I should be pushing some hybrid like F# or Ocaml. Remember how C++ succeeded where Smalltalk failed because it sneaked the changes under the table instead of calling for revolution. If that is the plan then I'd appreciate somebody putting me in the picture. Otherwise, please try to understand that the problems I'm up against are not about whether Num is derived from Eq or whatever.

mfG,
Adrian.
 



On 4 May 2013 02:33, Niklas Hambüchen <[hidden email]> wrote:
All right, here you go: https://github.com/nh2/WashNGo

https://github.com/nh2/WashNGo/commit/08010e7404219470a827f3e4172004f9d2aedc29

Took me around 75 minutes.

Think about it a bit:

I just ported thirty thousand lines of code that I have never seen
before and that has bit-rotted for over six years to the latest
programming environment.

It being Haskell, I am pretty confident it does *exactly* what it's
supposed to do.

I want to see anyone do that with an equivalently sized + outdated Ruby
/ Python project.


On 02/05/13 13:27, Adrian May wrote:
> I just tried to use Flippi. It broke because of the syntax change so I
> tried WASH. I couldn't even install it because of the syntax change. I
> persisted for a while but gave up because getPackageId doesn't exist in
> any form at all anymore. This was only the install script: what would
> WASH itself have in store for me to get my brain around?


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

Re: Backward compatibility

Niklas Hambüchen
I think you missed my point.

My point was to show that what you understand as "backward
compatibility" here is totally delivered by Haskell and its environment,
and how easy it is to be "conservative" (where "keeping it running" as
it is is only a matter of renaming a few imports).

> it seems important to fix that stuff

It is not.

I did not "fix" Flippi nor WASH; it is the same unmaintained code that
you should not use. If there's a security hole or it just doesn't work,
nobody will fix it, nobody will even mention it or care, because it is
clear that this is code from the past.

> it's a liability to Haskell to have broken
> code kicking around where people might find it.

There really is no reason to delete open-source code.

> and there's nothing on the WASH page to warn anybody.

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

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.

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.

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

I believe you that that's how it goes in many large organizations.

Nobody is forcing you to be part of that.

There are a lot of places that would care about you trying to get
software development right (it sounds like you do) and, surprise, the
chances that they use something like Haskell are much higher. Not
because they like research platforms, but because it's one of the
reasons for their success.

On 04/05/13 16:06, Adrian May wrote:

> Even though I've been advised against WASH already, it seems important
> to fix that stuff because it's a liability to Haskell to have broken
> code kicking around where people might find it. I found flippi just by
> googling for "haskell wiki engine", in fact I think I was pointed there
> by wikipedia, and there's nothing on the WASH page to warn anybody. So
> it's great that Niklas fixed it, thereby preventing impressionable
> people from having a Rails-day like I did.
>
> But is it correct to extrapolate from the fact that people like you can
> fix it in 5 and 75 minutes, that everybody else can and that's how
> industry should calculate its maintenance costs? You guys all know a
> hell of a lot more about Haskell than I do, but I've been playing with
> it for a few years now, and I never met anybody independently of Haskell
> who had even heard of it.
>
> On 3 May 2013 16:44, Ertugrul Söylemez <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     If it's your decision, you shouldn't be afraid to make it.  You are the
>     manager of your team!  Don't let yourself be stabbed by another manager.
>     Recognize that your choice can lead to higher productivity
>
>
> Middle management in big companies isn't really about minimising
> maintenance costs, or even getting anything done. It's about
> building yourself a botnet of colleagues you can trigger to DDoS one
> another. You don't need much of a trigger: it's the timing that counts:
> every bot has to perceive the attack to be already underway and
> successful by the time you trigger them. Then they'll be grateful that
> you pointed out something they hadn't noticed before, after all, they
> wouldn't want to screw up with any other bot. The main reason you'd want
> to DDoS somebody at all is so that all your bots know the network is
> operational and that they're safer on the inside. That's why most
> managers spend more time trying to sabotage one another's projects than
> doing anything useful themselves, and why the most useless of them
> always wind up at the top.
>
> It's in that context that I'd like you to try and imagine why my
> priorities might be different from yours. Please don't say that it's my
> culture's fault. That would be true, but it wouldn't be helpful because
> if nothing improved in the last 3000 years it probably won't in the next
> 3000 either.
>
> Whether a manager wants to behave in this Machiavellian way or not, he'd
> better assume that he's surrounded by botnets that want him on
> the inside. If he has any aspirations to keep both his job and a modicum
> of autonomy, he wouldn't want to give them a trigger on a plate.
> Backward compatibility is a very potent trigger because everybody knows
> what it means, and it would be potty to imagine you could convert
> somebody else's botnet into mutinying against the controller with the
> notion that backward compatibility doesn't matter. Referential
> transparency is not a very good defence because nobody knows what you're
> talking about.
>
> Take a guess how fast I can hire programmers here in Taiwan: about once
> every 3 months. I turn down 90% of applicants cos I know they'd waste
> more of my time than they save. I'm talking about the kind of people who
> can spend a whole week wondering why the bug never changes before I come
> along and ask them if they're even editing the right file. It's not
> obvious to people in my position why writing a coding standard that says
> "nobody is allowed to write anything that a monkey wouldn't understand"
> is a bad idea.
>
> Hopefully I've now shown that I must be nuts to be interested in Haskell
> at all. So why am I? Well I described my OP as a lullaby, not a rant. If
> you want to hear a rant, ask me what I think of imperative programming.
> Last time I saw an 8 million line project land in the bin, I could have
> said that I'd told them so 2 years earlier, but instead, I actually shed
> tears for all the developers who'd been stuck in that office til 11
> every night, chasing bugs around in circles that could never be fixed.
> For the guy who was publicly humiliated for giving a presentation about
> how to track a bug down through all that spaghetti and then fix it by
> wrapping "if (p!=NULL)" around the crash instead of wondering what was
> null or why, when in all fairness, that was the only thing any of them
> ever did. For that whole quirky culture that refers to bugs by a
> six-digit ID beginning with 3, and that doesn't lose it's cool even
> after two months unable to even build the thing, followed by another two
> when it can't make it to the idle screen without crashing. Of course I
> knew it would be pointless to ask those self-satisfied architects if
> they'd finally figured out that it wasn't smart to riddle the build
> system with cyclic dependencies so the testers didn't even know what
> they were testing, or to chop the whole thing into a guzzillion separate
> pseudo-processes so every debugger would spend 90% of his time trying to
> single-step over those asynchronous interfaces. Did they fail? I'm
> afraid not. The controllers just rounded up their best bots, found
> another venture capitalist and proudly boasted about how they'd turned 2
> million lines into 8 in only two years. How would the VC know to ask why
> they needed all those lines if no new features were coming out?
>
> You thought I was pissed off with Haskell? Oh no. That's not what I'm
> pissed off about.
>
> But I'm still not crazy enough to start a project at work in Haskell:
> what I'm debating is whether or not to give people a few presentations
> and a few hours in the week to study your language in the hope that it
> will improve their imperative code, plant a seed of suspicion that OO
> might not be the last word, nurture a healthy fear of data, and perhaps
> one day take over Haskell stuff that I might foolishly dare to write for
> the company. This language has got an important message for the world,
> and the reason I'm trying to tell you guys this stuff is that I want it
> to get through.
>
> Once they sent a security consultant to lecture us about how to avoid
> writing vulnerabilities through which people could jailbreak their
> phones from the network. Towards the end of the day when he'd explained
> how buffer overflows work, he dropped "using a language other than
> C/C++" into his list of possible remedies. The whole room was
> immediately filled with uproarious laughter. I have to go at this gently
> and ensure that the carrot looks bigger than the stick at all times. And
> I can't make myself vulnerable to easy pot-shots about backward
> compatibility or anything else.
>
> So what would their first impression be? They'd be dazzled but scared.
> ***Please bear in mind that if I scare a report by making him feel that
> his job security depends on him learning something new or taking more
> responsibility, then he's liable to throw a tantrum and plot against me
> in self defence.*** If most of his colleagues also think I'm crazy to be
> going on about this offbeat language, then I'm toast. At the beginning
> they'll spend a lot of time feeling humiliated by it always saying No,
> and there'll be a strong tendency for them to say:
>  
>     "It's not my fault: none of the examples on the web work either, and
> not even Adrian can make them work."
>
> At that point I look like an idiot and Haskell at that company will be
> caught in the crossfire of my assassination. That's why breaking old
> code is best avoided (as long as it doesn't conflict with progress)
> especially in a world where lots of unmaintained stuff is still on the web.
>
> That's why I'm very grateful to Niklas for fixing that prehistoric code.
> And why I think it's better only to deprecate things if you really need
> to. Does that make me ultra-conservative? Where I work, conservative is
> when you're still worried about how long it takes to dereference a virtual.
>
> Do you finally see where I'm coming from? If you want this language to
> catch on, you have to think about programming the people, not just the
> computers. You could also just soldier on as a brilliant microculture
> until you get swamped by something like F# that's not even where you
> were in 98, and one day people will tell you "Haskell? Monads? That's
> not what I mean by FP. FP is something like F#." (Apologies to anybody
> who works on F#: my issue with it is that nobody I know is likely to
> figure out the functional way to do something if it's that easy for them
> to bottle out and do it the imperative way.)
>
> Maybe that is the new plan. Maybe Haskell already gave up wanting to be
> anything but a research platform. Maybe you guys calculate that if I
> really want to push FP I should be pushing some hybrid like F# or Ocaml.
> Remember how C++ succeeded where Smalltalk failed because it sneaked the
> changes under the table instead of calling for revolution. If that is
> the plan then I'd appreciate somebody putting me in the picture.
> Otherwise, please try to understand that the problems I'm up against are
> not about whether Num is derived from Eq or whatever.
>
> mfG,
> Adrian.
>  
>
>
>
> On 4 May 2013 02:33, Niklas Hambüchen <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     All right, here you go: https://github.com/nh2/WashNGo
>
>     https://github.com/nh2/WashNGo/commit/08010e7404219470a827f3e4172004f9d2aedc29
>
>     Took me around 75 minutes.
>
>     Think about it a bit:
>
>     I just ported thirty thousand lines of code that I have never seen
>     before and that has bit-rotted for over six years to the latest
>     programming environment.
>
>     It being Haskell, I am pretty confident it does *exactly* what it's
>     supposed to do.
>
>     I want to see anyone do that with an equivalently sized + outdated Ruby
>     / Python project.
>
>
>     On 02/05/13 13:27, Adrian May wrote:
>     > I just tried to use Flippi. It broke because of the syntax change so I
>     > tried WASH. I couldn't even install it because of the syntax change. I
>     > persisted for a while but gave up because getPackageId doesn't
>     exist in
>     > any form at all anymore. This was only the install script: what would
>     > WASH itself have in store for me to get my brain around?
>
>

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

Re: Backward compatibility

Ben Doyle
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
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility

Carter Schonwald

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
12345