My talk "Functional Programming: Failed Successfully" is now available!

#65

Yeah. The database is the global variable – and not just global to your program/all its threads, but global to every other user/program on the network. And updates to it need to be under commitment control, to avoid any other session seeing it in a half-updated state.

Sure, that makes sense where most activity is enquiries. With optimistic locking for updates. We then need all sorts of double-check and rollback strategies in case of the database having changed after my user looked at it but before they entered their update. Did somebody above say "There is nothing “simple” about reassigning state. "?

#66

…yes, I do vaguely recall something being written to that effect - now what did I write again:

So a ParaSail library which does access a shared resource such as a network-wide database cannot use global references/variables for that purpose - it would need to work differently. But however it did work, concurrency would still be required because:

There is nothing “simple” about reassigning state.

…when it’s shared so vastly as a resource on a network, or just shared within a program.

#67

Interesting idea. Let me tell how it works in the real world: the fastest-moving product at the busiest store is also the data point that gets the most enquiries – so by this lazy update strategy will suffer the worst read-latency.

A more realistic strategy is to remove as many of those data integrity ‘promises’ as possible. Typically, to allow the stock-on-hand balance to go negative (even though that makes no sense physically), in the expectation delayed transactions will make up for it. Of course this then needs a human follow-up procedure to enquire on negative on-hands and go physically examine what’s on the shelves.

Amazon, for example will happily sell you some dead trees and take your money with no idea whether it can ship to you – either within their promised delivery time window or ever. They’ll then take their time using your money before giving it back to you because product undeliverable.

In this scenario, enquiries on the fastest-moving product at the busiest store are next to useless. The system might as well make up a number as force all that read-latency. (What I’d record is the date/time of latest reasonably confident stock level; plus a metric for how fast-moving; then guess a number by applying the decay metric over the intervening time interval.)

So a lazy database update might work. But you’ll have to redesign the whole user-facing business logic/manage user expectations. The sequential or otherwise programs are not really the place to tackle it. I don’t see Haskell vs (say) COBOL really having any bearing – to explain which is why I’m going so deep into the weeds on this thread. And I wouldn’t bet my stock control on an application infrastructure for which there’s only a handful of (rather too purist) programmers in the country. That’s why I say

Perhaps I mean: a lot of employers of programmers aren’t going to benefit from their employees grokking Haskell. Especially not if it makes their employees as argumentative as us lot round here (myself included :wink:).

1 Like
#68

…which could also explain the allegedly-slow uptake of Haskell commercially. But this also raises a question about the use of multi-paradigm languages: how do employers of programmers prevent their employees from arguing over which paradigm to use and when?

  • if there’s some generic strategy, perhaps that could be reused in a commercial Haskell setting;

  • if there isn’t…then using an multi-paradigm language risks employees being equally as argumentative, but about paradigms.

(Hmm…this could be another reason why FP was expelled from Python: to avoid this form of distraction.)

#69

For the record: I don’t oppose OO. I just think it’s overused, maybe.

Record dot: My only gripe (even then only softly) is the dot. I would have preferred # (which has been in OCaml for decades). But I concede that, as you pointed out, any other symbol like # has the same ambiguity issue, and if the parser gets it to work then the case is closed. Really, even if one opposes OO, any record syntax cannot have OO meaning unless you also semantically have…

Extensible records: I actually would love that. The one thing in Hugs that I wish GHC had is extensible records. (Then again, I guess the fact that it did not gain traction in the Haskell community is evidence for what you said about the community.)

Existential types: I actually oppose and cringe when people cite the “the existential type anti-pattern” link. Please stop calling it an anti-pattern. OK, if beginners reach for it out of instinct (see what’s wrong with intuition?) for very easy scenerios, then I oppose it and recommend instead simpler ways (in this case low tech and low setup) with just functions and algebraic types. But I am OK if people choose it after knowing their options.

And even that “simpler, low tech, low setup” about functions and algebraic types, I only call that true in Haskell (and SML, Idris, …). Did I say something bad about Python? And yet:

One time I was grading an assignment that asked “code up boolean expressions and an evaluator” in 3 languages: Prolog, Haskell, Python. One student liked Haskell so much, they translated Haskell to Python, i.e.,

if isintance(e, And):
  ...
elif isinstance(e, Or):
  ...
elif ...

I gave it a very low mark. If you use Haskell, play to the strength of Haskell. If you use Python, play to the strength of Python.

I don’t oppose OO. But I oppose the mainstream dogma that OO is the only way to be extensible. The Expression Problem implies that that dogma is false. It is another factor why I’m so skeptical about the mainstream.

#70

Good rule of thumb when a Haskell blog says “never do X” - ignore the directive to never do X. It’s not hard to assess your programs as-is…you don’t need hard rules like that.

A good example of this is the often-linked “What’s wrong with Implicit Params?”

The example given to illustrate the problem is pathological and definitely not a strong enough argument to not use -XImplicitParams.

And the conceptual argument about incoherence feels almost like a non sequitur…incoherence is on the tin and not inherently a bad thing even if it sounds like a bad word.

If I read this advice and just filed away "-XImplicitParams = bad" in my brain, I would have become a worse Haskeller. There are plenty of fun and useful ways to use IPs that I would’ve missed out on.

Why not implicit parameters?
#71

hah i actually loaded up the “counterexample” in ghci and toggled NoMonomorphismRestriction as requested and as expected -Wtype-defaults called the code out as suspicious.

horrific-implicit-params-example.hs:7:24: error: [GHC-18042] [-Wtype-defaults, Werror=type-defaults]
    • Defaulting the type variable ‘t0’ to type ‘Integer’ in the following constraint
        Num t0 arising from the literal ‘456’
    • In the expression: 456
      In the expression: let ?myparam = 456 in result
      In the expression: (result, let ?myparam = 456 in result)

so that is definitely Bad Code but not due to -XImplicitParams.

like i said - evaluate code on its own merits instead of trying to find global rules handed down by blog posts :stuck_out_tongue_winking_eye:

Why not implicit parameters?
#72

Whoa, that was brutal. It looks like there’s no tangible way Haskell and community can keep up to, let aside outrun, mainstream technologies after all, is there?

#73

hm maybe not, but why care? it isn’t a zero sum game where there are winners and losers

PLs are more about being “big enough” to have legs. Haskell currently seems to be “big enough” given its current industrial use & community. Ofc it’s important to nurture things so they are sustainable. But runaway growth in industry to get it on par with things like Go and Kotlin aren’t necessary for success.

#74

In addition, more people are either trying to “add-on” what Haskell already has (as I mentioned earlier) or outright questioning the predominant paradigm used in said mainstream (software) technologies:

(…from this post in another “long and winding” thread.)

Software is now a vital part of society, just like bridges, tunnels, apartment and office blocks, etc. So at some point in the future, software development won’t be enough: software engineering will dominate. But just as the transition from mud-and-grass huts to early structures of wood and stone demanded a more formal understanding of what is required to reliably build those structures (to avoid constantly going back to those mud-and-grass huts!), a similar understanding of what is required to reliably build future software structures will be required.

Of course, software development will continue, just as carpentry and other trades continue as needed…but certain tasks now require the skill set of an structural or civil engineer - being a carpenter alone isn’t enough. Like it or not, this is where “software construction” will eventually go - for certain tasks in the future, being a software developer alone won’t be enough: a software engineer will be required.

So what language/s will those software engineers of the future being using? If only I could reliably predict the future! But considering that engineering large physical structures demands a thorough understanding of mathematics and the properties of the materials being used…engineering large virtual structures will most likely require a similar and equally-as thorough understanding. So languages which at the very least do not wantonly interfere with using basic principles of mathematics and logic would most likely be preferred - languages like Haskell, Prolog, Mercury…and perhaps Verse (or successors thereof) which are declaratively-based, but not entirely divorced from the real world:

(Again, though: if only I could reliably predict the future…)

#75

It’s not brutal, it is what it is. It helps building cool stuff and sharing resources. I know I got people to try and like functional programming. Best we can do is try to make everything as ergonomic as possible. No monads as burritos. No semigrupoids as enchiladas. Show them the signature, show them built examples, and let them go at it. There’s a lot of space between 1 + 1 and space probe DSL. Rather than showing concise hieroglyph soup or the Tardis monad show them how you can just build things you can reason about, this I find invaluable and an incredible asset to peddle to industry: proofs for the masses!

Now try selling a language of the APL family to the masses.

#76

Software engineering is not math, and it will never be. Trying to redefine it in these terms will only increase the distance between haskellers and the rest of the world. The industry generally doesn’t care about Math and correctness as haskellers do. What haskellers call “engineering” is actually not an engineering for others. For others, it’s computer science, which is too pure and idealistic to be taken to the flag. Hoping for the industry to suddenly start caring what haskellers care about is wishful thinking. Even in the span of a decade or two, this will not happen as it didn’t for the last multiple decades. And also, in civil engineering, mathematics is only a tiny fraction. A small percentage of people do it. And a bigger fraction is those armies of dirty working non-engineers and non-mathematicians who move materials, put bricks, mix concrete, and risk their lives on the height. It’s that solid civil construction can’t be done without Math and civil engineering, but software can. And mostly, it is done without the direct participation of Math, even without the direct participation of Software Engineering. History shows that the industry is not interested in pure functional/mathematical utopia. This will not change, and it’s haskellers who need to learn what software engineering is, not vice versa.

Fix: grammar

#77

Software engineering is not math, and it will never be.

Neither is civil or electrical engineering! But they very much rely on mathematics, and that is where software engineering will also have to go.

The industry generally doesn’t care about math and correctness as Haskellers do.

Hence the maxim “try rebooting the system”. Now just imagine if we had to “reboot” all our bridges, tunnels, apartment and office blocks, entire cities, energy grids, et al…

Hoping for the industry to suddenly start caring what Haskellers care about is wishful thinking.

Is it just Haskellers? I would have most Prologgers and and other declarative-language users also care. But just like Haskellers, most of them also realise that it “won’t happen overnight” - just like the transition humans made from building with mud and grass to stone and wood.

History shows that the industry is not interested in pure functional/mathematical utopia. This will not change […]

This aforementioned reference:

having (apparently) stalled since 2015 certainly attests to that! So “what’s the problem?”

…is that all? Interesting:

  • it isn’t just pure functions which have a problem with I/O:

  • and as for trying to determine when some I/O actions can be used purely:

    Using unsafePerformIO safely?

So it’s fortunate for us that Haskell already has such functions (having no visible side effects) by default: otherwise we would probably be still deciding whether or not to include them!

[…] it’s Haskellers who need to learn what software engineering is, not vice versa.

Apart from (maybe?) a few “Haskell natives” (Haskell ver. 1.0 being released in 1990), the majority of us already know what that so-called “software engineering” looks like. And presumably so did John Backus back in 1978…

But all this talk about pragmatism (or the lack thereof) has has me wondering about something for a little while now:

  • does anyone here remember:

    • a physicist,
    • a chemist,
    • an astronomer,
    • or other scientist,
    • or an applied mathematician,

    …asking a pure mathematician to be (more) pragmatic?

  • if so, what was the response by the pure mathematician?

#78

You can define your own # to do field lookup using HasField, can’t you?

#79

First a disclaimer: I am a mathematician, working at a company with “real” (electrical and mechanical) engineers who build stuff we (have to) control.

That’s another problem. There are (for most software) no incentives at all to make “better” software. As long as companies are not (practically) liable for their software, they continue producing what is “good enough”. This isn’t a problem to be solved by “technology”.

Software engineering did and does always rely “on mathematics”.
Talking about “real” engineers: even then, there are specialist engineers (structural engineers for example, when talking about buildings and bridges) which do most of “the math”, while most of the “normal” civil engineers are mainly doing project management stuff. Which btw. isn’t the kind of (“pure”) math you are talking about at all, but the applied math programmers always have used.
And to take your “real” engineering equivalent to software engineering: there are/will be special software engineers that use some kind of formal method, but there always will be an order of magnitude less of them, as they are consulted when their work is needed.

That they don’t care about “the real world”, because it’s ugly. And this is fine “for Haskell” too, but “the pure Haskellers” lose their “right” to talk about real world usage of Haskell or “functional programming” (in the way “Haskell” likes to define it, in a “pure” language - the lazy part is obsolete anyway). So either you are “pure” and don’t care about “engineers” (as in “inpure people, that don’t know shit about what mathematics actually is” - which coincidentally is what most mathematicians think about engineers and computer scientists in general, especially after having to teach them (and architects) maths at university :wink: or they want them to use it, then they have to be pragmatic and cater for their (actual) needs and “speak their language”.

And the biggest irony: Haskell actually is the pragmatical choice of “functional language” for many, because it actually has the most users and a big ecosystem of libraries.

2 Likes
#80

You mean, “Let’s make a revolution”. This will not work. Haskell should not be a political weapon.

This message can be interpreted in two ways.

  1. “Have you seen what they call ‘software engineering’? Complete nonsense. We’ve seen it, we’re fed up with it.”
  2. “We know what software engineering is. And we are the majority in Haskell.”

If most haskellers know what software engineering is, why have we seen a huge demand for software engineering topics in the past decade? Why did the previous director of HF and many other folks say we don’t have enough understanding of software engineering? That the discipline is yet not formed? If we have software engineering, why does the outside world not agree that the materials we have are software engineering? (Hint: most Haskell books are not on comprehensible software engineering as a discipline but rather about non-systematic, non-universal Haskell wisdom, tips, and tricks.)

The outside world feels this implicit intent to revolutionize the field by rejecting and dismantling what was done in the discipline long ago and what was used in practice with huge success. It is no surprise that Haskell has this reputation and is struggling to get a wider adoption. Mainstream software engineering has its merits, and it is equally applicable in Haskell, with certain adaptations.

Fix: grammar

#81

Haskell should not be a political weapon.

A curious choice of words:

…if only they had used Erlang :-b

Correct: that was my intended interpretation. As for that other interpretation:

…here’s some suggested reading:

>_< …software in space.

I completely forgot about that one: software engineering has existed since (at least) the first (re)programmable computer was sent into space. So plenty of mathematical and logical checks needed for that software, to prevent extremely inaccessible hardware from going very astray…

#82

So many my points from the talk have real ground and are quite widespread across FP communities, especially Haskell. These things prevent its wider adoption and are seen by the outside world as misbeliefs or misconceptions. Of course, not the entire community supports everything but I don’t see a general disagreement with these:

  • “OOP is trash”
  • “Math is king”
  • “Mainstream is wrong. What it does is garbage. We know better”
  • “Software Engineering is Math. FP is Math”
  • “We have our oun way, we don’t need to follow rules of the industry”
  • “We’re fine in our small, isolated world, we don’t need Haskell to become more popular”.
  • “The industry is broken, we need to fix it. Haskell is a political weapon”

I recently learned that the purpose of HF is not industry adoption. The goal has changed therefore, and I can see why. The road to popularity goes through 1) recognizing 2) solving social problems (like those misbeliefs and narratives). This meets too much resistance, and needs a very different approach, so it’s easier to focus on technical terms and forget about wide adoption. If that’s so, let’s at least be honest about this. I will then stop trying to convince the outer world to use Haskell

#83

Alexander, this feels a bit like an act of rhetorical vandalism in what has been — with highs and lows — an informative discussion.
There are many interesting bits in your presentation; I am unconvinced advocacy will change much with regards to making Haskell more popular to management.

Part of the HF job is fostering industry adoption, e.g. see Haskell Certification Program. There are many ways to skin this functional cat.

5 Likes
#84

I recently learned that the purpose of HF is not industry adoption.

That’s a bit surprising. Where did you learn this? I’m a member of the board and I have not been aware of any change of purpose. The web site says

“An independent, non-profit organization dedicated to broadening the adoption of Haskell, by supporting its ecosystem of tools, libraries, education, and research.”

This is spelled out a bit more in the HF’s vision statement.

I think it is indeed true that industry adoption is not the sole goal of HF. Hence the slogan “Avoid success-at-all-costs”. For example, I would argue against compromising the conceptual integrity of the language in a single-minded pursuit of popularity.

But that does not mean that adoption is a non-goal – quite the reverse (see above). I personally spend a lot of time and effort working out how to reduce the friction of adoption by increasing stability, and the HF has a Stability Working Group that does nothing else. (Here’s a state of play document.)

I think that we should not characterise this conversation in terms of who is “right” and who is “wrong”. Rather, I would say that Haskell takes a single core idea (statically-typed, purely functional programming) and sees how far it will go. If that’s not what someone wants, then they shouldn’t use Haskell; it’s not that they are right or wrong – just that Haskell isn’t right for them. We should not (and I hope do not) claim that Haskell is Definitely Better than alternatives, that we are right and everyone else is wrong. It’s a grand experiment, to take a single radical idea, stick to it like glue, and see where it takes us. That has been the story of my professional life, starting in around 1984, and it has been a pretty exciting journey. I would love more people to adopt Haskell, but I want them to do so because they love the joy and beauty of the core ideas.

All that said, what we should do, I think, is to bear down relentlessly on accidental friction, things that make mainstream developers get fed up with Haskell, but that are not a consequence of the core vision for Haskell, but rather are simply engineering shortcomings. For example, before cabal it was a huge pain to get libraries distributed and installed; now it is a breeze. Huge win. But the list of accidental frictions is long, and it will continue to take a lot of design and engineering work to sort out.

The road to popularity goes through 1) recognizing 2) solving social problems (like those misbeliefs and narratives).

Even if we were to solve all the sources of technical friction, we would still have the social issues of perception, training, certification, recruitment, and so on. I totally agree that it’s not just technical! I also agree that as a community we are less good at addressing social problems than technical ones.

But different people have different skills, and I’d love to hear more from folk with good ideas for addressing “social friction” rather than just “technical friction”.

thanks for starting this thread

Simon

29 Likes