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

61–66 of 66 posts

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

#61

Post by kazinator »

kazinator wrote: post #55

TXR Lisp: (defstruct product nil sku price) (defstruct event nil) (defstruct add-to-basket event product quantity) (defstruct line nil product-sku quantity line-total) (defstruct basket nil lines total (:postinit (me) (set me.total [reduce-left + me.lines 0 (usl line-total)]))) (defvarl empty-basket (new basket)) (defun build-line (product quantity) (new line product-sku product.sku quantity quantity line-total (* qu…

Here is a version of basket add-to with a recursive local function for doing the insert, avoiding the clumsy mapcar and "did we insert or not" check copied from the F# code.

  (defmeth basket add-to (me product quantity)
    (labels ((insert (lines)
               (tree-case lines
                 ((line . rest) (if (equal line.product-sku product.sku)
                                  (cons (build-line product
                                                    (+ line.quantity quantity))
                                        rest)
                                  (cons line (insert rest))))
                 (() (list (build-line product quantity))))))
      (new basket lines (insert me.lines))))

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

#62

Post by daxfohl »

tejasv wrote: post #60
daxfohl wrote: post #42

Earlier quoted context omitted.

It'd be especially nice if database schemas mapped to F# types more readily. JSON db's kinda do it, but with no defined schema and no joins. It seems like it'd be not terribly difficult to augment regular SQL databases with something akin to the F# type system to define table schemas, rather than just flat data in columns. Then "SQL" could be extended to include `match` expressions.

I've taken the approach of converting my models to XML, mostly because they map 1:1 from F#-land to XML-land, and I can use SQL Server's XML Indices, but most importantly, I can use XSLT to evolve my persisted models upon change change to F# code. Then using a bit of F# Quotations, I can convert most match queries to XPath queries and query SQL Server directly (still work-in-progress). But running into performance pr…

Yeah, I did the first part a couple years ago too. I also put the whole thing behind a VCS so we'd have version-controlled data. But, yeah, it didn't scale well enough and I ended up dropping that for mongodb, and later for postgres.

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

#63

Post by pjmlp »

dllthomas wrote: post #54
pjmlp wrote: post #52

Earlier quoted context omitted.

No, just not everyone lives on Silicon Valley, or cool cities with startups. There are zero jobs for Elm, Elixir, .... where I live.

The parent claimed "Elm, Elixer, ..." were the future of the industry. You seem to be asserting that they are not the present.

I am asserting most of us across the world, work in boring companies whose main business is not software development and don't use such languages and never will, yes.

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

#64

Post by dllthomas »

pjmlp wrote: post #63
dllthomas wrote: post #54

Earlier quoted context omitted.

The parent claimed "Elm, Elixer, ..." were the future of the industry. You seem to be asserting that they are not the present.

I am asserting most of us across the world, work in boring companies whose main business is not software development and don't use such languages and never will, yes.

You had only been asserting "don't use such languages", you hadn't really got to "and never will". And I don't know whether I disagree, but you've certainly not made a case for it.

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

#65

Post by pjmlp »

dllthomas wrote: post #64
pjmlp wrote: post #63

Earlier quoted context omitted.

I am asserting most of us across the world, work in boring companies whose main business is not software development and don't use such languages and never will, yes.

You had only been asserting "don't use such languages", you hadn't really got to "and never will". And I don't know whether I disagree, but you've certainly not made a case for it.

No, you are the ones asserting "don't use such languages".

I am asserting "most of us never will never be allowed to use them at work.", which is quite different point.

Not everyone can relocate just for the pleasure of using another programming language.

But I guess not having job offers on the region one lives is not considered making a point.

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

#66

Post by dllthomas »

pjmlp wrote: post #65
dllthomas wrote: post #64

Earlier quoted context omitted.

You had only been asserting "don't use such languages", you hadn't really got to "and never will". And I don't know whether I disagree, but you've certainly not made a case for it.

No, you are the ones asserting "don't use such languages". I am asserting "most of us never will never be allowed to use them at work.", which is quite different point. Not everyone can relocate just for the pleasure of using another programming language. But I guess not having job offers on the region one lives is not considered making a point.

> No, you are the ones asserting "don't use such languages".

Oops, did you read that as imperative? It was just meant to be present tense. I didn't mean that you were recommending people not use these languages, just saying jobs aren't presently available in most companies. I missed the ambiguity when I wrote it; my bad.

My point was that the fact that you are not currently being allowed to use these languages doesn't imply that new languages won't be added to the list of "Java, C#, JavaScript, C++, SQL" - there was a time when none of those were on the list. It may be that there is something in particular that will prevent the addition of "these languages" but it hasn't been spoken to.

Post reply on HN