How we secretly introduced Haskell and got away with it • Hacker News Board

Re: How we secretly introduced Haskell and got away with it

#171

Post by pekk » Sat, Mar 04, 2017, 1:08 AM UTC

jwatte wrote: post #165

pharrington wrote: post #97

Earlier quoted context omitted.

I'm not sure what you're getting at. He's saying Haskell's type safety makes impossible the bug that was in his JavaScript project. As far as I can tell, it's impossible to write a type safe system in pure JavaScript. edit: To clarify this thought a bit, obviously you can transpile code in a type safe language to JavaScript. At the abstraction level of the code written, the project is type safe. The generated JavaScr…

If Haskell is better than Python, then writing the first version in Haskell and the second version in Python should yield two versions that are closer in quality than if you did the reverse order. Assuming you can measure quality, this is a totally valid hypothesis to test!

Additional hypothesis: the result of this test depends strongly on which one you are more familiar with and which one you prefer. If I hate writing Cobol, I'm going to spend that part of the test pining for the other language and not using whatever the up-to-date idioms are for making Cobol manageable, but just fighting Cobol until I can switch to the language I really wanted to use.

So, anyone doing this should consider trying to get a sample of people who are more or less indifferent between the options, so they don't sabotage the test

Re: How we secretly introduced Haskell and got away with it

#172

Post by q3r3qr3q » Sat, Mar 04, 2017, 1:08 AM UTC

pekk wrote: post #169

cmrdporcupine wrote: post #112

Earlier quoted context omitted.

And they inevitably fail to mention the pissed-off product or QA manager or customer who realizes their favourite feature or corner case or bugfix is missing from the rewritten version because the developer didn't understand or notice that aspect of the original.

Instead of blaming the developers every time a feature is missing, consider who is setting the priorities for development. In places where developers are being paid for their work, this is rarely done by the developers themselves. Always interesting to see how much end users specifically blame developers for whatever's going on, I guess without understanding that there are usually all kinds of managers who may not un…

Now someone has to sound exasperated at everyone jumping to blame managers.

Re: How we secretly introduced Haskell and got away with it

#173

Post by pekk » Sat, Mar 04, 2017, 1:12 AM UTC

hueving wrote: post #71

mightybyte wrote: post #31

Earlier quoted context omitted.

Not really. Even then you'll get criticism that the teams were more skilled in one language, or that they didn't use the best practices of the other language. Also, even if you could manage to normalize for all these variables. You're still only going to be comparing the cost to create the project. You're never going to get someone to maintain the two projects side-by-side for years and compare the total maintenance…

Doing a rewrite in a different language and justifying language choice by a successful outcome of the rewrite is grasping at straws to justify the language change. Every time I've been involved in a rewrite, including ones using the same language before/after , the outcome has been good. The act of doing a full rewrite is where the benefit comes from, it's hard to separate that from a language switch.

On a political level, it may often be easier to justify a rewrite which switches languages to take advantage of bullet point features (promotional claims like 10x faster, totally secure, no more bugs, etc.) than it is to simply ask for time to do a rewrite, which will make many average managers start fantasizing about firing you. If you write a blog post afterward, that seems to make the company look good.

Re: How we secretly introduced Haskell and got away with it

#174

Post by scriptkiddy » Sat, Mar 04, 2017, 1:16 AM UTC

Lev1a wrote: post #82

scriptkiddy wrote: post #67

Earlier quoted context omitted.

>Could you give an example of what "system libraries" would pose a problem in my example of using Rust with cargo? Specifically things like xorg libs, libmpeg, libsdl, and such. Not that Rust would have a problem interfacing with them, just that they would need to be present regardless of whether or not someone was just trying to run a distributed binary. Agreed that you wouldn't need a VM like CPython or the JVM. Ho…

> Specifically things like xorg libs, libmpeg, libsdl, and such. Not that Rust would have a problem interfacing with them, just that they would need to be present regardless of whether or not someone was just trying to run a distributed binary. That's why stuff like that is AFAIK usually either distributed with the binary or is absolutely required to have present on the system, regardless of the PL, if you want to/ca…

I think I may have misunderstood your point after re-reading.

I thought you were implying that compiled binaries do not have dependencies. Now I can see that is not the case.

Re: How we secretly introduced Haskell and got away with it

#175

Post by zeptomu » Sat, Mar 04, 2017, 1:27 AM UTC

saosebastiao wrote: post #168

jwatte wrote: post #164

Earlier quoted context omitted.

Aggregations and interfaces cover 99%of what you need. Implementation inheritance and virtual variation points create too tight coupling to be workable for evolving systems.

Maybe 99% of what you need, but more like 70% of what I need. I'm not sure what you mean by aggregations, but I design industrial simulations relatively frequently and I've seen the suggestions for replacing inheritance with composed typeclasses and they are not even close to a true alternative. Rust's current troubles with GUI development would suggest the same pattern there too.

Can you elaborate on that? What's an industrial simulation (compared to a "regular" simulation) and why do you like to solve it with inheritance?

Re: How we secretly introduced Haskell and got away with it

#176

Post by dragonwriter » Sat, Mar 04, 2017, 1:56 AM UTC

pekk wrote: post #170

goatlover wrote: post #134

Earlier quoted context omitted.

But then you end up growing your taxonomy ad-hoc. Also, Python does multiple inheritance sanely, and so does Eiffel.

Python might do nearly as well as any language could do with multiple inheritance, but "sanely" is relative, like finding the sanest way to drive two cars at once.

Multiple inheritance is perfectly sane, what isn't (or at least is less) sane is implicit invocation of methods defined in interfaces (and inheritance from a parent class is, among other things, taking an interface with a default implementation.)

Unfortunately, explicit interfaces were a very late idea (at least in terms of implementation in a major language, not sure if the idea was around earlier) in OOP implementation, and wasn't on v1 of any major language as a core approach, so we've got a bunch of languages where we accept multiple inheritance being messy or we don't have MI at all to avoid it being messy.

But if you had exclusively explicit access to interface (including inherited) methods, MI would be clean.

Re: How we secretly introduced Haskell and got away with it

#177

Post by kabdib » Sat, Mar 04, 2017, 2:02 AM UTC

curtis wrote: post #59

kabdib wrote: post #49

Earlier quoted context omitted.

Given the awfulness of so many OOP-based frameworks that I encountered in the 90s, I began to seriously consider that OOP wasn't a better paradigm for most things and that instead it was worse , and simply caused people to rewrite code to the point that it overcame the procrustean bed of inheritance and whatever other tools the language of choice was providing.

My personal suspicion is that the problem there wasn't OOP, it was frameworks.

Yeah, pretty much everyone and his brother had a framework:

- Apple, MacApp

- Microsoft: MFC, and others

- Borland: I forget what they called their stuff

- Anyone remember Taligent? Apple, HP and IBM, all getting together in a money-burning party...

- NeXT / Apple revival: NextStep / OpenStep, etc.

- Any number of minor players, including folks with Honest to Goodness Smalltalk implementations (none of which have survived to this day, I believe)

- Java stuff that I have mercifully forgotten

... they were nearly all crazy, and nothing was portable. So much for the promise of OOP :-)

Re: How we secretly introduced Haskell and got away with it

#178

Post by saosebastiao » Sat, Mar 04, 2017, 2:46 AM UTC

zeptomu wrote: post #175

saosebastiao wrote: post #168

Earlier quoted context omitted.

Maybe 99% of what you need, but more like 70% of what I need. I'm not sure what you mean by aggregations, but I design industrial simulations relatively frequently and I've seen the suggestions for replacing inheritance with composed typeclasses and they are not even close to a true alternative. Rust's current troubles with GUI development would suggest the same pattern there too.

Can you elaborate on that? What's an industrial simulation (compared to a "regular" simulation) and why do you like to solve it with inheritance?

An industrial simulation, in my context, is modeling the stateful flow of things through industrial processes. It typically involves millions of instances of thousands of types. There are typically much fewer very well defined processes, most of which would be trivial to implement with a simple impl trait with default methods. But some require stateful members in order to implement a default behavior, but Rust traits do not have fields/members, just functions.

Rust traits and Scala traits (or abstract classes) are more or less equivalent with this one exception. I was just pointed to a proposal that would allow for this in Rust, but it is not yet implemented [0]. Essentially, you would be able to define type members, and then "link" them to a member of the struct/enum that is being "impl"-ed. While ergonomically not quite the same as scala, it is effectively the same as inheriting an abstract class with a constructor parameter.

[0] https://github.com/rust-lang/rfcs/pull/1546

Re: How we secretly introduced Haskell and got away with it

#179

Post by daxfohl » Sat, Mar 04, 2017, 2:57 AM UTC

chrisdone wrote: post #152

daxfohl wrote: post #38

I'm just starting with Haskell and PureScript. So far I'm liking the latter better. It solves a few of their gripes with respect to strings, laziness and records, plus has a more granular/extendable effects system and cleans up the standard typeclass hierarchy. Also `head []` doesn't crash. Of course Haskell is more mature, has support for multithreading and STM, compiles to native, so it's more performant. But PureS…

I think PureScript should catch on. The runtime performance story is much more predictable than Haskell, it integrates trivially with the most valuable target platform: JS, it has small output, fixes the warts of Haskell and yet is still pure. Aside from apps at work, I made some simple physics demos with it http://chrisdone.com/toys/ Perfomance seems good.

While I really like it, I think it needs a more familiar syntax (to mainstream devs) to be anything more than a niche thing. I'd like to see something in the middle kind of go the typescript route, where valid+pure JS is valid WhateverScript, and with generally JS-y syntax, but with PureScript's additional features and effects systems.

It may end up really ugly though: how would you define operators while preserving JS semantics (e.g. no currying)?

Re: How we secretly introduced Haskell and got away with it

#180

Post by daxfohl » Sat, Mar 04, 2017, 3:10 AM UTC

dualogy wrote: post #56

davedx wrote: post #53

Good luck with hiring!

Shouldn't be hard.. Haskell to me so far feels like an ecosystem with way fewer jobs / freelance gigs than there are eager-to-go-commercial enthusiasts hacking away in their spare time..

That is confirmed here: https://stackoverflow.blog/2017/02/07/what-programming-langu...