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

51–60 of 66 posts

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

#51

Post by lucasmreis »

cmoscoso wrote: post #48
lucasmreis wrote: post #32

Earlier quoted context omitted.

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

Good point on the complexity of today web apps. I'm not really into web front-end and my comment was more about native frontend development, where you need to add/remove things from screen, run animations, you know, those sort of things that are inherently non-functional. Sorry for not being clearer.

It's ok! :)

So, if we only want to call a couple of animations and submit a form, I agree that a small script with three jQuery-style functions can do the job.

But that's rarely the case nowadays, in my experience. Almost every frontend project I came across professionally became a full application at some point.

There's the need of dealing with concurrent user interactions, online data requests to the server, non-traditional form behaviors, different routes...

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

#52

Post by pjmlp »

shados wrote: post #47
pjmlp wrote: post #46

Earlier quoted context omitted.

Not always, hence why you get to situations like that car repair shop in Poland using a C64 to manage their businesses. As language geek I dabble in every language I can put my hands on. Yet when it comes to work, it is always Java, C#, JavaScript, C++, SQL, because that is what RFPs allow for.

oh good lord are we pedantic. Yes, not everyone uses the same techs. All i'm trying to say is that we'll see more and more of it. It's already happening with Elm, Elixir, etc.

No, just not everyone lives on Silicon Valley, or cool cities with startups.

There are zero jobs for Elm, Elixir, .... where I live.

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

#53

Post by banashark »

lucasmreis wrote: post #51
cmoscoso wrote: post #48

Earlier quoted context omitted.

Good point on the complexity of today web apps. I'm not really into web front-end and my comment was more about native frontend development, where you need to add/remove things from screen, run animations, you know, those sort of things that are inherently non-functional. Sorry for not being clearer.

It's ok! :) So, if we only want to call a couple of animations and submit a form, I agree that a small script with three jQuery-style functions can do the job. But that's rarely the case nowadays, in my experience. Almost every frontend project I came across professionally became a full application at some point. There's the need of dealing with concurrent user interactions, online data requests to the server, non-tr…

Here is an example of something small that can benefit from F# sharing:

http://banashek.com/posts/20170204-a-brief-peek-at-universal...

Sharing types, validators, etc mean that the api communication is type-safe.

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

#54

Post by dllthomas »

pjmlp wrote: post #52
shados wrote: post #47

Earlier quoted context omitted.

oh good lord are we pedantic. Yes, not everyone uses the same techs. All i'm trying to say is that we'll see more and more of it. It's already happening with Elm, Elixir, etc.

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.

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

#55

Post by kazinator »

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 (* quantity product.price)))
  
  (defmeth basket add-to (me product quantity)
    (flet ((transform-line (line)
             (if (equal line.product-sku product.sku)
               (build-line product (+ line.quantity quantity))
               line)))
      (let* ((transformed-lines [mapcar transform-line me.lines])
             (product-already-in-basket (nequal transformed-lines me.lines)))
        (if product-already-in-basket
          (new basket lines transformed-lines)
          (new basket lines (cons (build-line product quantity) me.lines))))))
  
  (defmeth basket update (me event)
    event.(add-to me))
  
  (defmeth add-to-basket add-to (me basket)
    basket.(add-to me.product me.quantity))
REPL:

  $ txr -i typemodel.tl 
  1> (new add-to-basket product (new product sku 42 price 5) quantity 4)
  #S(add-to-basket product #S(product sku 42 price 5) quantity 4)
  2> (new basket)
  #S(basket lines nil total 0)
  3> *1.(add-to *2)
  #S(basket lines (#S(line product-sku 42 quantity 4 line-total 20)) total 20)
(The silly implementation of the product-already-in-basket is a literal transliteration of the original.)

If you see me designing programs like this in real life, just whack me on the head, please!

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

#56

Post by celdon25 »

rubber_duck wrote: post #39
jackmott wrote: post #38

Earlier quoted context omitted.

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, bec…

As a developer with 10 years of C# experience and two weeks (and counting) of F# experience, I'm already finding it easier and more enjoyable to do a lot of things in F#. Results may vary.

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

#57

Post by lucasmreis »

banashark wrote: post #53
lucasmreis wrote: post #51

Earlier quoted context omitted.

It's ok! :) So, if we only want to call a couple of animations and submit a form, I agree that a small script with three jQuery-style functions can do the job. But that's rarely the case nowadays, in my experience. Almost every frontend project I came across professionally became a full application at some point. There's the need of dealing with concurrent user interactions, online data requests to the server, non-tr…

Here is an example of something small that can benefit from F# sharing: http://banashek.com/posts/20170204-a-brief-peek-at-universal... Sharing types, validators, etc mean that the api communication is type-safe.

Really good, amazing example

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

#58

Post by jpalomaki »

olavk wrote: post #37
jpalomaki wrote: post #26

Earlier quoted context omitted.

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.

The idea is not to query things from the persistent store. Instead you would keep all the data in memory. The persistent store is just there in case your server goes down. In case of OO, there would be one big object graph which you then navigate using the functionality available in your programming language. For example take a list of things, pass it through the filter function to pick what you want.

My feeling is that in traditional business apps you don't have so much needs to these random searches over huge amount of data. It's more about taking hold of one piece of the graph and then navigating to related objects (dummy example: search for customer, then start looking at that customers orders).

I'm not familiar with Smalltalk, but I'm sure there was some ideas related to persistence other than just ORM and relational database (but could be those ideas have been proven as bad over the years). I just find it a bit strange that we have been building these things pretty much the same way for the last 20+ years. Meanwhile the hardware has changed much. Even with quite small corporate hw budget you are looking at half a terabyte of RAM and tens of cores in a single server.

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

#59

Post by throwawayish »

jpalomaki wrote: post #58
olavk wrote: post #37

Earlier quoted context omitted.

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

The idea is not to query things from the persistent store. Instead you would keep all the data in memory. The persistent store is just there in case your server goes down. In case of OO, there would be one big object graph which you then navigate using the functionality available in your programming language. For example take a list of things, pass it through the filter function to pick what you want. My feeling is t…

http://zodb.org/ is literally what you are describing :)

It's the basis of most Zope apps, including Plone, but also many other applications; there's not much talk about it, because it just works. Like in the comment I made below; if it's a good fit ze ZODB is quite literally worth every LoC in gold.

The database itself doesn't do that much (apart from giving you transparent object/application persistence, transactions and MVCC :), as one would expect.

The Zope people made an excellent job of modularising it (or, in other words: this is by principle extremely modular), so there are a bunch of packages commonly used around it (eg. BTrees, zodburi, often either ZEO or RelStorage and stuff like eg. zope.container).

(Historically it's also very interesting - development started in 1997! The revision history is an interesting read, too, many familiar names pop up, including GvR)

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

#60

Post by tejasv »

daxfohl wrote: post #42
lucasmreis wrote: post #33

Earlier quoted context omitted.

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

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 problems, so it's not 100% done.

http://stackoverflow.com/questions/41949177/f-data-types-sql...

Post reply on HN