Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
AI Databases Programming

Ask Slashdot: DuckDB Queries JSON with SQL. But Will AI Change Code Syntax? (pgrs.net) 12

Long-time Slashdot reader theodp writes: Among the amazing features of the in-process analytical database DuckDB, writes software engineer Paul Gross in DuckDB as the New jq, is that it has many data importers included without requiring extra dependencies. This means it can natively read and parse JSON as a database table, among many other formats. "Once I learned DuckDB could read JSON files directly into memory," Gross explains, "I realized that I could use it for many of the things where I'm currently using jq. In contrast to the complicated and custom jq syntax, I'm very familiar with SQL and use it almost daily."

The stark difference of the two programming approaches to the same problem — terse-but-cryptic jq vs. more-straightforward-to-most SQL — also raises some interesting questions: Will the use of Generative AI coding assistants more firmly entrench the status quo of the existing programming paradigms on whose codebases it's been trained? Or could it help bootstrap the acceptance of new, more approachable programming paradigms?

Had something like ChatGPT been around back in the Programming Windows 95 days, might people have been content to use Copilot to generate reams of difficult-to-maintain-and-enhance Windows C code using models trained on the existing codebases instead of exploring easier approaches to Windows programming like Visual BASIC?

This discussion has been archived. No new comments can be posted.

Ask Slashdot: DuckDB Queries JSON with SQL. But Will AI Change Code Syntax?

Comments Filter:
  • by boulat ( 216724 ) on Sunday March 24, 2024 @11:44AM (#64340891)

    Not amazing. Not even new. Not even innovative.

    Stop sucking at your job, editor david.

  • How many methods or expressions in how many languages have you stumbled upon a more efficient way of doing it, but the source code would essentially be "unreadable"...?
  • If I'm coding, I'm fine with letting AI suggest a few lines or a small routine here and there, but there is no way in hell I'm letting it build a complete system or even putting one of it's suggestions into production without reviewing every line.

    I've taken to using ChatGPT to generate PowerShell scripts for 365 admin tasks for me, but while it is faster than typing it out myself or even looking up a snippet I've stored somewhere... it generates crap from time to time that needs correcting.

  • by fluffernutter ( 1411889 ) on Sunday March 24, 2024 @12:37PM (#64340977)
    Maybe he should be using PostgreSQL [postgresql.org]?
    • by Skinkie ( 815924 )
      The big difference between DuckDB and PostgreSQL is that for DuckDB you don't run a separate database process, it is an in process database. This is directly the major drawback of DuckDB: you can't do concurrent read/write operators. In my perspective DuckDB replaces remote crunching solutions, because it made column storage accessible in the formfactor of SQLite.
  • by Gravis Zero ( 934156 ) on Sunday March 24, 2024 @12:44PM (#64340983)

    Will the use of Generative AI coding assistants more firmly entrench the status quo of the existing programming paradigms on whose codebases it's been trained?

    As "Generative AI coding assistants" progress, they will become more refined because people will need to correct all the errors it makes which will then become new data to be trained on. However, since it's likely that you are incorporating external source of code, it's going to depend on which sources are weighted to be the most influential in it's training model.

    Here are a few examples of differing data pool weighting methodologies:
    - projects with the most code churn: Smaller specialized programs (i.e. follow the Unix philosophy [wikipedia.org]) will have little influence. The paradigms used may change several time so it may be random.
    - projects that keep adding more code: Likely to have diminishing returns but could inadvertently become prized training data and not following any paradigm at all.
    - code that has a high level of developer participation: These may be the most likely to use paradigms that are maintainable. If the developers are typical then it will feedback the most into the model. In this case paradigm could become highly focused.

    Of course, this is all predicated on the initial AI being worth using which means programmers must at least believe it will save them time and want to donate their own code to the AI owner.

  • Are you guys idiots? Coding an entire application with prompts would take longer and be more asinine than, I dunno LEARNING TO FUCKING CODE. Coding is the fastest way to tell anything what to do. Otherwise you'll get pre-canned shit. It's like you tell a woman to make you a sandwich but she doesn't put enough bacon in it. You need to explicitly tell her "more bacon" and then inevitably she doesn't put enough mayo. It's better to provide detailed instructions than to go back and forth. Whenever you see an ar

    • Prompt your way into a useful modernized UI layer in a language that you do not know.

      Sounds tricky.
  • "...I'm currently using jq. In contrast to the complicated and custom jq syntax, I'm very familiar with SQL and use it almost daily."

    So, dude that uses sql all of the time would rather just hammer SQL into everything, vs., just learning how to use other tools. Do you have a plan than to use SQL to list files in a directory? Browse the web? Manipulate photos?

    If you think jq is complex, you're in the wrong field. Stop fucking with tools that just work already. It's not supposed to be simple en

"The medium is the massage." -- Crazy Nigel

Working...