skysight-inc/HackerNews huggingface dataset:
I have been working with Java for the past 20 years.

I have noticed that over the years the knowledge of SQL eroded a lot in population of Java developers. Not only that, but the design of application seems to be lacking. Where problems could easily be solved with a little bit of efficient SQL people mindlessly accept huge performance losses due to ORM as if they just did not see other possibility.
We felt the same way about Retool and that's why we built Appsmith. https://github.com/appsmithorg/appsmith

Our project has similar goals like Retool, Powerapps or other low code builders for internal tools, but we are building an open ecosystem instead of a closed one.

How close is this project to Retool? We have all the major features already so you won't miss much but we don't have all the UI widgets and native integrations yet. We'll probably reach feature parity in ~6 months.
I've been hiring part-time engineers for about 2 years now at my consulting company. I post on r/Jobs4Bitcoins, ask for their github and that they speak English fluently.

I have some really good engineers who love working for me. I do weekly standups, give them direction and then get the f-- out of their way.

We have a kanban board where I populate tasks and the devs just grab what they want to work on. We don't do sprints.
I get what you are saying, but on the other hand, there is a need for static website. Not every site needs a backend. There are use cases where a static site is a simpler and more efficient solution that a wordpress site for example. Jamstack got popular due to a need, it wasn't just a hype.
Cache warming is an overcomplicated way to achieve most of the same thing. You already know exactly what's changed; why would you throw that information away and then attempt to regenerate it, instead of just using it directly?
Linq is not an ORM, but Entity Framework is. But what makes EF interesting is Linq.
I agree with your logic. To self-interpret: I think my rationale demonstrates that the claim "markets are inefficient" is coherent, and my examples demonstrate that its true.
I mean the market literally is the average of everybody's position so I would say it's a tautology that the average performance of everyone who participates in a market will equal an index of that market.

But sure you could always define efficiency in an unattainable way by saying no matter how much you beat the market your streak could end down the line and the limited sample size means it doesn't prove anything.

And to me that's what efficient markets are. This unfalsifiable word game you can play where as long as the definition is flexible enough, you get to say the sentence "markets are efficient".
Rust also comes with a very deep standard library for I/O, path manipulation etc whereas the C++ equivalents for all of this are still surprisingly lacking even in C++20 (especially on the network side).

I agree with this point and cross-platform development is painful in C and C++. However, one of the reasons people use C and C++ is because of platform specific development. It turns out the platforms themselves are written in C.

For example, the "very deep standard library" for Rust can't do DNS TXT queries. On Linux, I run 'man res_query' [1] and get the documentation. Notice the Synopsis, that's C/C++ and the Linux specific code I write can use that.

Rust can also call these functions but there is an impedance mismatch between the safe world of standard rust and the unsafe calls to the system -- I imagine that a crate is a available to ease the pain of the 'unsigned char *answer'.

I am not making this comment to belittle Rust, I actually think it is a good and safe alternative to C++. However, there is decades of system development behind the C/C++ ecosystem and coming onto a C/C++ thread (about a package manager) and calling things a "shitshow" is not going to win people over.

[1] https://man7.org/linux/man-pages/man3/res_query.3.html
ORM +DDD = business!
Linq is more of a query builder than an orm, or am I wrong?
> By proving too much I meant to say that since section 230 does not apply to newspapers the law must make a difference between them. To my understanding this difference is editorial control.

Instead of guessing what the difference is why not read the very short section 230? The difference is that 230 specifically deals with the web. The difference isn't editorial control its literally that the law directly speaks to the web. I would suggest in half the time required to watch the video one could read 230 twice over. This misunderstanding directly stems from concerning oneself with bad secondary sources.
I would sincerely love to know how to make Firefox work this well for me. For reasons I still can't decipher, the browser tends to slow any computer I run it on terribly no matter what I do or which version I run. I've noticed this across multiple machines. Yes, I often leave dozens of tabs open but Chrome (combined with Great Suspender) never gives me trouble on this.

If anyone can suggest any sort of fix, i'd love to leave the snooping, prying Google browser behind finally.
I agree with most of this, but once you’ve learned SQL, how do you integrate it with your code?

I find value in libraries that occupy a middle ground between nothing but raw SQL and a full-blown ORM.

In TypeScript (and with apologies for hawking my own project): https://jawj.github.io/zapatos/
The CEO is beholden to the board who are beholden to the shareholders. The CEO is generally not actually beholden to the shareholders (directly). Depending on the shares, the shareholders may or may not be able to actually influence the board.

Owning a share in coca cola doesn't give you a right to the secret formula.
Ef, entity framework, exposes an iqueryable which you can use linq to query against. Meaning you can use your orms entity model and query your database In a type-safe compile-time-checked manner.
Does this mean that space time is ‘bent’ and objects follow an apparent parabola along that bend, or that space time is flowing towards a mass and the object is following a straight line on a ‘moving’ space time?
The article says the analysis controlled for age. Survival has improved in every age range.
Cell-based meat: On the road to commercialisation with Memphis Meats
I learned to use the Django ORM in depth, but there were some things it couldn't do at the time (it may have improved). Extra conditions on joins. Subqueries, conditional aggregates (it does those now). Once you get to a certain level of complexity you can shoehorn the query into the ORM,but I am not sure it makes sense. The next developer is more likely to know SQL well than the Djnago ORM.
Greg young would agree!
Thank you so much! I appreciate the kind reply and will be researching APEC and Millennium. I really didn’t know where to start, so I really appreciate it!
I think that Google would be a memory without them aggressively developing and leveraging new tech (AI) for search and other ajoining services (maps, translate, adwords).

Adwords exploits automated auctions (from Multi-agent systems)

Maps uses planning

Translate uses deep networks

Search uses ??? (dunno, but it ain't map reduce for sure)
Much is said about what to learn, but when you learn it is just as important and I'd like to see more written about that.

Is an ORM good to help onramp beginners, or is it some syntactic sugar for experts who already know SQL very well? Or both? Or neither?
The JSC team (and I suspect V8 and SM) always treat performance cliffs caused by normal/sensible code patterns as a bug.

The problem is that when implementing improvements it's easy to forget every mostly-equivalent thing and so miss obvious things (often the entire fix in the end is "if (canDoItFast) doTheExistingFastThing()"
The rail automation is solved, entire metro lines are automatic in several places.
Unfortunately while it is an easier problem to solve, it's also a less financialy interesting: in a train the labor cost of the driver is much lower than in a taxi.
Could you explain what you think an "actual need" for const looks like?
Or, like, figure out how to get them healthcare.
Interesting :) in this context I still do not understand how this would not apply to the New York Times.

If I had to guess I might point at employer liability or contract laws, but it might be a discovery for another day
I switched back to linux two years ago for exactly the same reason.

It was painful at first, but it's worth it. The only things I still miss are the visual feedback in the UI (lots of little stuff) and the feel of the trackpad.

But the customizability has more than made up for that in productivity. Like being able to edit the source code for the window manager.
Online documentation. For some reason the qualification is necessary because their header files have a bunch of information that whatever script or tool that generates the webpages doesn’t catch.
> "the market considers all information and synthesizes it correctly"

This is a further misrepresentation of the efficient market hypothesis. The efficient market hypothesis states that the price agreed upon by the market is accurate to a risk-adjusted level, to the extent that it is not possible to consistently beat the returns of the market.

This is generally proven true by the fact that most funds fail to beat their benchmarks in any given year, and the more long term you start to look, the closer the number of funds that outperform their benchmarks gets to 0.

Page 9 of this document shows this quite conclusively: https://www.spglobal.com/spdji/en/documents/spiva/spiva-us-y...

Anybody who "beats the market" on any given day could only achieve that by discovering an inefficiency in the markets decision making. The efficient market hypothesis doesn't say that this is impossible. It says that it's impossible to do this consistently, which is reflected quite accurately in the historical performance of mutual funds. I guess the theory is flawed in the sense that it doesn't define how long you have to beat the market for before you can be considered 'consistent' at it, but I'd consider the small number of funds that achieve this over any significant period as being within the error bars of luck.
> but by using stored procedures in your database.

This used to be the standard when clients used to connect directly to the database. Now that the world depends on web services, things are a little different and there's less incentive to maintain stored procs as an interface to your database.

It's still a good idea though, with unparalleled performance. I suppose developers don't do it for a variety of reasons: They may lack the SQL knowledge, they may not want to maintain the extra code, they may fantasize about database portability, etc.
There is a trick in physics I am reminded about. In infinite dimensions there is no way to have a Gaussian measure on just an infinite dimensional Hilbert space. It needs to be embedded inside a bigger infinite dimensional space and then you can have some relative measure.

So you do not look at just a Gaussian integral, you look at a quotient of Gaussian integrals.

Perhaps there is a similar idea. Perhaps there is some sort of renormalisation that would make neural networks work better. Even if your neural network is infinite dimensional it still makes sense to talk about some surface relatively.
Short of external factors (sharp recession in tech), I don't see the culling phase happening.

If a recession did happen and orgs started cost cutting, I imagine that R&D would drop somewhat, and you would see fewer new projects and toolkits perhaps? Even then its hard to see the pace of innovation (for lack of a better word) slowing.

It seems to me that technology is now in the stage, where its everywhere. Every industry that is quick to adopt new software gains a competitive advantage over its peers, in so many industries. This unreasonable effectiveness of software seems to feed itself.

I would love to see studies that measure/quantify the blooming and culling of technologies so we could talk about these things with more than just anecdata.
LinkedIn Spiral Galaxy Captcha
The point of ORMs is not avoiding SQL, it is avoiding concatenating strings in order to build complex queries. In our app we have very complex query logics depending on the request params, and I can hardly imagine how dirty the code would be without the relational algebra abstraction.
That's why in my last Ruby On Rails projects, all my query and mutation are just sql query. No ORM, no callback.

The reason is that, not all our Rails devs understand well ActiveRecord, but they know SQL enough to make things work.
Let me be more clear. Partial objects, such as a book with an author created from a user request may or may not have DB ids that may or may not exist. If you want to add a Book object with an Author you must first upsert the Author to possibly retrieve the DB id which already exists and cannot simply be generated locally. This can often be a bit confusing or cumbersome compared to the SQL.

Why are you caring about DB ids if the ORM is supposed to handle it, asks OP.
If it can proved immutable all modern JS engines will at worst hoist to the earliest point of immutability. With the exciting amount of inlining the modern JS JITs can do they can often do a better job of proving immutability than C[++] compilers.
Honestly, C and C++ libraries being annoying to deal with is a Windows-created problem.

POSIX systems have pkg-config as the de-facto standard way to find installed (or non-installed, if done correctly) libraries, and all common build systems (including autoconf, CMake, Meson, ...) support this.

Meanwhile on Windows you're left with a pile of unpacked library directories somewhere on your disk and everyone does their own thing and it's a clusterf*ck of build system twiddling.

And the worst part is that this bleeds over into POSIX systems when Windows-created libraries make a jump over and don't know to stick to the conventions.
>Just require people to be explicit about what the burger/sausage/cheese-like thing is made of and that's all, surely?

The problem is while some products use packaging that clearly indicates it is non-meat based, there is plenty of packaging that does not. I nearly bought some plant-based food recently because it was looked similar to meat-based versions of the same thing, and I only happened to notice it was "chicken-style" (the "style" being in very small lettering and so offset from the word chicken that it was practically detached) when I took a second look to check the cooking instructions. It wouldn't have hurt me to eat it, but I would have been disappointed to only find out when I went to start cooking. I live with a vegetarian, and have tried a number of meat alternatives and not been impressed by any of them so far - while some are ok as their own product, nothing I have tried was a good substitute for meat.

I understand that some companies want to market their products as "indistinguishable from meat", such as appealing to people who became vegetarians for ethical reasons but still crave the taste of meat, but I am a firm believer that packaging for food and other important items should follow the principle of least astonishment, and that using terms that have historically referred to meat products to market non-meat products in a way that can mislead or confuse consumers is unethical and should be regulated.
I actually agree with your point, but what?!?! It takes some serious punch drinking to have ever gone along with that "hee-hee we can do such creeper things but we don't because we're ethically superior" shtick. Anyone who has ever signed on to work for Google has made an obvious decision of wallet/status over ethics. Yet the implication in your post seems to be "if google went cheese, anyone could". I disagree strongly.
Is there any comprehensive overview of why python is slow in the first place? There seems to be opportunities for small optimizations, but is that the only place where the slowness is? A few years ago I tried to find out what investigations had been done on the speed of bytecode generation and there was basically nothing. No one could even suggest how long bytecode generation took, only that "it's really slow". Isn't the common wisdom to measure, then optimize, not the other way around?
Just say no to ORMs.
The argument against it I usually see is "you can't version control SQL!"

Where I work we have a custom system which manages releasing immutable SQL snapshots between environments and they get merged to master once in prod. The only thing needed is a process, and then version control is easy.
Like 24, 25 or 30 fps. Well below eye's Nyquist rate. Everything above that looks like garbage unless there was special care taken to look good or real reason to shoot at higher fps. Upsampling to 60fps seems like even worse idea because it usually introduces soap opera-like effect.
While hardware engineers come up with faster and faster computers, software engineers come up with slower and slower and slower software.

While I agree that having nice and easier thing is nice, and easier, performance is always relevant, if not for pride or principle, at least think about the environment, computer processors and memory chips consume electricity, and are really inefficient.. How many percentage of the consumed energy turns into the desired product (computation)? Les than 1%, a CPU using 100 watt is pretty much a 100 watt room heater with a side-effect of also performing some computation..

That's a _WAY worse fuel efficient than a Model T, and yet we treat computational power and memory capacity as infinitely cheap.
I wonder if there are companies focusing on solving the opposite problem. In other words, AI to focus on things humans don't perceive (leaving the driving to the human). For instance, figuring out the person in another car is drunk, then alerting you to avoid them. Or detecting emergency personnel needing you to get out of the way (can't tell you how often I see folks blocking or oblivious).

This goes along with my experience in new cars in that the best improvements are those that enhance my ability to drive (such as a backup camera).
I like ORMs for routine queries, there's a lot of stuff that is just much nicer and less tedious to write that way. It's also generally much less annoying to have some dynamic aspects in your queries with an ORM, e.g. adding different WHERE clauses depending on some parameters.

But even with relatively small and simple things you can run into issues very quickly if you don't know what kind of queries the ORM will create. ORMs are very leaky abstractions, they're useful but unless you understand SQL and understand their quirks you're likely to create some weird and monstrous queries at times.

You should know how your ORM handles related entities if you query them, there are some big footguns there with some strategies. And of course you should know how to use the ORM so that it doesn't do a "SELECT *" everywhere (which can be trickier than I'd like in some cases).

I would also not hesitate to drop to plain SQL for some cases, if your query doesn't fit neatly into the capabilities of your ORM.
I've been in really poor places all over the world, all alone and on my own. None scared me like that one street in SF, the tech capital of the world. I genuinely felt like I was about to get hurt, right here in plain daylight, just walking through. There was unimaginable misery wherever I laid my eyes, for what seemed like a kilometre long stretch of road.

I didn't expect the source of so much wealth to be this bad.
Show HN: SaaStarter – Nuxt.js auth templates and Stripe integration
Bug that is tracking this in webkit land is https://bugs.webkit.org/show_bug.cgi?id=199866
Why is it not properly documented or are you not hiring developers with the right skills or providing training?

Instead of fizz buzz maybe testing basic SQL abilities in an interview would be better.
Like everything else, use the tool but understand the inner workings too. E.g. Hibernate allows logging of the SQLs being executed so when I make changes, I review that the SQL being executed is as expected + performance is acceptable. From that point of view, understanding SQL performance is important. However, I don't really want to write boilerplate SQLs when the ORMs can basically form the query for me using query method name - that is super convenient and I don't want to give that up.

Selecting * from a table with 200 columns isn't performant but if the table had 200 columns, I won't be blindly relying on the ORM generated query anyway since most provide the escape hatch of executing direct SQL.
On high volume applications I would avoid it since it's usually easier to horizontally scale web servers than sql servers, and it makes cache strategies more difficult depending on how and what you're querying.
Yes ORMs are terrible but there is a middle ground required. Something to nicely pool connections and handle all the boilerplate involved in binding parameters to prepared statements. I normally roll my own but would love to find a good library that does it all.

One problem I've yet to find a good solution to is automatic reconnect on database errors with proper transaction support.
Not him, but this should be quite easy to port, the only difference being that the JWT stuff would need to be served by this newer plugin instead https://github.com/greenpau/caddy-auth-jwt because v1 and v2 plugins are not compatible.
What is a serious language?

I would call C a serious language. Its running your laptop, your phone, your car, the airplane you took on holiday, the fighter planes that protect your airspace, your washing machine, and if you are unfortunate enough to get seriously ill it will probably be running on the medical equipment that keeps you alive.

One of the reasons it is serious is because it is standardized and multiple implementations exist.