I’m the guy who designs those. They pay me the big bucks to make sure a hacker feels at home when violating our Gibson, after all. We’re one big family here.
Even though comments are very helpful, often it’s even enough to name variables and methods/functions really good. At least do that. You don’t want i, j and value. Believe me. You want rowCount, colCount and deliveryOption instead. You just may not know it now, but you will, when it has to be changed in a few months.
Where comments are useful most is in explaining why the implementation is as it is. Otherwise smart ass (your future self) will come along, rewrite it just to realize there was indeed a reason for the former implementation.
Comments are good when you’re doing something weird to handle an edge case or something. But yeah most of the time clear variable names, and extracting complicated code to a dedicated and clearly named function, are enough.
There are only two hard things in Computer Science: cache invalidation and naming things.
C# is about right. LINQ was meant to make things easier, or at least the code easier to read. Instead, you gain this addiction to seeing how much functional logic you can fit into one line of code (or a single multi-line query) while still remaining readable.
I swear to god, companies are nowadays just picking the solution with the most buzzwords. Any compiler engineering student knows how to write a transpiler from one language to another, while getting this right is a cumbersome task, it still completly automated afterwards. Just hire a few compiler engineering phds and the job is done in at least half a year.
You want to translate COBOL to another language? That exists as a commercial product! The complexity is not the syntax though, it is the environment and subsystems surrounding the code. A lot of COBOL is designed for mainframe systems, and emulating a mainframe is complex.
You also end up with code that is still written as if it were COBOL. The syntax for COBOL is the easy part and that is all you can easily replace. Afterwards you’re still stuck with the way of working and mindset, both of which are quite peculiar.
The company I work for recently looked at all of this, and we decided not to translate our code.
Just make the devs learn the language if they don’t know it already. What kind of shitty mid to senior dev can’t learn a new language in a reasonable amount of time.
I think it’s a matter of expertise. I am stuck dealing with people who write Javascript/Typescript like it’s C# because they’re C# senior devs. It’s not world-ending until issues of speed, scale, or other “why we use best practices” raise their ugly heads. Then it is world-ending. I can only help with so many design standards when you still see everything show up in a classes-and-subclasses mindset with hard-to-catch concurrency bugs. I actually caught a developer trying to spin up a child process to wait on a socket response.
So in FinTech, I can imagine it becomes a bigger deal faster.
A view is a saved query that pretends it’s a table. It doesn’t actually store any data. So if you need to query 10 different tables, joining them together and filtering the results specific ways, a view would just be that saved query, so instead of “SELECT * FROM (a big mess of tables)” you can do “SELECT * FROM HandyView”
Basically scripts you can run on the fly to pull calculated data. You can (mostly) treat them like tables themselves if you create them on the server.
So if you have repeat requests, you can save the view with maybe some broader parameters and then just SELECT * FROM [View_Schema].[My_View] WHERE [Year] = 2023 or whatever.
It can really slow things down if your views start calling other views in since they’re not actually tables. If you’ve got a view that you find you want to be calling in a lot of other views, you can try to extract as much of it as you can that isn’t updated live into a calculated table that’s updated by a stored procedure. Then set the stored procedure to run at a frequency that best captures the changes (usually daily). It can make a huge difference in runtime at the cost of storage space.
It can really slow things down if your views start calling other views in since they’re not actually tables
They can be in some cases! There’s a type of view called an “indexed” or “materialized” view where the view data is stored on disk like a regular table. It’s automatically recomputed whenever the source tables change. Doesn’t work well for tables that are very frequently updated, though.
Having said that, if you’re doing a lot of data aggregation (especially if it’s a sproc that runs daily), you’d probably want to set up a separate OLAP database so that large analytical queries don’t slow down transactional queries. With open-source technologies, this is usually using Hive and Presto or Spark combined with Apache Airflow.
Also, if you have data that’s usually aggregated by column, then a column-based database like Clickhouse is usually way faster than a regular row-based database. These store data per-column rather than per-row, so aggregating one column across millions or even billions of rows (eg average page load time for all hits ever recorded) is fast.
A Chevy dealership in Watsonville, California placed an Ai chat bot on their website. A few people began to play with its responses, including making a sales offer of a dollar on a new vehicle source: …slashdot.org/…/car-buyer-hilariously-tricks-chev…
I think this vastly depends on if there’s malicious intent involved with it, and I mean this on both sides. in the case of what was posted they manipulated the program outside of its normal operating parameters to list a quote for the vehicle. Even if they had stated this AI platform was able to do quotes which for my understanding the explicitly stated it’s not allowed to do, the seller could argue that there is a unilateral mistake involved that the other side of the party knew about and which was not given to the seller or there is very clear fraudulent activity on the buyers side both of which would give the seller the ability to void the contract.
In the case of no buy side manipulation it gets more difficult, but it could be argued that if the price was clearly wrong, the buyer should have known that fact and was being malicious in intent so the seller can withdraw
Of course this is all with the understanding that the program somehow meets the capacity to enter a legally binding agreement of course
also fun fact, Walmart had this happen with their analytical program five or so years ago, and they listed the Roku streaming stick for ~50 less so instead of it being $60 it was listed as 12, all the stores got flooded with online orders for Roku devices because that’s a damn good deal however they got a disclaimer not soon after that any that came in at that price point were to be Auto canceled, which is allowed by the sites TOS
In my opinion, we shouldn’t waste time in the courts arguing over whether a claim or offer made by an algorithm is considered reasonable or not. If you want to blindly rely on the technology, you have to be responsible for its output. Keep it simple and let the corporations (and the people making agreements with a chatbot) shoulder the risk and responsibility.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.