skysight-inc/HackerNews huggingface dataset:
Imperative code is complicated when dealing with data, so we abstract imperative code into SQL.
SQL is complicated so we abstract it from SQL back into imperative code via an ORM.

Of course it's backwards.

It's like one of the biggest legacies of web development next to javascript, html and CSS. SQL is a very specific way to think about data and a very high level and leaky abstraction. So high and leaky, that you literally need to look at the query plan in order to optimize sql queries. If Database IO is the bottleneck for web development the best abstraction for this area is most likely a zero cost abstraction (rust for example). Instead we have SQL and we create a generation of SQL hackers who memorize a bunch of technology specific hacks to try to get things to work. Why is SELECT * bad? It's a hack you memorized, a leaky abstraction.

I'm not saying schema-less is better hear me out. I'm saying SQL is a bad API. You can probably make some api language that's more explicit and imperative on top of something like postgres. Change the API itself don't write something on top of it.

Either way, an ORM on top of SQL is like what type script is to javascript. You know when they make an API on top of an API it's to cover up something that doesn't work well. Unless it's a zero cost compilation such fixes only make performance worse.

If you insist on using some abstraction on top of sql the way to do it with zero cost is an api that is bijective to the syntax of SQL itself. Type script I'm guessing is relatively isomorphic to javascript, so it works out.
Insertion and deletion from DEQ indeed is linear, but in all of DEQs in the structure only one (!) needs insertion, the rest are just popping/pushing front/back.
Design by committee at it finest.
I tried the pill and eventually turned it off. Android 10's navigation seems a lot more fluid, though maybe a little less discoverable.

edit: to be clear, I now have the option for traditional 3 buttons, 2 buttons (pill), and no buttons (all gestures).
It's not intellectually dishonest. Most people know about that ruling already.
My god that would. Be both horrific and hysterical at the same time.

Btw, how do you wash off UV powder... asking for a friend....
Just because the content of a comment doesn't agree with you, that doesn't make it not constructive.
I think the data-structure is careful to make sure the main array is at most SQRT(N) and all linked queues also SQRT(N).

It's a neat restructuring of the vector into a SQRT(N) * SQRT(N) arrangement.
A hundred times this. Nothing is going to change until they're hit where it hurts more: profits. Enough people taking note of all products showed during or very near mass shootings coverage and then refusing to buy them, possibly informing the companies about the choice, would send quite a message.
Maybe I’m in the minority, but I’ve found that if the right ORM fits your brain, it can be incredibly useful for a lot of CRUD operations, especially if it offers escape hatches to lower levels of the abstractions; ultimately down to raw SQL.

SQLAlchemy for Python is that for me. I find it incredibly expressive and allows me to write complex queries that are readable, maintainable, and perfomant. Yes, it requires learning, but it’s the right tool for the job, personally.
Growing a SaaS: Avoid Confusing Dual Offers
Such a movement would need to be popular enough to bring its own additional attention to shootings. In order to spread information about the details of the news and the advertisers, it would effectively become an alternate news source about them.
They mention the case where the ORM shadows the db schema. The argument isn't terribly salient, it's not like you can't build type checking in, it just means more work if that's what you want to do. Essentially according to the author the only way to do it right if you have an existing db is to write all queries from scratch.

My preferred solution for existing DBs is Ruby's Sequel or ROM if you want to go nuts. But I'm a diehard Rails lover and will choose ActiveRecord over all other solutions if I can. To me there's only one decent ORM and everything else is either good for special purposes or junk.
Venus’ Ocean of Air and Clouds
We've found good luck w/ PyPika as well.
Most ORMs I have used are by definition a leaky abstraction: an inferior and insufficient representation for the underlying language at which they try to improve upon.

In addition, ORMs greatly increase the surface area for troubleshooting. Instead of just being able to run and profile a query, you now need someone who is experienced in the internals of the ORM and how it "plans" a certain query. Of course, because ORMs do not understand how the data is actually laid out, when they say "plan" they mean create the SQL string.

So in place of a query you will need to learn the conventions of the particular ORM, leaks and all, and how that maps to the SQL. Then you will still need to understand how that SQL actually interacts with the table schema.

The end result is normally one backend person who is very territorial over their code, and who acts as a bottleneck for the rest of the team. If you're using an ORM I'm sure you already know who this guy is...
AI Hardware Summit Sept. 17-18
> was good at SQL and who quit over trying to work with a large aggregation query in SQLAlchemy

Is this really a good example? Sqlalchemy allows you to use raw queries when you want to. Just like almost every orm out there.
> I think the opposite is True: SQL is backward to a programming language. Creating statements by concatenating strings? An ORM makes real objects and types you can actually instantiate and use, or even type check.

That you view the situation as ORM or concatenation terrifies me. No wonder SQL injection remains so prevalent.

Prepared statements are what you use here. You provide a query with placeholders for the values you want to fill in, and then you call that prepared statement with the arguments you need. These are typically type-checked and hardened against SQL injection, but of course you should verify with your particular language/library combination.
Google doesn't make trademark law nor do they get decide if some behavior follows the law or not. Google obviously considers it okay; they get to profit from both the aggrieved party and the malicious party. The question of whether a business practice is illegally unethical should not be determined by a person who profits from it.
I'd like to see the performance of growing the list (a common scenario):

ArrayList list = new ArrayList();
for (int i = 0; i < N; i++) {
list.add(i);
}

(Forgive me, Java is my mother tongue).
As someone who's used both SQL and Django ORM, I could ask: "Why SQL is so backward?"

Here's a datapoint I experienced:

The company I worked for didn't trust the Django ORM for DB migrations. They thought they could do it by hand. After lots of deployment failures where the migration script worked in the dev environment but failed in the prod environment, we switched to using django migrations. Haven't had an issue since.

The author even admits that migrations are a hard problem, but yet, he has no solutions other than just using raw SQL.

Edited to Add:

In Django, these migrations are handled pretty well with a single command to make the migrations. In SQL, someone would probably have to spend some time testing, and then would need to be reviewed in the PR.
Autonomic | Palo Alto, CA or Detroit, MI or Toronto, ON | Full-Time, Onsite | https://autonomic.ai
Autonomic is building the Transportation Mobility Cloud: the platform for the transportation ecosystem. Great team, amazing culture, working on bleeding edge stuff.

Here are our open roles:

Manager of Developer Relations, Technical Support Engineer, Support Engineer, AWS Core Services Engineer, Field Software Engineer, Kubernetes Engineer, Senior Infrastructure Engineer, Senior Security Engineer, Senior Software Engineer (multiple teams), Software Architect, Software Engineer - Kafka, Product Manager

I'm a PM here. You can reach me on khaled@autonomic.ai or apply directly with the link below.

https://boards.greenhouse.io/autonomic?t=gelirj2#.Wpc6a5PwaL...
We are currently having some parliamentary inquiries in Australia to start a nuclear program. I have always been against talk of nuclear on two main grounds [0,1] (but against decommissioning existing plants).

However a local economist has argued (and costed) for a way to make nuclear viable in this country. Tldr: a carbon price.

https://johnquiggin.com/2019/08/23/what-price-nuclear-power/

[0] Time/Cost (in aus, this means 30yrs+ & tens of billions). Though in CA, this may be considerably less, it is unlikely to be as cheap short term as renewables or gas.

[1] All the mines and dumping grounds in oz are in the middle of sensitive habitats or traditional owners lands.
I love that this is being downvoted you Chinese piece of shit shills. Keep going! The more it’s downvoted the more i win!! Yay communist robot shill pieces of shit!
> Why anyone puts a max 10 W port on a desk basically hand-tailored for the SV 4-ft desk open office

If the people are the same, you have answered your own question. Open Offices are not a bright idea in the first place; not sure why you would be expecting anything other than similar ideas :)
C# obviously has a very different design philosophy than Go, but its releases are moving along at a similar (and IMO, reasonable) pace.
All of these are a possibility But we need to significantly step up our citizenship game.
For simple queries, sure SQL is great but it is not composable. Ideally you want to send your whole query to the database at once and for a complex statement that may mean many many lines of reasonably complex joins etc. With Sqlalchmey you can write a bunch of simple components and join them together for submission at once instead of having a thousand lines of SQL that can be hard to read. You can re-use parts and even come back later and understand clearly what is happening. How do I know this? 25 years of writing SQL and at leat 6 using SQLAlchemy. A lot of the time I will still compose and test in SQL using, say DataGrip or psql, then build an SQLAlchemy query from that. This guy should look at alembic too. It has it's faults (like the half module half executable runtime), but it solves most of the problems of just having a folder with a million naively numbered SQL scripts like managing up and down versions as well as branches.
How do you avoid leaking business logic into database stored procedures? Sounds like you would now have two sources of truth, application logic, and database stored procedures.
Of all the ethical considerations of betting, not gambling seems like the most peculiar.
Chinese people who show sympathy for HK protests risk getting doxxed by friends
The Affinity Project (TAP) | Boston, MA - ONSITE | Full-Time | https://theaffinityproject.com/

We are hiring frontend (Vue, React), backend (Node, Golang), and senior full-stack engineers to help transform the terrain of digital engagement technology. We're building tools to foster genuine communication around what we believe defines people best – the content they love. You’ll joining an engineering team with backgrounds from having built the world’s most trafficked eSports sites to having run the largest Bitcoin mining pools in existence.

Technologies: Vue, React, MongoDB, Node, Golang, PostgreSQL, AWS, Heroku

If interested, please reach out to: atian@sidekicks.com
ORMHate is nothing new under the sun. Martin Fowler wrote a more balanced article about the issue years ago https://www.martinfowler.com/bliki/OrmHate.html
Not sure if you were trying to be funny.. but I find this hilarious :P
Sure.

You can write Velocity templates for integration responses.

Normally they are JSON because that's what all the AWS services return and API-Gateway just passes them along.

But you could write something like this:

#set($pets = $input.path('$'))
<html lang="en">
<head>
<meta charset="utf-8">
<title>Pets</title>
</head>
<body>
<table>
<th>ID</th>
<th>Type</th>
<th>Price</th>
#foreach($pet in $pets)
<tr>
<td>$pet.id</td>
<td>$pet.type</td>
<td>$pet.price</td>
</tr>
#end
</table>
</body>
</html>
Those units should be kWh/year, not kW/year (and kWh/d in the article).

(Though personally I'd just use Watts exclusively, and ignore the per day and per year figures.)
Here is a nice 2 bed condo in Chelsea for $199k. https://www.zillow.com/homedetails/570-Fieldstone-Cir-N-Chel... Lots of tech around to indulge your side hussle.
So, I've seen this go back and forth so many times, and I've come to the conclusion that the two extremes are irreconcilable. Not because they're incorrigible, but because they represent two very different ways of using a database.

For some, the database is not actually a database, per se, it's just a place to persist state. Usually folks in this camp think in an object-oriented way. They haven't read Codd's paper, they don't care about the relational algebra, they just want some way to take bags of properties and stick them somewhere that offers random access with good performance and is reasonably unlikely to not spontaneously erase data. If you're in this camp, ORM works great, because there isn't really much of an object/relational impedance situation in the first place. The data store wasn't structured in a way that creates one, there's no need burn a bunch of effort on doing so, and dragging in the whole relational way of doing things is like dragging a wooden rowboat on a hike through the forest because you'd like to use it to go fishing on the off chance you find a nice pond.

Others see a lot of value in the relational model. They're willing to put a bunch of time and effort into structuring the data and organizing the indexes in ways that will allow you to answer complex, possibly unanticipated questions quickly and efficiently. They, too, hate the syntax for recursive common table expressions, but are willing to hold their nose and use them anyway, for various reasons, but mostly because people think you're really cool when you can spend 30 minutes and make something go 2-3 orders of mangnitude faster than it used to. They don't think of the data in terms of bags of properties, they think of it in terms of tuples and relations and a calculus for rearranging them in interesting and useful ways. For them, there is potentially a huge problem with object/relational impedance; the data's organized in ways that just don't fit cleanly into Beans.

The thing is, neither of these ways of using a database is wrong. Each has it strengths and weaknesses. The trick is figuring out which way fits your business needs. Well, that's the easy trick. The hard trick comes when someone on your team doesn't understand this, believes there is one universal solution that will work for everyone, and is hellbent on jamming the One Righteous and Holy Peg, which happens to be square, into a round hole.
There were multiple literal questions embedded in his rhetoric; which without answers, invalidate the author's solution.
It is a lofty goal. I've been told by coworkers, "No one can remember the entire language." and then went and did it anyways.

Yes, I still have to look up libraries for, eg pip, and I haven't gotten to the level of knowing every compiler error yet.

But it is very much a doable goal. Especially given that knowledge transfers between languages and libraries. Once you learn the thought process of the dev who wrote it, you can guess how they did or are going to do everything after that, creating a short cut where you can guess and usually always guess the right answer. It's much quicker than using SO.
Yes and No. Yes in that it is still relatively obscure. I mean there have been plenty of cool Forth systems built, but I'd wager more Python gets built daily than the entirety of Forth code. Does that really matter though? Not really. It isn't a single language or even a family of languages like Lisp (Common Lisp, Racket, Clojure... etc). Rather, Forth is an idea and loose federation of philosophy concerning how to best tie primitives [written in something like Assembly or C (you want a low level language for speed and simplicity), but F#, Common Lisp, Clojure, Python...etc have all been used to write Forths] to code actually written in Forth. There is no traditional compiler and usually not too many data structures outside of the stack which is used for everything. Forth goes for extreme simplicity. There are some commercial vendors and products (SwiftForth, VFXForth, 8th), but the philosophy of Charles Moore was to just write what you need for the project. It was never really meant to be Java.
Sounds like maybe Candidiasis.
Every project I've seen that refused to use an ORM in favor of their own home grown solution was worse off for doing so. Almost every time someone claims that the ORM can't be used, I would point out how it could and that code became simpler and easier to maintain. If they read the documentation and used a bit of creativity instead of fighting against their tools, they wouldn't be left with such a mess.

This post reads to me as the author not having the proper ability to structure and plan their projects so they blame their tools instead of themselves. So instead of understanding limitations and tradeoffs, they try to build their own magic lamp that solves every problem under the sun.
Lately it seems like it would be most efficient to introduce the optional syntax from some modern languages. How about: "U?S?B?".
Wait a second. The back button is being replaced with a swipe from the left edge of the screen???

What if my phone is really wide? What if I miss that gesture 40% of the time?
That story was widely debunked in followup stories. No one ever demonstrated any of the claims in that story.
If not profitable, it's at least tasteful. Even without the disclaimer (though I think it's best to disclose it), it's so much cleaner than the junk most sites have. If the review is honest, the affiliation is disclosed, and the link is presented in an unobtrusive way, I have no issue with the practice. I'd even like to see it done more.

I actually used the link. I got a KVM today with a Scroll Lock hot key and, after 4 years, I'm just now realizing my basic Dell keyboard doesn't have that key :/ It came with a remote, but the place I want to keep it puts the IR receiver out of site. I'm currently using my old (Windows Vista era) Dell keyboard, but it's clanky AF. The Amazon Basics keyboard looks pretty close to what I'm used to.
It's a setting, you can keep the soft buttons if you like.
Ok and? Is the report the same as being there?
I've personally seen and done both. At one job (first actual dev job) it was a lot of complex business queries for analytics. I put these into their own python module as string "constants" and imported them (I would not do this again). At my current job we put them in .sql files and have a 3 line function that opens and reads them into a string. I sometimes write them inline. I've come to only one real conclusion though is that unless it's super trivial I put the SQL outside of where they are being invoked and name the .sql something that makes sense. It's just noise in my code and I want to see the logical steps.
I have my own slack, just for me. I ise it to have all my calendar invites go to a cal channel...

Can you write up that?

Then all peoples cals can go to their personal slack regardless of source
When you say international community, what do you mean, the UN? The WTO? The G7?

I'm curious. What precedents are there for such a "community" to enforce sanctions on a country's use of their own natural resources?
"Every now and again there is a moment that brings home how strange life in the twenty-first century can be. There I was in Brighton, England, holding a thin slice of glass and metal which was made in South Korea and ran American software, and which could show me the President of America threatening the Supreme Leader of North Korea."

John Higgs: Stranger Than We Can Imagine
an alternative history of the 20th century, p. 5
For me (MBP from early 2015 w/o dedicated card) the upcoming FF 70 made a huge difference. I installed the beta today and I finally can go to youtube, facebook and reddit (the new design!) without the fan spinning up.
That is only on a clock locked chip. There are chips with designs where different parts of a chip where clocks run at different cycles.
We went from hibernate/eclipselink to MyBatis - and have never looked back. Needing to deal with the idiomatic behaviour of JPA, HQL and the target SQL is a nightmare. We’ve literally removed tens of thousands of lines of Java code by dropping JPA.
Its a kind developer based community for google products. It connects developers from different backgrounds with each other around ex language or tools.
> "migration commands based on the git history"... what does that even mean?

It actually seems like a really cool idea. E.g.

* Commit A: create a schema.sql file "create table t (a INT);"

* Commit B: update the schema.sql to "create table t (a INT, b INT);"

* The tool can generate a migration from A..B "alter table t add column b INT;"

It seems like it probably would work really well for creating new tables and columns in simple projects. In more complex projects I've worked on, we usually had more complicated migrations to update the data to fit the new schema, and we often had to be careful to interleave schema, data and code updates (especially if you wanted to be able to rollback).
FireWire wasn't trying to support mice and keyboards. Nor was it trying to be all things to all users. It was trying to be an ultra-fast interface. And FireWire absolutely was backwards-compatible with an adapter. Still is. I never had any compatibility issues with FireWire.
Integral Health | Multiple Positions | Boston, MA | Onsite & Remote | Full-time

Integral Health is leveraging integrated biology to engineer and deliver better medicines to people. It is a patient centric company with the simple, yet ambitious mission of delivering medicines that matter to patients and increasing the scale and scope of health impact. Integral does not only develop drugs but has a deep understanding of wellness and is pioneering targeted data-driven care approaches.
Engineers on our team previously worked at large pharma companies, startups, and Google. If you’re passionate about solving challenging technical problems and using your skills to improve human health, please apply.

We’re looking to hire:

* Software Engineers

* Data Scientists

* Data Engineers

All of our openings can be found here: https://boards.greenhouse.io/integralhealth

No recruiters please.
The fact that some growth has happened despite a lack of road-building does not disprove that more growth could have happened if more roads were built.