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

41–50 of 66 posts

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

#41

Post by smoothdeveloper »

pjmlp wrote: post #29
smoothdeveloper wrote: post #21

Earlier quoted context omitted.

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.

I see what you mean.

Really reduced codebase size and features like type provider which increase safety and saves from writing boiler plate code do save on the bottom line, especially in maintenance.

Also, if you are using vanilla C# for math computation, you can save CPU/energy by translating it to F#, it tends to run significantly faster, that also impacts the bottom line in some contexts.

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

#42

Post by daxfohl »

lucasmreis wrote: post #33
daxfohl wrote: post #4

I call this RSLDD: Red Squiggly Line Driven Development.

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.

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

#43

Post by throwawayish »

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.

I disagree with both of you.

SQL and ORM are a superb fit for a great many applications, incidentally a large share of real world applications. The four-letter abbrev. CRUD comes to mind, as well as reporting.

Most kinds of NoSQL remove some benefits of the relational model while not really giving you the benefits of object persistence. I never felt a great need to use it; since quite some of these databases also had all sorts of issues that not exactly endeared trust for serious applications -- I'm not working on software where that's an OK thing to have (though for others it might be an acceptable tradeoff).

The real deal persistent object databases are a completely different beast from both NoSQL and relational models (only some NoSQL concepts like explicit / application-level indexing carry over). Two important things to note about these: 1.) There are not many of them 2.) Properly using them already requires proper OO technique. Failing 2.) will make it an unmaintainable mess. Certain kinds of applications benefit greatly from these, and there they also tend to perform better in both developer experience and efficiency as well as application performance than forcing a huge impedance mismatch down the throat of an ORM -- which pretty much always means that the underlying relational DB is used in very anti-patternish ways, resulting in poor performance regardless how good the DB actually is.

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

#44

Post by shados »

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.

it trickles down, slowly. Facebook does it, then SV companies do it, then tech companies globally do it, then everyone else.

Always goes that way.

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

#45

Post by pjmlp »

lucasmreis wrote: post #35
pjmlp wrote: post #20

Earlier quoted context omitted.

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

I love ML languages, my first was Caml Light, OCaml wasn't yet born.

Also share your opinion, and go even further, for me personally IT projects should be accountable just like in many industries.

However my experience in enterprise consulting, with applications written in Excel, or languages that allow for "replaceable programmers", is that business doesn't care if software is the same quality of 1 € shop items, as long it generates the desired output.

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

#46

Post by pjmlp »

shados wrote: post #44
pjmlp wrote: post #20

Earlier quoted context omitted.

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.

it trickles down, slowly. Facebook does it, then SV companies do it, then tech companies globally do it, then everyone else. Always goes that way.

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.

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

#47

Post by shados »

pjmlp wrote: post #46
shados wrote: post #44

Earlier quoted context omitted.

it trickles down, slowly. Facebook does it, then SV companies do it, then tech companies globally do it, then everyone else. Always goes that way.

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.

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

#48

Post by cmoscoso »

lucasmreis wrote: post #32
cmoscoso wrote: post #22

Earlier quoted context omitted.

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

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.

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

#49

Post by jackmott »

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.

have you seen sqlprovider and sqlcommandprovider?

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

#50

Post by vivainio »

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…

You rarely have Tabula Rasa developers - average developer is probably proficient in Java and/or C#.

I would say HM type inference is a non-incremental "hard sell" improvement, but it depends on the target audience :).

Post reply on HN