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

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

#11

Post by yawaramin » Sat, Feb 04, 2017, 7:45 AM UTC

aryehof wrote: post #10

KurtMueller wrote: post #7

Earlier quoted context omitted.

> However, for complex representational systems, including both transactional and continuous systems in business, commerce and industry, other languages and paradigms can remain better suited. Hello. Respectfully, what is a complex representational system? Why are other languages/paradigms better suited over a language like F#?

> "What is a complex representational system" 1. Representational systems a. Transactional systems [1], based around actions that need to be recorded , typically for commercial or legal reasons, like software used to record your purchases, payments, reservations, participation, interactions, obligations, results, commitments, plans, and significant events. b. Non-transactional continuous systems, like software contro…

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

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

#12

Post by yawaramin » Sat, Feb 04, 2017, 7:49 AM UTC

twblalock wrote: post #9

KurtMueller wrote: post #7

Earlier quoted context omitted.

> However, for complex representational systems, including both transactional and continuous systems in business, commerce and industry, other languages and paradigms can remain better suited. Hello. Respectfully, what is a complex representational system? Why are other languages/paradigms better suited over a language like F#?

> 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.

Actually, the benefits of pure functional programming are even more clearly exposed if you're doing complex IO operations like disk access and mutability. The ability to capture the effectful operations (read a table, write a row) as statically-typed action containers is invaluable because it lets you sequence the effects in a correct order with very little effort.

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

#13

Post by staticassertion » Sat, Feb 04, 2017, 8:16 AM UTC

twblalock wrote: post #9

KurtMueller wrote: post #7

Earlier quoted context omitted.

> However, for complex representational systems, including both transactional and continuous systems in business, commerce and industry, other languages and paradigms can remain better suited. Hello. Respectfully, what is a complex representational system? Why are other languages/paradigms better suited over a language like F#?

> 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.

This is the #1 misconception I see surrounding pure functional programming - that once you run into mutable state, you run into problems.

It is entirely the opposite. PFP exposes the murky aspects of mutability, provides abstractions around it, and ensures that you're not tripping over yourself in regards to mutability.

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

#14

Post by staticassertion » Sat, Feb 04, 2017, 8:17 AM UTC

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 would agree if I felt that the industry were moving towards "better" software - as in, as an industry, we said "Wow, we need to seriously take a step back and start writing systems more reliably, more securely, etc".

I do not think we're going in this direction, necessarily.

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

#15

Post by aryehof » Sat, Feb 04, 2017, 8:52 AM UTC

yawaramin wrote: post #11

aryehof wrote: post #10

Earlier quoted context omitted.

> "What is a complex representational system" 1. Representational systems a. Transactional systems [1], based around actions that need to be recorded , typically for commercial or legal reasons, like software used to record your purchases, payments, reservations, participation, interactions, obligations, results, commitments, plans, and significant events. b. Non-transactional continuous systems, like software contro…

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-types)

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

#16

Post by rubber_duck » Sat, Feb 04, 2017, 9:03 AM UTC

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 see them being mainstream in the future.

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

#17

Post by smoothdeveloper » Sat, Feb 04, 2017, 9:14 AM UTC

twblalock wrote: post #8

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 know a lot of people don't want to hear this but these types of languages, functional first, are the future of our industry. Mainstream languages will incorporate functional features and remain popular, and they will not be superseded by pure functional languages. Java and C# are already doing this.

They will still remain generally more painful and more exposed to their issues and choices:

* mutable by default

* OO by default

* null by default

* structural equality a pain to implement

* immutable types a pain to implement

* verbose syntax / failing at the DRY principle

* statement based rather than expression based

* large codebase following those idioms

I don't think they'll not remain popular, but I think a more important share of people will eventually "get it" that there are alternative approaches which are sound, same or greater potential to achieve and thriving eco-system.

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

#18

Post by smoothdeveloper » Sat, Feb 04, 2017, 9:19 AM UTC

twblalock wrote: post #8

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 know a lot of people don't want to hear this but these types of languages, functional first, are the future of our industry. Mainstream languages will incorporate functional features and remain popular, and they will not be superseded by pure functional languages. Java and C# are already doing this.

The other thing is footprint of codebase, despite almost 15 years of using C#, after only two years, I consistently write F# which is 1/3 of equivalent C# code, writing idiomatic code that any F# developers would grasp.

There are ways a C# aficionado would take to try to not be so verbose, but those solutions won't be considered idiomatic by 99% of C# developers.

At the end of the day, codebase size matters a lot.

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

#19

Post by pjmlp » Sat, Feb 04, 2017, 9:32 AM UTC

smoothdeveloper wrote: post #17

twblalock wrote: post #8

Earlier quoted context omitted.

> 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. Mainstream languages will incorporate functional features and remain popular, and they will not be superseded by pure functional languages. Java and C# are already doing this.

They will still remain generally more painful and more exposed to their issues and choices: * mutable by default * OO by default * null by default * structural equality a pain to implement * immutable types a pain to implement * verbose syntax / failing at the DRY principle * statement based rather than expression based * large codebase following those idioms I don't think they'll not remain popular, but I think a mo…

Managers don't care about those bullet points.

If you want to sell a language to the upper layers, you need a list of business reasons, not language features.

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

#20

Post by pjmlp » Sat, Feb 04, 2017, 9:35 AM UTC

shados wrote: post #6

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…

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.