Hakeashar

Isn't a CTE in Postgres (unlike in MS SQL, AFAIR) also an optimization fence?

Just something to keep in mind when using it as a substitute for subquery, readability vs performance and all that :)

Yup, it's a bit unfortunate, but that's how it is most of the time.

I found myself using F# for core libraries with clearly defined boundaries between APIs and assemblies - IMO that's where the language shines right now. You can have your core logic contained in a library with a separate, C#-compatible API.

Using F# for WPF, ASP.NET MVC or ASP.NET WebAPI development wasn't quite as stellar experience, also because of the state of the tooling. I'm even wary about type providers, when they work - it's great, when they don't - you're pretty much screwed with no real recourse. In case of relational DB access, most .NET libraries (both full-ORMs and micro-ORMs) are C#-oriented.

Therefore, after including all the annoyances you listed, it's hard to justify anything more than 'handle core libraries in F# with C#-compatible API, do the rest in C# - it's good enough' to the business...

I'd say that ~98% (statistic pulled out of the thin air) of Single Page Applications are - in fact - Single Page Websites in your terminology. At least that's what I usually see when various companies are using Angular (or Ember, or React-with-routing, or any other library/framework) to power their web applications.

Honorable mention for the application that you probably have in mind can go towards (IMO) React UI Builder which was posted to HN a few days ago (https://github.com/ipselon/react-ui-builder).

Looks interesting...

Do you actually support 'full remote' positions? I'm asking because the application system on your site has 'Permanent legal right to work in the United States.' listed as one of the requirements.

The platform I know best (.NET) seems to align with what you're looking for, but working in and/or moving to US is not really an option. Time zone wouldn't be an issue though.

It's something that I noticed too. I had what I think was a pretty unique opportunity to be involved in project(s) from the very beginning to the 'end' (i.e. support phase) from my early working days - since my very first year. That allowed me to fully experience writing really underengineered code, then subsequently vastly overengineered, then a chance to clean it up - all while having no one else to blame but myself for any shortcomings. I'd like to think it taught me a lot and of all the rules-of-the-thumb and catchy acronyms, it seems like KISS and YAGNI sank in the most.

Also, a lot of the points the article makes about the senior engineer seem to be about a 'business sense' - what the actual business problems you're solving are and how your solutions influence the business itself. I really like to know all that - in fact, those are my starter questions as a candidate in any job interview - but I don't know if it's just an innate trait that some people have, if it's something you pick up, or maybe both to a degree...?

And I don't consider myself a senior engineer, not by a long shot...

Makes sense.

I mean, I mostly work with C# and F# on the back-end, but I created my fair share of WPF apps which I vastly prefer to web front ends. I also tinker with Scala in my free time, but I don't really know much about the JVM ecosystem.

I also readily admit I know next to nothing (neither have a feeling for) the UI/UX design, which is why I usually relied on libraries like MahApps; lately I had my eye on Material Design for WPF.

Considering my contract is up soon(ish), what you're offering looks tempting. :)

All things considered, I still feel compelled to ask: do you have a salary range or is it discussed individually? Or both, to a degree?

Huh, that sounds intriguing.

What 'kind' of engineer are you looking for? Any specific platforms, languages or fields of interest? I went through the site and the portfolio consists of multiple (and very different) projects, so I'm just wondering how it works. :)

I figured as much. Unfortunately there's no Emit for AOT where you could do something like: https://github.com/jonwagner/Insight.Database/blob/master/In...

On the other hand, I wonder if it wouldn't be easier to ship a T4 template? I know for sure that would integrate with VS (both the IDE and build process) without any issues, not sure about Xamarin Studio...

Damn, thanks for pointing me in that direction. It's exactly what I've been looking for.

Technically, I implemented some of that stuff myself because I needed REST client that would work with PCLs and be a bit 'nicer' to use than just juggling strings/routes everywhere, so using annotations and wrapping Microsoft's HttpClient was obvious and relatively easy way out.

Anyway, I'll probably just phase out my own solution and start using the library.

[EDIT]

After checking it out, RefitStubs.cs file seems a little bit clunky, but the library as a whole looks solid enough. I'll look further into it.

Lately I checked the Perlin noise performance test that was linked to on reddit (http://www.reddit.com/r/programming/comments/31mzu1/go_vs_ru...).

Summary:

Benchmark: C# (Mono) - 1052.041381 ms, Java - 597.9874 ms

My machine: C# (Windows) - ~475 ms, Java - ~552 ms

Even considering that Mono is using maximum precision available (so instead of floats it's using doubles), when I swapped all floats to doubles it still ran in ~525 ms on my box.

So while Mono might be 'getting there', sometimes it's still lagging behind. It's just something to keep in mind :)

AsNoTracking makes the materialization indeed faster, but EF always has a cost associated with it, both for initial use (set up of the context etc, which is noticeable) as well as every other query after that (expression tree parsing etc, not as noticeable especially for recurring queries).

I hope it's one of the pain points they will address and solve during their rewrite to EF7 at one point.

That being said, my opinion is that unless you have really strict performance and/or latency requirements, EF should be good enough. At least for simpler queries and in 'longer-running' applications :)

For working with HTML (parsing, extracting), I'd like to add HtmlTypeProvider from F# Data as one of the options. :)

Even then, for query building I found EF (or any LINQ provider for SQL) to be easier solution than string concatenation. Well, at least for relatively simple queries with pagination and stuff. For filters, Dynamic.Linq would be helpful here.

On the other side, if you need to work extensively with stored procedures or you have complicated or custom SQL to run, Dapper (or Insight.Database - https://github.com/jonwagner/Insight.Database, a library which I found really nice to use) will be your best friend.

- Writing a WPF app in F# is a real pain (no partial classes, no nice MVVM framework support like Caliburn.Micro). C# is way better there.

- Accessing the DB is easier in C# (just select a nice micro-ORM), type providers do not always cut it.

- When using any kind of library that relies on anonymous types (e.g. Dapper for database access).

- Tooling is still not complete, not being able to create directories in F# project (!) from IDE level (and even if you edit .fsproj, it can be a bit buggy) is really annoying in both web and desktop apps.

- If you want to use some of object-oriented features e.g. co/contravariance in interfaces, protected access modifier.

- (admittedly, that does not happen often) no unsafe context/keyword

That being said, I agree that F# has a very sane set of defaults and I really like using F# for library work.

ADO.NET uses DBNull: http://msdn.microsoft.com/en-us/library/system.dbnull(v=vs.1...

There's one valid (if obscure) use case for it, other than that it is pretty much redundant: http://stackoverflow.com/q/4488727/1180426

All modern (micro)ORMs, even if they're just a thin wrapper over ADO.NET like Dapper, work just fine with regular nulls.

No problem! Happy to help :)

ORMs get a lot of flak and while some of it is truly earned, the rest comes from the misuse/abuse of the tool. I always thought that using ORM functionality (where convenient) together with SQL (where necessary or convenient for different facet of the application) was the best from both worlds.

And then you can of course mix different ORMs in one project, so you can use EF in areas where performance does not really matter that much or if you're doing a lot of CRUD and Dapper (or something like Insight.Database if you like stored procedure-to-interface mapping) in hot paths or analytic-heavy piece.

Even the bulkiest ORMs allow you to use raw SQL. That's why you can use 80 - 90% of the features on the regular basis and hand-tweak regions which cause performance problems or places where you just have to write SQL (e.g. recursive queries).

In EF, there's either: Database.SqlQuery<T> - http://msdn.microsoft.com/en-us/library/gg696545%28v=vs.113%...

which can return any object or: DbSet<T>.SqlQuery - http://msdn.microsoft.com/en-us/library/gg696332%28v=vs.113%...

which returns tracked entities, so you can write raw SQL (e.g. call a stored procedure) and just use the 'mapper' part of the framework.

NHibernate has CreateSQLQuery - http://www.nhforge.org/doc/nh/en/#querysql-creating

I like micro-ORMs, but when you want to skip writing tedious INSERT or UPDATE queries, you have to add extensions to them (at least to Dapper); that, and SQL strings do not really lend well to refactoring and type safety...

I would love to see pattern matching and at least some kind of tuple support. I don't know if it's ever going to happen in C# though...

The `using` static is actually really good news. I have seen people who seem to be really mad about it, but sometimes it would be nice to have, for example:

    // Something like Scala's 'Predef'
    public static class Id<T>
    {
	public static Func<T, T> Identity { get {  return x => x; } }
    }

   using Id;

   var grouped = list.GroupBy(Identity);

Equivalent of F#'s record types would be also awesome, which is what you put as 'readonly class':

    type Person = { FirstName : string; LastName : string }
    let single = { FirstName = "Jane"; LastName = "Doe" }
    let married = { single with LastName = "Smith" }

I'd love to see some kind of typeclass support in F#...

In the meantime, honest question: what are modules in OCaml? I tried to read up on it online, but my understanding of the topic is still murky. Regular modules don't really seem that interesting (they look like modules and/or types/classes in F#), parametrized modules seem to be something that is missing in F#.

Second question, do you have that proof of concept code laying somewhere around? I'm just curious how it would look in F#...

Just a quick question - if the views are set to be deprecated, what would be the way to do a (long) series of collection transformation without spawning multiple intermediate collections? So, essentially, equivalent of .view, transformations, .force?