Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lucasmreis.github.io

Post reply on HN
Print view View original

21–30 of 66 posts

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

#21

Post by smoothdeveloper »

pjmlp wrote: post #19
smoothdeveloper wrote: post #17

Earlier quoted context omitted.

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.

See if testimonials help: http://fsharp.org/testimonials/

As for me, I also use the awareness of manager to the developer needs to be productive, give best ROI and would definitely use that to select a job.

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

#22

Post by cmoscoso »

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.

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

#23

Post by vivainio »

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…

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.

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

#24

Post by willtim »

aryehof wrote: post #5
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…

Future of our industry? Such languages are popular and suited to certain types of projects and solutions certainly. Particularly for systems in computing, and information and data science. However, for complex representational systems, including both transactional and continuous systems in business, commerce and industry, other languages and paradigms can remain better suited.

There's not enough detail here to really comment. I can say that Haskell has the best software transactional memory implementation out there, thanks to purity and controlled side-effects. Haskell's explicit handling of state also helps provenance and keeping state managed / in the database.

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

#25

Post by christophilus »

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. It is the frontend that made me want to learn functional programming in earnest. Redux and ImmutableJs were the catalysts.

I'm currently learning a couple of LISP variants (Closure and LFE). With ClojureScript, Elm, PureScript, BuckleScript, and even plain ole ES6, functional on the frontend is more compelling than ever.

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

#26

Post by jpalomaki »

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.

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 memory in reasonable time in case the cluster goes down.

I think the whole database thing also caused major issues on the object oriented side and actually stopped people from really using OO (or getting benefits out of it). Instead of building intelligent and smart objects it is easy to end up with objects that are just containers for data.

Probably there has been thoughts on how to do this, one old project I remember is Prevayler[1].

[1] http://prevayler.org/

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

#27

Post by grumpyprole »

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…

Agreed. Objects for everything results in code that is riddled with hidden mutable state and side-effects (state is not encapsulated). It's impossible to reason globally about such systems, even before threads are added. Objects can be used as a reasonable module system, which is why many still advocate them, although IMHO better module systems do exist (e.g. in OCaml).

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

#28

Post by willtim »

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?

Yes and Ethereum's imperative approach didn't work out so well. There many FP shops looking at Blockchain. E.g. IOHK which are using Haskell.

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

#29

Post by pjmlp »

smoothdeveloper wrote: post #21
pjmlp wrote: post #19

Earlier quoted context omitted.

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.

See if testimonials help: http://fsharp.org/testimonials/ As for me, I also use the awareness of manager to the developer needs to be productive, give best ROI and would definitely use that to select a job.

I am aware of them, my comment was more a kind of heads up, because I have been in too many meetings about technology adoption, whose presenters though an endless list of features was the best approach.

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

#30

Post by willtim »

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…

Most mainstream languages don't even have sum types, but have to encode them via other means (enums, tags, inheritance). They are not necessarily the best choice for modelling data, just your preferred choice.
Post reply on HN