Really intriguing article about a SQL syntax extension that has apparently already been trialed at Google.

As someone who works with SQL for hours every week, this makes me hopeful for potential improvements, although the likelihood of any changes to SQL arriving in my sector before I retire seems slim.

        • frezik@midwest.social
          11·
          3 months ago

          Possibly unpopular opinion: more languages should embrace unicode symbols in their syntax with multi-character ascii equivalents like Raku did. I set my vim config to automatically replace the ascii version with unicode. It wasn’t hard, it makes the code a little more compact, and with good character choices, it stands out in an understandable way.

          • xmunk@sh.itjust.works
            5·
            3 months ago

            I think that makes it harder to work in a language… you certainly can set up an editor autoreplacement but once a decade or so someone’s going to need to hotfix something in a strange environment and trying to force things into nano using alt codes is a real pain.

            That said the intentionally hard to type symbols with ascii replacements actually make me less sad than things like this syntax that requires a pipe character… I don’t know if you’re a polyglot (or ever typed on a keyboard in quebec) but most of these languages’ symbol choices are convenient on an en-US keyboard with little consideration for international keyboard layouts and there are a lot of hard to type symbols on the spanish keyboard that are very common in programming languages.

          • Kogasa@programming.dev
            3·
            3 months ago

            This should be done with font ligatures, not replacing character combinations with other characters that can’t be typed normally

    • anti-idpol action@programming.dev
      1·
      3 months ago

      In Clojure, -> is used for inserting the piped argument at the head position in the arguments of whatever it is passed to, while ->> is used for inserting it at the tail. This approach is great for working with immutable data in a series of approachable transformations, which I believe is one reason why so many Domain-Specific Languages for generative programming are written in that language, aside from its interactive REPL. Additionally, there is no need to worry about excessive copying, as this is generally well optimized.

      This can be particularly useful with HoneySQL, which is more of a DSL for SQL rather than a typical ORM tool. For example:

      (defn apply-filters [query filters]
"applies WHERE clauses to a query"
  (reduce (fn [q [column value]]
            (helpers/where q [:= column value]))
          query
          filters))

(defn build-dynamic-query [{:keys [table columns filters sort-by limit]}]
  (-> {}
      (helpers/select columns)
      (helpers/from table)
      (apply-filters filters)
      (helpers/order-by sort-by)
      (helpers/limit limit)
      sql/format))

;; Result - a super readable function call that resembles a natural language 
(build-dynamic-query 
  {:table :products 
   :columns [:id :name :price] 
   :filters {:category "electronics" :in-stock true}
   :sort-by [:price :desc]
   :limit 20})