[mjburgess]

Where does it go into the management details?

I've skim read through it, and it reads vastly too weak.

They used a blockchain haskell implementation on a fringe blockchain technology, and wrote nearly all their business logic in it.

If I were them, I'd immediately sue whoever built it. This level of gross incompetence reads to me like they were scammed, used as patsies to integrate blockchain into a client.

[blitzar]

It is paid for and reads like it was paid for by ASX - damning enough to say the solution is woeful, but knows that the person paying their consulancy fee green lit the vision to jam a square peg into a round hole.

[mjburgess]

Yes, that's exactly how it reads.

It bends over backwards to say that somehow this approach meets some non-functional reqs. But it cannot plausibly meet any such requirements well. Even praising the "quality" of the haskell code whose job it is to provide a casio-watch level of compute power over an immutable distributed ledger. For $250m!

It would be fascinating if, eg., the Australian gov forced Accenture to release their internal docs. I imagine there are several versions of me with with much much more strongly-worded things to say.

This feels like it would go well in a netflix documentary retrospective on the "blockchain con" and how it duped gen-z and ceos.

[blitzar]

The bit I never understand, and these projects crop up all the time - for 250mil ... seed a company that you 100% own to build the solution.

Or if you have to pay 100mil for the drop in already complete solution (which sounds insanely expensive).

[mjburgess]

When you outsource dev, you also outsource responsibility.

Much of what board members do is play games to keep themselves in power.

[blitzar]

Major IT projects are a graveyard for executives, anyone who could reasonably succeed knows they are destined to fail, and they fail so often that big co's now have so much legacy chewing-gum holding together their systems that implementing any system is destined to fail.

The most likely to work solution - rip out everything in the company and start from scratch. Short of that you are looking at - $50mil to modernise with a drop in (fully functioning) component in a 2 week install + 5 years and $100mil to write translation layers to all the other systems which will still fail on edge cases.

Every now and then the executive that believes in sunshine, rainbows and unicorns comes along, slaps down a stupid budget and tries, with good intentions I might add. They however, are predisposed to buy into the people and vendor that sell magic beans. And they cycle continues...

[mrjin]

It was never about outsourcing.

[mrjin]

If you interpret it from a different angle, it would be much clearer.

1. Those made the decisions are smart, really really smart people. If they were dumb, there is no way they can get to where they are now. So if the decisions look questionable, they probably are indeed questionable. But that does not mean they made a mistake. Smart people don't do obvious stupid moves, if they do, there must be some reasons we don't know.

2. If the budget is not used, at best it lapses or worse will be used by someone else. So do whatever they can if they have nothing better to do with it.

3. If you do something for someone-else with someone-else's money, neither the price nor the quality would be much of your concern.

4. After handling meat, you know, there is oil on your hands.

Put all that together...

[threeseed]

> They used a blockchain haskell implementation

CHESS Replacement Application code consists of Daml, Scala, and Haskell like Daml with ~87% of the code in Daml/Haskell like Daml and 17% in Scala.

So not actually Haskell.

[carterschonwald]

Yeah. I’m pretty familiar with the history of their tech, and the problems with DAML and how they architected everything predate the surface syntax being Haskell.

Source: I was the evaluator of DAML for Jpmorgan.

The way daml is setup makes it more of a weird sibling of GRPC for stateful resource protocols. But where you have to write your own db and interpreter tooling to ingest the commands if you want all the usual nice things you’d expect from a database

[scrumper]

And a very patient and curious evaluator you were too (I was one of your counterparts at DA).

> The way daml is setup makes it more of a weird sibling of GRPC for stateful resource protocols.

Yes, well said. I think that's quite fair. It's wrong to look at it through the lens of Haskell (or any other FP language), it's really a declarative language for describing process flow and actor rights and obligations. Not something you could write a complete program in. A better way to think of it is as a big DSL for controlling state machines; you still need all the machinery around the outside to advance execution, handle IO, trigger events and transitions etc.

It's syntactically similar to Haskell because the people who created it were Haskell heads out of ETH Zürich. That's the only connection.

[carterschonwald]

The intial surface language for the dsl was actually not Haskell! But I think eventually shifted to using ghc as a frontend library?

I’m not sure if I was the most patient of evaluators ;). If I was despite that one of the more patient evaluators, wow!

I kinda view everything in this space from the lens of tools I want to build for myself. Namely a decent transactional db system where the modelling language for datatypes and workflows is a linear logical concurrent functional language with some soundness guarantees. I did build a preliminary version of the core of that at jpmorgan, though for various reasons it never saw the light of day

[scrumper]

> But I think eventually shifted to using ghc as a frontend library?

That's right. It happened fairly quickly, part of the efforts to formally verify the language. I think when you were poking at it was around the time it was changing underneath. But, that was years ago!

> Namely a decent transactional db system where the modelling language for datatypes and workflows is a linear logical concurrent functional language with some soundness guarantees.

I mean that's largely what Daml was trying to do. But of course it lacked the transactional DB system once we tossed out our in-house DLT. The approved answer back then was, deploy it over someone else's blockchain/DLT. Well, we all know about those. So before I moved on I spun up a successful skunkworks effort to integrated it into some relational databases; you'd be surprised what _that_ implementation ended up at the heart of.

Well, patient is maybe not the right word :) You weren't ever a dick though and that put you in a small club. You can draw your own conclusions about the space I'm talking about (Haskellers, JPMorgan, enterprise DLT...)

(I'll ping you separately as I have you at a disadvantage. For various reasons I won't put my name in this thread.)

[carterschonwald]

I assume you remember or heard of the crayons incident then ;)

[mjburgess]

Read "implementation" differently.

I was using it in the sense that Daml is "a haskell", in the way that Ocaml is an ML, etc.