4 ms·

Why? Just like learning Emacs/vim, the time investment is well worth it. You get much more elaborate the more time you invest in learning, and the skills gaine

Why? Just like learning Emacs/vim, the time investment is well worth it. You get much more elaborate the more time you invest in learning, and the skills gained will still be valuable in 25 years - as opposed to whatever subset of SQL the query builder du jour would give you.

smcl 5y ago
It sounds like the commenter knows SQL, so it’s not like they want to avoid learning it. I can only guess, but more likely they dislike the fact that you have to represent your raw queries etc safely as a string in your application’s language - which isn’t hard but it does look a little ungainly and tends not to scale too well. As for the “du jour” part - is there that much churn and fanboyism in ORMs?
- spfzero 5y ago
  Strings do give you the ability to copy them right into your code from the SQL console after testing.
  - smcl 5y ago
    While that is true, I think most queries would involve parameters of some sort, so those would need to be fiddled with at the very least after pasting to your code, plus you'd also want to format them so they don't look that out of place. And at that point you've likely got a single maybe-weirdly indented query that appears as a plain string, which is fine if you have just a couple but can get a little tricky if you have a larger application. I'm not super religious about this - a colleague and I were discussing Hangfire.io's SQL Server code which has inline SQL[0] and we ended up agreeing that it's fine - but if I'm writing an application with a SQL backend I'm definitely leaning towards using something like EF in .NET [0] = https://github.com/HangfireIO/Hangfire/blob/master/src/Hangfire.SqlServer/SqlServerStorage.cs#L496-L499 https://github.com/HangfireIO/Hangfire/blob/master/src/Hangf...
    - spfzero 5y ago
      True about the params. I guess I've always put the queries in as "here" strings, so they do look out of place in the sense that the structure is different. In most cases the sql was in a file with a bunch of other "lowest" level db calls, so I kind of got used to that being the look of those particular source files. Looked at the Hangfire code and the last two methods there look a lot like what I used to do in the old C# days. Except I'd have whole files of db stuff like that, and other files for the C# code that called them.
      - smcl 5y ago
        Ah neat so there's a very real separation between the code itself and the queries, that I think addresses the weirdness of seeing a block of SQL in a string literal that I find a bit jarring. Out of curiousity, is this Perl by any chance? I haven't really seen here docs in use outside shell or Perl scripts
        spfzero 5y ago
        Haven't used Perl but they're in a lot of languages, Lisps, Python ("""), Ruby, PHP etc. but C# does at least have the verbatim-type of strings which would be good enough. Don't use the interpolation features though, use the @params and let the SQL driver do the replacements.
BiteCode_dev 5y ago
I've learned vim. It was not worth it. I'm more productive with vscode and nano. I know SQL, 99% of the time, an ORM is more productive, for the rest, I can still write SQL manually. It's not an XOR.
- desmondl 5y ago
  I got pretty proficient at using vim in vscode, and personally for me the investment was worth it. It's great for working in HTML with chords like `va"p` (replace selection around quote with clipboard) and `dip` (cut out the contents inside this xml tag). YMMV depending on the type of work you do.
- chousuke 5y ago
  I'm completely hopeless in nano because I can't for the life of me use the arrow keys for moving around, so I just end up typing random strings of hjkl/bw or whatever in the buffer until I realize I have the wrong editor and switch to some variant of vi so I don't fight with my fingers. One major advantage of vi is that it's always there (except on Windows :().
sparker72678 5y ago
I'm fluent in SQL, and even with ActiveRecord it's not always possible to escape having to write it directly, but I still don't like it. Writing raw SQL comes with all kinds of risks you can abstract away through nice ORM APIs, and with a good ORM API I find that it's much easier to clearly communicate intent in the code. YMMV.
crooked-v 5y ago
Even sticking to "just" SQL without a true ORM, using a well-designed query builder instead of writing raw strings will save you from inevitable "oops, forgot a comma" bugs.
danellis 5y ago
With the library I'm using (Quill), the DSL is mostly a copy of the standard library's collections, so other than a little boilerplate, it's mostly already familiar.

smcl 5y ago

It sounds like the commenter knows SQL, so it’s not like they want to avoid learning it. I can only guess, but more likely they dislike the fact that you have to represent your raw queries etc safely as a string in your application’s language - which isn’t hard but it does look a little ungainly and tends not to scale too well. As for the “du jour” part - is there that much churn and fanboyism in ORMs?

spfzero 5y ago
Strings do give you the ability to copy them right into your code from the SQL console after testing.
- smcl 5y ago
  While that is true, I think most queries would involve parameters of some sort, so those would need to be fiddled with at the very least after pasting to your code, plus you'd also want to format them so they don't look that out of place. And at that point you've likely got a single maybe-weirdly indented query that appears as a plain string, which is fine if you have just a couple but can get a little tricky if you have a larger application. I'm not super religious about this - a colleague and I were discussing Hangfire.io's SQL Server code which has inline SQL[0] and we ended up agreeing that it's fine - but if I'm writing an application with a SQL backend I'm definitely leaning towards using something like EF in .NET [0] = https://github.com/HangfireIO/Hangfire/blob/master/src/Hangfire.SqlServer/SqlServerStorage.cs#L496-L499 https://github.com/HangfireIO/Hangfire/blob/master/src/Hangf...
  - spfzero 5y ago
    True about the params. I guess I've always put the queries in as "here" strings, so they do look out of place in the sense that the structure is different. In most cases the sql was in a file with a bunch of other "lowest" level db calls, so I kind of got used to that being the look of those particular source files. Looked at the Hangfire code and the last two methods there look a lot like what I used to do in the old C# days. Except I'd have whole files of db stuff like that, and other files for the C# code that called them.
    - smcl 5y ago
      Ah neat so there's a very real separation between the code itself and the queries, that I think addresses the weirdness of seeing a block of SQL in a string literal that I find a bit jarring. Out of curiousity, is this Perl by any chance? I haven't really seen here docs in use outside shell or Perl scripts
      - spfzero 5y ago
        Haven't used Perl but they're in a lot of languages, Lisps, Python ("""), Ruby, PHP etc. but C# does at least have the verbatim-type of strings which would be good enough. Don't use the interpolation features though, use the @params and let the SQL driver do the replacements.

BiteCode_dev 5y ago

I've learned vim. It was not worth it. I'm more productive with vscode and nano. I know SQL, 99% of the time, an ORM is more productive, for the rest, I can still write SQL manually. It's not an XOR.

desmondl 5y ago
I got pretty proficient at using vim in vscode, and personally for me the investment was worth it. It's great for working in HTML with chords like `va"p` (replace selection around quote with clipboard) and `dip` (cut out the contents inside this xml tag). YMMV depending on the type of work you do.
chousuke 5y ago
I'm completely hopeless in nano because I can't for the life of me use the arrow keys for moving around, so I just end up typing random strings of hjkl/bw or whatever in the buffer until I realize I have the wrong editor and switch to some variant of vi so I don't fight with my fingers. One major advantage of vi is that it's always there (except on Windows :().

sparker72678 5y ago

I'm fluent in SQL, and even with ActiveRecord it's not always possible to escape having to write it directly, but I still don't like it. Writing raw SQL comes with all kinds of risks you can abstract away through nice ORM APIs, and with a good ORM API I find that it's much easier to clearly communicate intent in the code. YMMV.

crooked-v 5y ago

Even sticking to "just" SQL without a true ORM, using a well-designed query builder instead of writing raw strings will save you from inevitable "oops, forgot a comma" bugs.

danellis 5y ago

With the library I'm using (Quill), the DSL is mostly a copy of the standard library's collections, so other than a little boilerplate, it's mostly already familiar.