Type Driven Domain Modelling, Part 2: Evolving Models with F# • Hacker News Board

Re: Type Driven Domain Modelling, Part 2: Evolving Models with F#

#31

Post by yawaramin » Sat, Feb 04, 2017, 12:57 PM UTC

aryehof wrote: post #15

yawaramin wrote: post #11

Earlier quoted context omitted.

The Tezos project is writing a new safety-focused blockchain implementation in OCaml. Would you classify that as a representational system or otherwise?

I don't know anything about Tezos or blockchain implementations sorry, but I suspect that it is primarily focused on the processing of data, rather than the modeling of the concepts in a domain – a specific area of activity or knowledge. As such it is more of a Type 2B project - "Information, data science and analysis projects, systems often focused on the processing of data." ( http://aryehoffman.com/entry/project-t…

From the description, 2(b) sounds like a strict superset of 1(a). In fact, it sounds like the most generic possible description of an IT system. I mean, what computer system is not focused on the processing of data?

Anyway, I asked you about a blockchain technology because it fits perfectly into your description of a representational technology. In fact it's a breakthrough in the space, and I'm finding it hard to believe that an IT professional doesn't have even a basic idea about about it.

Re: Type Driven Domain Modelling, Part 2: Evolving Models with F#

#32

Post by lucasmreis » Sat, Feb 04, 2017, 1:28 PM UTC

cmoscoso wrote: post #22

fowlerpower wrote: post #2

F# is a beautiful language. You always want to use the right tool for the job but honestly F# is so right for so many jobs. I know a lot of people don't want to hear this but these types of languages, functional first, are the future of our industry. (In the sense that in the 2000s Java like laguanges were the future of our industry). I might be reaching here, but in my opinion, these are the right languages for the…

I agree with functional first for backend programs. I don't see functional programming become popular on the front-end thought.

I disagree too. Frontend is getting more complex each day, and I find that functional programming languages help a lot with large projects. Frontend SPA's are crying for help with the exploding complexity :)

Re: Type Driven Domain Modelling, Part 2: Evolving Models with F#

#33

Post by lucasmreis » Sat, Feb 04, 2017, 1:34 PM UTC

daxfohl wrote: post #4

I call this RSLDD: Red Squiggly Line Driven Development.

Amazing - I'm gonna use this in the future :)

Re: Type Driven Domain Modelling, Part 2: Evolving Models with F#

#34

Post by lucasmreis » Sat, Feb 04, 2017, 1:36 PM UTC

kough wrote: post #3

I think there's a typo in the createQty function: shouldn't it return (uint16 0) if n is less than 0, not greater? Otherwise, great article. This is exactly how I learned to program with Scheme: mosel the domain carefully, slowly building up helper functions, and conposing at the end.

Thank you! I actually just removed createQty from the code. not only it had a typo, it was not being used anywhere beside the tests.

And, as some commenter on Disqus said, probably the right thing to do would be returning an Qty option from the function, and treating it properly.

I have no experience with Scheme, but already worked with Clojure - it was actually my "gateway" to functional programming languages, hehe!

Re: Type Driven Domain Modelling, Part 2: Evolving Models with F#

#35

Post by lucasmreis » Sat, Feb 04, 2017, 1:38 PM UTC

pjmlp wrote: post #20

shados wrote: post #6

Earlier quoted context omitted.

Facebook is betting pretty hard on ML via ReasonML (even on the client with BuckleScript), and F# is similar as an ML derivative. We'll hear about these more and more for sure.

Sure, but the majority of companies in the world with IT department, don't have software as business, rather as a cost center for support their actual business. Companies like Facebook aren't what the majority of us works on. So when selling languages to management "look Facebook does it" usually doesn't help at all, what one needs are how that adoption will help those IT costs go down.

From my research and experiments, I think that ML languages help a lot "getting the specs right". That means that you have more confidence that the code does what you want it to do.

I can see a lot of value for that in non-tech companies that correctness is crucial, like finance, insurance, health...

Re: Type Driven Domain Modelling, Part 2: Evolving Models with F#

#36

Post by rjbwork » Sat, Feb 04, 2017, 2:02 PM UTC

rubber_duck wrote: post #16

fowlerpower wrote: post #2

F# is a beautiful language. You always want to use the right tool for the job but honestly F# is so right for so many jobs. I know a lot of people don't want to hear this but these types of languages, functional first, are the future of our industry. (In the sense that in the 2000s Java like laguanges were the future of our industry). I might be reaching here, but in my opinion, these are the right languages for the…

I honestly wish this was true but I doubt it. F# is different enough to have a big curve, and yet the benefits aren't immediately tangible, it's just a bunch of small things that add up - but try selling that to someone. Meanwhile mainstream languages are picking up features from it (eg. C# will eventually have record types and pattern matching). I think languages like this will influence the mainstream but I don't s…

Sorry to keep shilling this, but it seems to keep coming up lately - exhaustive pattern matching library in pure C# https://github.com/Jagged/OneOf - https://www.nuget.org/packages/DiscU

Re: Type Driven Domain Modelling, Part 2: Evolving Models with F#

#37

Post by olavk » Sat, Feb 04, 2017, 2:31 PM UTC

jpalomaki wrote: post #26

twblalock wrote: post #9

Earlier quoted context omitted.

> Respectfully, what is a complex representational system? A database is one example. A database is also global mutable state for the programs that write to it, and that significantly compromises the advantages of using functional programming languages for such programs. You might start with some nice pure functional code, but the database adds massive side effects.

Maybe we should get rid of databases (or limit them to reporting). Back in the days they were mandatory since memory was expensive and you simply had to access stuff from disk and needed something that made it reasonably efficient. Now memory is so cheap and for quite many business applications it would be feasible to keep everything in memory. SSDs with GB/s level read speeds would enable restoring the stuff back to…

Persistent objects does not mean you get rid of the database. It just means the database is a lot harder to query.

Re: Type Driven Domain Modelling, Part 2: Evolving Models with F#

#38

Post by jackmott » Sat, Feb 04, 2017, 2:38 PM UTC

vivainio wrote: post #23

rubber_duck wrote: post #16

Earlier quoted context omitted.

I honestly wish this was true but I doubt it. F# is different enough to have a big curve, and yet the benefits aren't immediately tangible, it's just a bunch of small things that add up - but try selling that to someone. Meanwhile mainstream languages are picking up features from it (eg. C# will eventually have record types and pattern matching). I think languages like this will influence the mainstream but I don't s…

Huh, the benefits are immediately tangible, the biggest one being less code to do the same thing while remaining typesafe. In the meantime, you probably need slightly , but not massively, better developers.

I don't think you need better developers. I've had one college intern so far that I've had work with some F# and she liked it better than C#.

Lots of stuff that is easier to do. Not much that is harder.

Re: Type Driven Domain Modelling, Part 2: Evolving Models with F#

#39

Post by rubber_duck » Sat, Feb 04, 2017, 3:35 PM UTC

jackmott wrote: post #38

vivainio wrote: post #23

Earlier quoted context omitted.

Huh, the benefits are immediately tangible, the biggest one being less code to do the same thing while remaining typesafe. In the meantime, you probably need slightly , but not massively, better developers.

I don't think you need better developers. I've had one college intern so far that I've had work with some F# and she liked it better than C#. Lots of stuff that is easier to do. Not much that is harder.

When you don't know a lot learning something different is actually easier than when you're already proficient in C#. You expect an intern to take x ammount of time before he can be productive, so if he spends it on learning how to do it with F# or C# it won't change the x much. But when you have a senior who knows how to do something with C# he will not want to invest ammount similar to x, even a 1/2 of the time, because he can get it done with what he knows.

Like I said to OP F# doesn't have that "hard sell", it's just a bunch of incremental improvements that end up being a big deal together, but each one on it's own is unimpressive.

Re: Type Driven Domain Modelling, Part 2: Evolving Models with F#

#40

Post by rubber_duck » Sat, Feb 04, 2017, 3:36 PM UTC

vivainio wrote: post #23

rubber_duck wrote: post #16

Earlier quoted context omitted.

I honestly wish this was true but I doubt it. F# is different enough to have a big curve, and yet the benefits aren't immediately tangible, it's just a bunch of small things that add up - but try selling that to someone. Meanwhile mainstream languages are picking up features from it (eg. C# will eventually have record types and pattern matching). I think languages like this will influence the mainstream but I don't s…

Huh, the benefits are immediately tangible, the biggest one being less code to do the same thing while remaining typesafe. In the meantime, you probably need slightly , but not massively, better developers.

The problem is that F# leads to shorter code by being incrementally better all over the place - so every example you show to someone he'll go "oh that's cute but I can do something similar with C#" but when you sum up those "cute tricks" you end up with 1/3 code, much less noise, and easier to maintain code. But it's hard to sell because there's no "one big thing that is 3x better than C#".