Comments by "xybersurfer" (@xybersurfer) on "The Stockholm Syndrome of SQL | Prime Reacts" video.

  1. SQL is not a string only language. SQL only tends to become a string inside other languages, as a result of the way most languages integrate with SQL
    201
  2.  @fullmontis  i think there is plenty of room for improvement in DBs. change for the sake of change is bad, but i could see DBs improving as part of a bigger change
    11
  3. yep. i think it's okay to reinvent the wheel every so often, but i hate it when so many other things get worse in the new way of doing things (regressions). i think it's partially because of the way humans developed software (fragmentation & NIH)
    7
  4. ​ @FatfighterXD1  i have plenty of experience myself, and i can relate to there being cranky old engineers. i tend to follow the status quo to not take any unnecessary risks (and avoid getting fired), but i'm still aware of many of the limitations of my tools. i like to think that i can reasonable discern what is mostly hype, although we all get at least a little tunnel vision, after getting comfortable with the tools. but some people start to think the tools are perfect, or don't even want to think about their limitations. these are the people that get cranky. it's 2 different mindsets. one is passionate and typically more knowledgeable and open minded, and the other is mostly just doing a job. i've met both kinds of old engineers
    6
  5. i disagree. generally, a relational database is typically a better fit that a document database
    4
  6.  @danieltoth714  well said
    3
  7. yeah. and the sad thing is that the article even explains how to pronounce SQL
    3
  8. i have encountered these. a nice thing is that you get access to .NET functions, and from the outside you get a stack trace when there is an exception. but to me it feels like a step in the wrong direction, as it goes against the declarative nature of SQL. i personally prefer to have as much as possible in queries, so that things are as stateless as possible. so similarly i also don't like people creating stored procedures when a SELECT query would would have done (which i see way too often)
    2
  9.  @alexaneals8194  right. i prefer the SELECT statements to be Views or UDFs so that they can be used as part of other queries (so in the database). indeed application languages limit who can troubleshoot, good point
    2
  10. ORMs are make your life easier for most simple queries, but they occasionally can't be used for less typical queries. in those situations, i usually drop to using SQL syntax (a lot of ORMs allow this on the same database connection, which is nice for transactions). that's the nice thing. you don't have to choose between ORMs and SQL syntax. just use both
    2
  11. maybe. although Zig, Java, C, assembly are all Imperative (stepwise). you might want to try a Functional programming language. that was a huge eye opener for me. especially: - lambda calculus / higher-order functions (declaring and using a function on the same line feels natural) - typically way less lines of code needed than - recursion (languages with tail call optimization are great, as they allow for endless recursion without blowing the stack) - how in theory each call is an expression that fits on 1 line that can be rewritten on the next line (like maths) - and how (usually) avoiding a global mutable state makes things more predictable - pipe operator - usually these languages have good type checking, in their compiler (the statically typed ones) - and a few more topics (not that many) it basically taught me that being productive, is a more interesting challenge than trying to go more low level. i'm mostly familiar with F# because it comes with .NET and Visual Studio Community (nice debugger) and i'm also a little bit familiar with Haskell. SQL queries (as discussed in this video) was also an eye opener for me, as it's queries are in a Declarative langage. which means that in theory you don't have to explain to the computer how to do something, but just what you want done (which is kind of unique). although this only works in a database (maybe things like LINQ-to-Objects in .NET are an exception that allow you to "query" your program's data structures), it's still useful because a database is at the center of many applications. speaking of databases, designing a database with an ER diagram was another eye opener for me, as it taught how data is organized in a simple and intuitive way (instead of trying to remember the all the normal forms). it taught me to quickly recognize design mistakes in databases. i love tools that allow me to draw a database and automatically generate the SQL commands that create it (my favorite is DeZign by Datanamic, but there are many others). Zig looks interesting too. haven't tried it myself, but i do see similarities to C which i am familiar with. i think assembly is interesting to see a few times to get an idea of how it typically works, but the problem is that it's not portable like higher/more-abstract languages like everything you listed and functional programming. it really depends on what you want to do though. i'm not self taught like you though, so good job on that. sorry for the long reply. programming is just a really interesting topic, and i didn't want to leave anything out.
    2
  12.  @alexaneals8194 admittedly, i usually only put SQL SELECT statements, that i share across applications, in the database
    1
  13.  @aoeuable  true. but i do have a small annoyance: support for inheritance is usually very limited in a database
    1
  14.  @isodoubIet  i don't think that's an SQL problem though. that's more to do with how other languages integrate with it. but still SQL could use some improvements
    1
  15. how often could the complaining be? it can't be that bad
    1
  16. interesting. i need to look into Datalog
    1
  17.  @felixjohnson3874  it's because Mozilla has a certain brand, so i guess that comes with the territory. people also idolize Apple but in a different way, it's used more like a status symbol
    1
  18. exactly
    1
  19.  @TheSulross  wouldn't that require implementing a database?
    1