because with SQL you know exactly what's being executed while with ORMs you don't/have to go through hoops to inspect the output/learn the ORM's inner workings
All of these. I wouldn't risk with someone changing some inner workings of some third party library fricking up thousands of bank accounts or introducing vulnerabilities.
>Dude, you can't just code PHP you need LARAVEL. >Dude, you can't just do raw socket queries you have to use *this trendy cloud-based API* >Dude, why do you run your own DNS? Just use google or cloudflare. >Bruh, nobody needs to run a SMTP server in 2022 just use gmail!
This is how I imagined PHP programmers wrote their codes.
<?php
$result = shell_exec("mysql -uroot db -e "select * from table where id='".$_GET["id"]."'"");
?>
I assume it's to have higher accountability given they have more direct control over their systems' construction and to reduce the scope for vulnerabilities because I recall ORM opens up more opportunities for such.
Boomers want muh job security through silos. There really isn't an argument for raw SQL over ORMs in the modern world.
People will larp about performance differences but there really isn't a significant difference aside from latency. Throughput isn't significantly impacted.
Simpler, easier to maintain, developers are cheaper, lower overhead compared to maintain a database and an main application, faster development times, the list could go on.
There's a reason why ORMs have become very popular.
Not a fan of ORMs but >they usually provide some alternate query interface that can be checked by the compiler at buildtime >they (presumably) make sure best practices are done for you (eg sanitising inputs, sensible defaults, utf8) >they provide some way to map between DB rows and your models >90% of the time the worse performance isn’t going to matter
The main argument for ORMs here is that I've spent enough time debugging and optimizing SQL code from 'professional developers' who claimed to be well versus in SQL that I would rather never let any of them write a query again.
>People will larp about performance differences but there really isn't a significant difference aside from latency. Throughput isn't significantly impacted.
This is an incredibly false statement, to the extent that this guy could be a shill and/or a complete moron. I've heard the same nonsense from PHP devs who can't code a single line of meaningful raw PHP code and only know how to operate in their framework playpens.
Financial stuff is more about latency than throughput, and ORMs introduce SUBSTANTIAL latency for nothing other than making it possible for morons to have an easier time dealing with SQL.
There's a reason why ORMs have become very popular.
>Simpler, easier to maintain,
False; if the database and respective queries are maintained by a truly competent professional such as myself, it is easier when there is no intermediary.
>developers are cheaper
True; ORMs allow you to hire generally incompetent morons and still get some kind of functional result, sometimes.
>lower overhead compared to maintain a database and an main application
False; a database is a method of storing data. The application(s) that rely upon it will always need to be maintained in a manner that works within the parameters of the database(s) being used.
>faster development times
False; a competent developer with expertise in databases will produce better results in the same time or faster as an ORM, without the limitations ORMs introduce.
ORM is OOP for database queries. OOP did not make C better by shifting from logical, procedural coding to a disjointed collection of "objects". The same is true for DBs.
>the list could go on.
Indeed, you can make up all kinds of imagined benefits.
>There's a reason why ORMs have become very popular.
Ahh yes, popularity... the ultimate determining factor of quality and whether or not a thing truly is better.
We needed our API to be able to work with any database provider. ORM is a natural choice for that as they tend to work with all the major database providers.
there's like 4 major database dialects. that's 4 classes using a standard repository pattern, and honestly nobody ever changes database tech so you don't actually need to do that unless you're writing something like jira that's going to deploy on somebody else's hardware.
2 years ago
Anonymous
>honestly nobody ever changes database tech
Bullshit they don't. I been involved in several migrations from Microshit to other platforms including Snowflake and Postgres
2 years ago
Anonymous
stop changing jobs every 2 years and you won't suffer this shit so often.
2 years ago
Anonymous
Does Snowflake actually do anything? Team here has been working on moving 'everything' from SQL Server to Snowflake and revolutionizing the company's data platform for two years now and I'm not aware of a single completed deliverable.
>Financial stuff is more about latency than throughput
Financial is hardly a normal use case. And I specifically said that latency is something that favors raw SQL.
>False; if the database and respective queries are maintained by a truly competent professional such as myself, it is easier when there is no intermediary.
This just screams of insecurity. You don't know how to use an ORM properly and so you make it sound like they are bad across the board.
>False; a competent developer with expertise in databases will produce better results in the same time or faster as an ORM, without the limitations ORMs introduce.
You say these things, but then you don't define what a "competent professional" is and you also didn't quantify development time. I stand by my statement that for 90% of CRUD web apps there is zero development benefit to using raw SQL over an ORM provided you have solid application logic - something you should have regardless of how the application talks to the database.
>Indeed, you can make up all kinds of imagined benefits.
Why not? You just did.
>Ahh yes, popularity... the ultimate determining factor of quality and whether or not a thing truly is better.
I suppose you only program in the one true programming language - LISP(or any other language). Who cares if nobody else uses it any more and you can't find developers who can write in it. Its THE one and ONLY.
I would expect most DBs in finance to be Lovecraftian horrors that can't be reasonably mapped to ORMs.
Besides, then you need to access it with different languages and raw SQL as well so you need a plain SQL definition of everything anyway.
My problem is that every time I think of a problem an ORM would solve I remember all the SQL code that's already written and the pain in the ass it would be to port it.
>Why does the financial industry prefer using raw SQL to modern ORM's?
I use raw SQL when I use databases. Performance and reducing latency of the application making the DB queries is the simplest reason. Any DB is already introducing substantial overhead as compared to a filesystem, with the benefit of keeping your data structured and standardized...it's generally unwise to add performance cost just to save some up-front development time, so that pajeets can continue to displace Americans.
SQL is simple enough. The additional layer of abstraction might not be that useful, especially when you need performance and ORMs tend to generate some really garbage queries sometimes. Especially shit like LINQ. I swear to god the only reason that shit works is because databases have been microoptimised to hell and back.
>because databases have been microoptimised to hell and back
There's also a cult of fools who tell you not to optimize your programs, instead, just get them to work... which is dumb advice because if you optimize as you go, you will spend more time initially but more often than not save time later down the line since you don't have to hunt down blocks of code that works, but isn't quite as good as it could be.
There's a cottage industry build around turdpress (wordpress) software optimization. Turdpress is perhaps one of the most bloated and sub-par examples of PHP where an initially shitty codebase is built upon with exponentially shittier code... so now they actually try to make the servers run turdpress faster by accounting for its deficiencies. That is just moronic...
>There's also a cult of fools who tell you not to optimize your programs, instead, just get them to work...
That's just the end-result of deadline-drive development. Optimising takes time, but thanks to middle managers pushing for deadlines it's easier to just push a feature and "optimise it later". Eventually people just start thinking that this is the norm and hence the 'cult'.
>That's just the end-result of deadline-drive development. Optimising takes time, but thanks to middle managers pushing for deadlines it's easier to just push a feature and "optimise it later". Eventually people just start thinking that this is the norm and hence the 'cult'.
I tell people who want to program as a profession to do it on a contractual basis, and in that contract you decide the pace. If the potential client makes unreasonable deadlines or something of that sort, negotiate something that works or just save optimizations for incremental versions.
Agreeing to program as an employee is generally a mistake, especially considering that people who are actually good at it are few and far between.
2 years ago
Anonymous
Problem is that in a lot of places being a contractor adds a lot of overhead people might not like. I.e. outside the US contractors have to do their own taxes, while companies tend to do it at least partially for salaried people. You have to get your own healthcare. Banks might do a double take when deciding loans because you don't have an official place of work. When covid hit contractors in the UK also weren't eligible for aid and stuff. There's risks of companies not paying out in a reasonable timeframe. Basically stuff like that. It also doesn't help that contractors are seen as a last resort option for pushing out doomed projects, so even if you get extra time, you still have a lot of shit to worry about.
But if you're the type of person who can deal with all of that bullshit then definitely. Contracting can be way more rewarding in every way.
2 years ago
Anonymous
>outside the US contractors have to do their own taxes
Well, you only pay tax if you received some benefit. We're not talking about "outside the US" here, obviously, and within the US taxes are voluntary. If you are a contractor the client would typically give you a 1099 for whatever you were paid. These are "earnings" and not "income" or "gross income". This is not taxable, and to further protect yourself from all tax liability you simply need to demand lawful money per 12 USC 411 within your contract, and on any instrument you endorse for 'payment'. Don't report "income" if you did not have any "income".
>while companies tend to do it at least partially for salaried people
All they do is report what they paid to you as "income", so they can write it off. They don't do your taxes for you nor is that a good reason to avoid contracting.
>You have to get your own healthcare.
Insurance is a scam, and to a large extent, so is "medicine" at large. Stop living in fear.
>Banks might do a double take when deciding loans because you don't have an official place of work.
Never had a problem with this; rent a mailbox. It's not that hard.
>When covid hit contractors in the UK also weren't eligible for aid and stuff.
You were never required to stop contracting either, were you? If you cucked to false "mandates" that's on you for being Godless and gutless.
>There's risks of companies not paying out in a reasonable timeframe.
That's why you set up a payment schedule with at least 20% up front. If they're not willing to pay to start, they'll probably be a problem later down the line. Write your contracts wisely to make enforcement of these things simpler.
>contractors are seen as a last resort option for pushing out doomed projects,
That would suggest they are viewed as particularly competent.
>Contracting can be way more rewarding in every way.
It is, but people lack confidence in themselves and so they choose to be wagecucks.
2 years ago
Anonymous
>I'm not driving, officer, I'm traveling
2 years ago
Anonymous
>US taxes are voluntary
oof
If you're practicing this you're lucky IRS is understaffed and underpaid. Contractor work is definitely taxable, and as far as IRS is concerned 1099 is definitely income. >We're not talking about "outside the US" here
I was just listing shit contractors have to deal with. They exist even outside the US. Not to mention any contractor worth their salt will also contract outside the US (remote). >Insurance is a scam, and to a large extent, so is "medicine" at large. Stop living in fear.
That's fun and all until something does happen. You do you. >Never had a problem with this; rent a mailbox. It's not that hard.
How is a mailbox going to help the fact that you don't have consistent income on file? Are you okay? >You were never required to stop contracting either, were you?
Literally every company was cutting contractors loose. Contractor jobs dried up and the competition was pretty bad at the time. This along with the taxation statement makes me think you haven't actually done IT contracting in the US. >Write your contracts wisely to make enforcement of these things simpler.
Sounds good on paper, more difficult to enforce in real life. You're not going to sue them over a delayed paycheck, it's usually not worth it.
2 years ago
Anonymous
>within the US taxes are voluntary
I guess you can choose to go to jail instead. Don't think I'd pick that; I like to be able to pick up the soap in the shower unmolested.
>which is dumb advice
Nah. If the code isn't working at all, optimizing that function one more time won't help. In many ways, the greatest optimization is going from "not working" to "working".
Choosing the right basic algorithm isn't optimizing in my book.
>Nah. If the code isn't working at all, optimizing that function one more time won't help. In many ways, the greatest optimization is going from "not working" to "working".
How would you optimize code that isn't working? Optimization implies you got the code to work and are seeking to improve its performance.
>Choosing the right basic algorithm isn't optimizing in my book.
There's often multiple ways to do a thing in terms of programming, and thus you will often have multiple algorithms to select from. It's a starting point, but not really what we're talking about here. Where did anyone say that was all there is to optimization of code?
Remember when Joshua Moon decided that the Laravel framework was the best choice to rewrite 8gag's software, and he got so frustrated with their shitty wrapper around the database that he forked the framework to make it do what he wanted?
https://github.com/laravel/framework/issues/10847
More importantly, why do ORMs target SQL databases instead of simpler key->value ones? Seems dumb to want an object model represented in code generated SQL instead of just code generating the appropriate code on top of a kv.... I never used an ORM by the way and I generally prefer using RocksDB or Leveldb instead of some DBMS, especially one with a forced relational data model.
because k/v is simpler
the main point of ORMs is just to avoid learning SQL, which is why the vast majority of ORM usage is in webshit, since most webshits refuse to use a language that isn't JS/PHP/CSS
It depends. In dotnet the idea is to have a unified query language for all database types, for stuff like parsing html/xml/excel docs and even for your algos.
>In dotnet the idea is to have a unified query language for all database types, for stuff like parsing html/xml/excel docs and even for your algos.
In my applications, I make database drivers which allow me to interface with commonly used DBs without having to make any changes to the code. Once you make a driver like this, you can use and reuse it in other applications. Any competent programmer would have a private library of code bits that they can drop into their programs.
Depends on which ORM you're talking about. If it's hip and basedshit like laravel or literally who nodejs ORM, then a big no. But established boomer library like Entity Core/Framework with linq, maybe.
I was a Dapper fan before just because of the significant performance advantage they used to have over EF Core, but nowadays they're almost on the same level. And if you know what you're doing, you can get your EF queries to be as efficient as raw SQL ones.
I work in the financial industry. It’s because SQL is so much more expressive than any ORM could ever be. Most analysts are running ad-hoc OLAP queries and SQL is very powerful in this regard.
>filezilla, not all boomers are moronic 10 year old wintoddlers
But I use filezilla in linux, you're telling me there's a superior application in linux???
>real boomers would use cgi
Wrong, the other anon is correct.
CGI's were only relevant for a minute before it got replaced by PHP.
Only thing cgi ever produced was guestbook's or contact forms that's it.
Where PHP does so much better.
>only relevant for a minute
cgi perl scripts were ubiquitous back then and php didnt really become dominant until like 2004. even today on plenty of commerce portals you'll request something deep within cgi-bin
Mostly so the DBA knows what's going to be executed at all times. Only applies when the database or organization is large enough to have DBAs. Otherwise you might as well use an ORM.
Because ORMs are over complicated nonsense invented by OOP weenies who are too brainlet to deal with relations. ORMs defeat the entire point of RDBs because every time you query at the object level you're grabbing tons of shit rather than just the stuff you need for what you're doing. You'll also get a tree view of your data instead of a list view, which means it's going to be more annoying and less efficient to work with.
this reminds me of a story boomers told me. back in the day, java was brand new and fresh, and IBM had implemented it on their OS/390 / z/OS systems. since poolang was the newest, sexiest enterprise craze, and the company has a mainframe systems, naturally they had to make something with it. COBOL boomers were so incompetent, making continuous data calls to the MF DBs, it would hang the system/LPAR. the proper way to have done it, was call once, and access in memory/temp file. what ended up happening was them building the frontend apps in java, the middleware in java and having the mainframe transform and send the data in files.
>Because ORMs are over complicated nonsense invented by OOP weenies who are too brainlet to deal with relations.
They've got some value, to generate the binding goop between the queries+result-sets and the OOP stuff. That used to be quite annoying to do (lots of boilerplate).
But abstracting away the query language itself isn't very valuable, as you lose much of the actual power of SQL that way. Non-trivial JOINs are when you are starting to actually use what the database can do.
You'll never move a substantial dataset between databases. That's just eye-wateringly expensive (in time and effort) to do. The ability to move your queries between DBs is therefore just theoretic.
because with SQL you know exactly what's being executed while with ORMs you don't/have to go through hoops to inspect the output/learn the ORM's inner workings
All of these. I wouldn't risk with someone changing some inner workings of some third party library fricking up thousands of bank accounts or introducing vulnerabilities.
Why would you prefer ORM's?
>Why would you prefer ORM's?
This.
>Dude, you can't just code PHP you need LARAVEL.
>Dude, you can't just do raw socket queries you have to use *this trendy cloud-based API*
>Dude, why do you run your own DNS? Just use google or cloudflare.
>Bruh, nobody needs to run a SMTP server in 2022 just use gmail!
homosexuals and their third-party intermediaries.
This is how I imagined PHP programmers wrote their codes.
<?php
$result = shell_exec("mysql -uroot db -e "select * from table where id='".$_GET["id"]."'"");
?>
You can actually find code like this in the wild, it seems to be common in embedded devices.
Easier to say "good knowledge of SQL" on a job posting rather than "good knowledge of this one orm that you might have never heard of"
Transactions.
I think it's just a question of performance. There's a performance cost to all ORMs.
I assume it's to have higher accountability given they have more direct control over their systems' construction and to reduce the scope for vulnerabilities because I recall ORM opens up more opportunities for such.
Boomers want muh job security through silos. There really isn't an argument for raw SQL over ORMs in the modern world.
People will larp about performance differences but there really isn't a significant difference aside from latency. Throughput isn't significantly impacted.
What's the argument for ORMs?
Simpler, easier to maintain, developers are cheaper, lower overhead compared to maintain a database and an main application, faster development times, the list could go on.
There's a reason why ORMs have become very popular.
Literally none of these is true.
>There's a reason why ORMs have become very popular.
Yeah, OO used to be some sort of religion and was seen as a solution to every problem.
Not a fan of ORMs but
>they usually provide some alternate query interface that can be checked by the compiler at buildtime
>they (presumably) make sure best practices are done for you (eg sanitising inputs, sensible defaults, utf8)
>they provide some way to map between DB rows and your models
>90% of the time the worse performance isn’t going to matter
The main argument for ORMs here is that I've spent enough time debugging and optimizing SQL code from 'professional developers' who claimed to be well versus in SQL that I would rather never let any of them write a query again.
>People will larp about performance differences but there really isn't a significant difference aside from latency. Throughput isn't significantly impacted.
This is an incredibly false statement, to the extent that this guy could be a shill and/or a complete moron. I've heard the same nonsense from PHP devs who can't code a single line of meaningful raw PHP code and only know how to operate in their framework playpens.
Financial stuff is more about latency than throughput, and ORMs introduce SUBSTANTIAL latency for nothing other than making it possible for morons to have an easier time dealing with SQL.
>Simpler, easier to maintain,
False; if the database and respective queries are maintained by a truly competent professional such as myself, it is easier when there is no intermediary.
>developers are cheaper
True; ORMs allow you to hire generally incompetent morons and still get some kind of functional result, sometimes.
>lower overhead compared to maintain a database and an main application
False; a database is a method of storing data. The application(s) that rely upon it will always need to be maintained in a manner that works within the parameters of the database(s) being used.
>faster development times
False; a competent developer with expertise in databases will produce better results in the same time or faster as an ORM, without the limitations ORMs introduce.
ORM is OOP for database queries. OOP did not make C better by shifting from logical, procedural coding to a disjointed collection of "objects". The same is true for DBs.
>the list could go on.
Indeed, you can make up all kinds of imagined benefits.
>There's a reason why ORMs have become very popular.
Ahh yes, popularity... the ultimate determining factor of quality and whether or not a thing truly is better.
>competent professional such as myself
lol
We needed our API to be able to work with any database provider. ORM is a natural choice for that as they tend to work with all the major database providers.
there's like 4 major database dialects. that's 4 classes using a standard repository pattern, and honestly nobody ever changes database tech so you don't actually need to do that unless you're writing something like jira that's going to deploy on somebody else's hardware.
>honestly nobody ever changes database tech
Bullshit they don't. I been involved in several migrations from Microshit to other platforms including Snowflake and Postgres
stop changing jobs every 2 years and you won't suffer this shit so often.
Does Snowflake actually do anything? Team here has been working on moving 'everything' from SQL Server to Snowflake and revolutionizing the company's data platform for two years now and I'm not aware of a single completed deliverable.
>Financial stuff is more about latency than throughput
Financial is hardly a normal use case. And I specifically said that latency is something that favors raw SQL.
>False; if the database and respective queries are maintained by a truly competent professional such as myself, it is easier when there is no intermediary.
This just screams of insecurity. You don't know how to use an ORM properly and so you make it sound like they are bad across the board.
>False; a competent developer with expertise in databases will produce better results in the same time or faster as an ORM, without the limitations ORMs introduce.
You say these things, but then you don't define what a "competent professional" is and you also didn't quantify development time. I stand by my statement that for 90% of CRUD web apps there is zero development benefit to using raw SQL over an ORM provided you have solid application logic - something you should have regardless of how the application talks to the database.
>Indeed, you can make up all kinds of imagined benefits.
Why not? You just did.
>Ahh yes, popularity... the ultimate determining factor of quality and whether or not a thing truly is better.
I suppose you only program in the one true programming language - LISP(or any other language). Who cares if nobody else uses it any more and you can't find developers who can write in it. Its THE one and ONLY.
I would expect most DBs in finance to be Lovecraftian horrors that can't be reasonably mapped to ORMs.
Besides, then you need to access it with different languages and raw SQL as well so you need a plain SQL definition of everything anyway.
Performance
My problem is that every time I think of a problem an ORM would solve I remember all the SQL code that's already written and the pain in the ass it would be to port it.
>2022
>ORMs are relevant
>2032
>ORMs of ORMs are relevant
>2042
>ORMs of ORMs of ORMs are relevant
>2052
>ORMs of ORMs of ORMs of ORMs are relevant
>FileZilla
so much SOVL! my friend still works at a shop that uses it for some of the frontline staff.
>boomers
>php
That's Gen X at the oldest. Boomers did Cobol and Fortran
I don't think boomer means what you think it means here
>Why does the financial industry prefer using raw SQL to modern ORM's?
I use raw SQL when I use databases. Performance and reducing latency of the application making the DB queries is the simplest reason. Any DB is already introducing substantial overhead as compared to a filesystem, with the benefit of keeping your data structured and standardized...it's generally unwise to add performance cost just to save some up-front development time, so that pajeets can continue to displace Americans.
because it just works why would you want to use anything else ?
>because it just works why would you want to use anything else ?
Plain SQL doesn't work anymore?
SQL is simple enough. The additional layer of abstraction might not be that useful, especially when you need performance and ORMs tend to generate some really garbage queries sometimes. Especially shit like LINQ. I swear to god the only reason that shit works is because databases have been microoptimised to hell and back.
>because databases have been microoptimised to hell and back
There's also a cult of fools who tell you not to optimize your programs, instead, just get them to work... which is dumb advice because if you optimize as you go, you will spend more time initially but more often than not save time later down the line since you don't have to hunt down blocks of code that works, but isn't quite as good as it could be.
There's a cottage industry build around turdpress (wordpress) software optimization. Turdpress is perhaps one of the most bloated and sub-par examples of PHP where an initially shitty codebase is built upon with exponentially shittier code... so now they actually try to make the servers run turdpress faster by accounting for its deficiencies. That is just moronic...
>There's also a cult of fools who tell you not to optimize your programs, instead, just get them to work...
That's just the end-result of deadline-drive development. Optimising takes time, but thanks to middle managers pushing for deadlines it's easier to just push a feature and "optimise it later". Eventually people just start thinking that this is the norm and hence the 'cult'.
>That's just the end-result of deadline-drive development. Optimising takes time, but thanks to middle managers pushing for deadlines it's easier to just push a feature and "optimise it later". Eventually people just start thinking that this is the norm and hence the 'cult'.
I tell people who want to program as a profession to do it on a contractual basis, and in that contract you decide the pace. If the potential client makes unreasonable deadlines or something of that sort, negotiate something that works or just save optimizations for incremental versions.
Agreeing to program as an employee is generally a mistake, especially considering that people who are actually good at it are few and far between.
Problem is that in a lot of places being a contractor adds a lot of overhead people might not like. I.e. outside the US contractors have to do their own taxes, while companies tend to do it at least partially for salaried people. You have to get your own healthcare. Banks might do a double take when deciding loans because you don't have an official place of work. When covid hit contractors in the UK also weren't eligible for aid and stuff. There's risks of companies not paying out in a reasonable timeframe. Basically stuff like that. It also doesn't help that contractors are seen as a last resort option for pushing out doomed projects, so even if you get extra time, you still have a lot of shit to worry about.
But if you're the type of person who can deal with all of that bullshit then definitely. Contracting can be way more rewarding in every way.
>outside the US contractors have to do their own taxes
Well, you only pay tax if you received some benefit. We're not talking about "outside the US" here, obviously, and within the US taxes are voluntary. If you are a contractor the client would typically give you a 1099 for whatever you were paid. These are "earnings" and not "income" or "gross income". This is not taxable, and to further protect yourself from all tax liability you simply need to demand lawful money per 12 USC 411 within your contract, and on any instrument you endorse for 'payment'. Don't report "income" if you did not have any "income".
>while companies tend to do it at least partially for salaried people
All they do is report what they paid to you as "income", so they can write it off. They don't do your taxes for you nor is that a good reason to avoid contracting.
>You have to get your own healthcare.
Insurance is a scam, and to a large extent, so is "medicine" at large. Stop living in fear.
>Banks might do a double take when deciding loans because you don't have an official place of work.
Never had a problem with this; rent a mailbox. It's not that hard.
>When covid hit contractors in the UK also weren't eligible for aid and stuff.
You were never required to stop contracting either, were you? If you cucked to false "mandates" that's on you for being Godless and gutless.
>There's risks of companies not paying out in a reasonable timeframe.
That's why you set up a payment schedule with at least 20% up front. If they're not willing to pay to start, they'll probably be a problem later down the line. Write your contracts wisely to make enforcement of these things simpler.
>contractors are seen as a last resort option for pushing out doomed projects,
That would suggest they are viewed as particularly competent.
>Contracting can be way more rewarding in every way.
It is, but people lack confidence in themselves and so they choose to be wagecucks.
>I'm not driving, officer, I'm traveling
>US taxes are voluntary
oof
If you're practicing this you're lucky IRS is understaffed and underpaid. Contractor work is definitely taxable, and as far as IRS is concerned 1099 is definitely income.
>We're not talking about "outside the US" here
I was just listing shit contractors have to deal with. They exist even outside the US. Not to mention any contractor worth their salt will also contract outside the US (remote).
>Insurance is a scam, and to a large extent, so is "medicine" at large. Stop living in fear.
That's fun and all until something does happen. You do you.
>Never had a problem with this; rent a mailbox. It's not that hard.
How is a mailbox going to help the fact that you don't have consistent income on file? Are you okay?
>You were never required to stop contracting either, were you?
Literally every company was cutting contractors loose. Contractor jobs dried up and the competition was pretty bad at the time. This along with the taxation statement makes me think you haven't actually done IT contracting in the US.
>Write your contracts wisely to make enforcement of these things simpler.
Sounds good on paper, more difficult to enforce in real life. You're not going to sue them over a delayed paycheck, it's usually not worth it.
>within the US taxes are voluntary
I guess you can choose to go to jail instead. Don't think I'd pick that; I like to be able to pick up the soap in the shower unmolested.
>which is dumb advice
Nah. If the code isn't working at all, optimizing that function one more time won't help. In many ways, the greatest optimization is going from "not working" to "working".
Choosing the right basic algorithm isn't optimizing in my book.
>Nah. If the code isn't working at all, optimizing that function one more time won't help. In many ways, the greatest optimization is going from "not working" to "working".
How would you optimize code that isn't working? Optimization implies you got the code to work and are seeking to improve its performance.
>Choosing the right basic algorithm isn't optimizing in my book.
There's often multiple ways to do a thing in terms of programming, and thus you will often have multiple algorithms to select from. It's a starting point, but not really what we're talking about here. Where did anyone say that was all there is to optimization of code?
LINQ is God's gift to man you monkey
Don't enable verbose logging for LINQ if you want to be able to sleep at night.
because most ORMs suck fat dick and are unironically more painful to use than even a shitty SQL database.
ORMs work fine with simple queries, but get very very complicated when you want to do non-trivial queries.
Remember when Joshua Moon decided that the Laravel framework was the best choice to rewrite 8gag's software, and he got so frustrated with their shitty wrapper around the database that he forked the framework to make it do what he wanted?
https://github.com/laravel/framework/issues/10847
Kek. Isn't he rewriting it in Rust now?
More importantly, why do ORMs target SQL databases instead of simpler key->value ones? Seems dumb to want an object model represented in code generated SQL instead of just code generating the appropriate code on top of a kv.... I never used an ORM by the way and I generally prefer using RocksDB or Leveldb instead of some DBMS, especially one with a forced relational data model.
because k/v is simpler
the main point of ORMs is just to avoid learning SQL, which is why the vast majority of ORM usage is in webshit, since most webshits refuse to use a language that isn't JS/PHP/CSS
It depends. In dotnet the idea is to have a unified query language for all database types, for stuff like parsing html/xml/excel docs and even for your algos.
>In dotnet the idea is to have a unified query language for all database types, for stuff like parsing html/xml/excel docs and even for your algos.
In my applications, I make database drivers which allow me to interface with commonly used DBs without having to make any changes to the code. Once you make a driver like this, you can use and reuse it in other applications. Any competent programmer would have a private library of code bits that they can drop into their programs.
Depends on which ORM you're talking about. If it's hip and basedshit like laravel or literally who nodejs ORM, then a big no. But established boomer library like Entity Core/Framework with linq, maybe.
I was a Dapper fan before just because of the significant performance advantage they used to have over EF Core, but nowadays they're almost on the same level. And if you know what you're doing, you can get your EF queries to be as efficient as raw SQL ones.
I work in the financial industry. It’s because SQL is so much more expressive than any ORM could ever be. Most analysts are running ad-hoc OLAP queries and SQL is very powerful in this regard.
Show me any type of SQL query and i'll translate it for you in ef/LINQ.
>filezilla, not all boomers are moronic 10 year old wintoddlers
But I use filezilla in linux, you're telling me there's a superior application in linux???
>real boomers would use cgi
Wrong, the other anon is correct.
CGI's were only relevant for a minute before it got replaced by PHP.
Only thing cgi ever produced was guestbook's or contact forms that's it.
Where PHP does so much better.
>only relevant for a minute
cgi perl scripts were ubiquitous back then and php didnt really become dominant until like 2004. even today on plenty of commerce portals you'll request something deep within cgi-bin
ORMs are shit. Just use some simple SQL generators.
Mostly so the DBA knows what's going to be executed at all times. Only applies when the database or organization is large enough to have DBAs. Otherwise you might as well use an ORM.
I don't know why you would even need ORM, sql is so easy once you learn the fundamentals.
Because ORMs are over complicated nonsense invented by OOP weenies who are too brainlet to deal with relations. ORMs defeat the entire point of RDBs because every time you query at the object level you're grabbing tons of shit rather than just the stuff you need for what you're doing. You'll also get a tree view of your data instead of a list view, which means it's going to be more annoying and less efficient to work with.
this reminds me of a story boomers told me. back in the day, java was brand new and fresh, and IBM had implemented it on their OS/390 / z/OS systems. since poolang was the newest, sexiest enterprise craze, and the company has a mainframe systems, naturally they had to make something with it. COBOL boomers were so incompetent, making continuous data calls to the MF DBs, it would hang the system/LPAR. the proper way to have done it, was call once, and access in memory/temp file. what ended up happening was them building the frontend apps in java, the middleware in java and having the mainframe transform and send the data in files.
>Because ORMs are over complicated nonsense invented by OOP weenies who are too brainlet to deal with relations.
They've got some value, to generate the binding goop between the queries+result-sets and the OOP stuff. That used to be quite annoying to do (lots of boilerplate).
But abstracting away the query language itself isn't very valuable, as you lose much of the actual power of SQL that way. Non-trivial JOINs are when you are starting to actually use what the database can do.
You'll never move a substantial dataset between databases. That's just eye-wateringly expensive (in time and effort) to do. The ability to move your queries between DBs is therefore just theoretic.
ORMs are dogshit. Biggest meme reinventing the wheel anti pattern if I've ever seen one.
easier to manipulate, for ~~*(reasons*~~)