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

#61

No I wasn’t “deciding for” anybody. I’m making a prediction for what decisions they’ll make “for themselves” after they’ve played with Haskell – based on having worked amongst programmers and commercial applications for decades. (Commercial applications that typically take the user row-by-row through the database, so will show no benefit from parallelism pace @atravers’ claim for a “mass appeal”. [**])

Yes, that’s what I said Haskell is already doing paragraph 1. You can lead a horse to water, but you can’t force it to drink.

I think this discussion has got to the point of repeating itself.

[**] Just what proportion of the industry is turning out PC games? And don’t they and the players have something useful to do with their lives?

#62

Phew! You’ve gone through all that discussion? Epic!

Yeah thanks, but no: earlier than that. Haskell 98 records was very much at the time seen as a stopgap because they had to put something into the standard. There was already in Hugs Trex 1996 [3 below]/[5 in the 1999 paper]. And Trex continued to be developed in Hugs up til ~2004. The 1999 paper essentially proposed to abandon H98 records and adopt Trex. This would have been a majorly breaking change. But in an era when Haskell users were a tiny ‘ivory tower’, and much more tolerant of breakages.

Errm coming in a thread titled ‘Failed Successfully’ I’m afraid I’ve lost track of the double/triple negatives going on here. Who was pragmatic? Who was purist? Who could have been more pragmatic?

@graninas’ claim was that one side of the debate wanted to implement . to be like OOP; the other side wanted to not implement . because it would be dumbly aping OOP – and only for that reason, like Haskell must keep itself aloof from other languages. My memory (without going through the whole thread) is nobody particularly was suffering from envy or jealousy of OOP. Rather it was: Haskell has got itself in a mess with . [**], can we find a compromise syntax/lexing that allows all existing usages to co-exist (backwards compatibility) and also this new syntactically-specific usage?

@graninas suggested they could have proposed a different operator for field access – except what? Any symbol from user-space might be already taken, so again breaking backwards compatibility.

[3] B. R. Gaster and M. P. Jones. A polymorphic type system for extensible records and variants. Technical Report NOTTCS-TR-96-3, Computer Science, University of Nottingham, November 1996.

[**] because . is just a terrible symbol to use for such a common operator in lambda-calculus as compose °; because . is used for all sorts of purposes, including decimal separator and Module namespacing.

#63

…because modifying a shared resource does requires concurrency, which would help to explain why ParaSail has no global variables. Interestingly, this appeared in one of my searches yesterday:

Lazy Evaluation of Transactions in Database Systems (2014)

…so given the appropriate circumstances, maybe “read-only” transactions can occur in parallel.

But more generally…unless someone discovers a way to use e.g. tungsten carbide as a semiconductor, the future is multicore/threaded, and “straight-track” sequential programs will have to be adapted accordingly.

I’ve mentioned it before: Unicode didn’t exist back in 1987…

#64

Of course I get that. . doesn’t even look much like °. But that’s degree sign (as I used above), which isn’t quite right, should be ∘ at mid-height (pasted from wikip, I’ve no idea how to get it on my keyboard). Then @ at least has a circley thing at mid-height; and is a kinda reserved sym in Haskell but can’t currently appear in expressions.

. is used in math to mean multiply/also dot-product (at mid-height wot also we don’t have in ASCII) or to denote some arbitrary binary operation. Just already too overloaded and too precious to use as a vanilla operator.

#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