News for hackers. Stuff that matters.
Re:The Problem with F# Evangelism by brianberns on Wednesday August 16, 2017 @11:55AM (#15028491)
C# developers in my shop loathe the SQL type provider because it requires them to have a compatible SQL Server database schema at build-time. The extra level of organization required is more than they can accept.
Re:The Problem with F# Evangelism by mbenoni7 on Wednesday August 16, 2017 @02:13PM (#15029765)
There's a new type provider out that takes a different approach by bundling a SQL parser:

https://github.com/rspeele/Rezoom.SQL

It can't check everything that the other providers can, but IMO you get most of the benefit without requiring any onerous build-time dependencies.

Re:The Problem with F# Evangelism by brianberns on Thursday August 17, 2017 @01:12AM (#15033964)
Very cool. Thank you.
Re:The Problem with F# Evangelism by tarmil on Thursday August 17, 2017 @10:52AM (#15037285)
Actually, for the providers from FSharp.Data.TypeProviders, it's only necessary when you need to pull a schema change.

You can pass `LocalSchemaFile = "foo.ssdl", ForceUpdate = false` to the provider, and it will only try to connect to the database if the file foo.ssdl doesn't exist; if it does, then the provider just uses it to compute the schema. When the schema changes, you just need to set ForceUpdate to true, wait for the IDE to pull the changes from the server and write foo.ssdl, then set ForceUpdate back to false, and you can commit the changed file.

Re:The Problem with F# Evangelism by rjbwork on Wednesday August 16, 2017 @12:12PM (#15028645)
Does the F# SQL type provider integrate with the .sqlproj database projects that are in the solution, or do you have to have an actual running SQL database?
Re:The Problem with F# Evangelism by brianberns on Wednesday August 16, 2017 @12:27PM (#15028788)
It needs a connection string to a real database.

http://fsprojects.github.io/FSharp.Data.SqlClient/

Re:The Problem with F# Evangelism by ice109 on Wednesday August 16, 2017 @08:18PM (#15032576)
that kind of thing is a collosal mistake in my opinion - just on the face of it I/o at compile time seems very wrong.
Re:The Problem with F# Evangelism by bonesss on Thursday August 17, 2017 @02:56AM (#15034357)
An understandable position.

Here's the context that makes it not a big deal:

1) If there is some fundamental issue with having a dev DB then you would just use another ORM, just like in C#. Really, this specific type provider is not an ORM, it's for SQL server data munging. Most every project I've seen in a decade has multiple dev DBs, many used in testing, many used for staging... being able to talk to a valid schema source should be relatively straightforward... but if it isnt then get a different type provider or use an ORM with explicit code generation.

2) Compile time guarantees about data sources is a huge source of comfort when dealing with DBs owned by external actors or teams. For data scientist, integrator, sys admins, and such the norm is connecting to operational DBs that you have very little control over. This specific Type Provider ensures that your scripts will not compile if there has been a breaking schema change. That means you're seeing these issues during deployment, not as costly runtime errors that may or may not corrupt your application state. Less debugging, more safety, better guarantees, immediate feedback on issues; all in realtime.

To summarize: if compile time validation of JSON structures, XML structures, SQL Schema, or custom file formats creates some kind of pain, then don't use a provider of types that relies on analyzing data structures to create code :)

For the other 99.9999% of the time type providers are a DREAM for working with external data sources, provide most of what we want ORMs for, and are very lightweight in comparison. It's rapid data exploration with built in prototyping. Very nice.

Re:The Problem with F# Evangelism by brianberns on Thursday August 17, 2017 @01:14AM (#15033972)
Why? Compilers have to read source files anyway. What's wrong with reading other stuff as well? For example, there are type providers for XAML, JSON, app.config, etc. Do they also seem wrong to you?