skysight-inc/HackerNews huggingface dataset:
What counts as "next to"? I've lived within ten minutes walk of two or three different stations for the last thirty years, and I've worked within fifteen minutes walk of one for the last twenty years over a number of different jobs.

When I'm considering where to live and where to work, I won't consider a house more than ten minutes away or a workplace more than fifteen, and have rejected houses and jobs on that basis in the past. I'm not alone.
> What, are they going to ban it from tournament play?

Plenty of cards have been banned from tournament play. There's no reason why this one can't. Maybe it already has?
ADAMANT – An Anonymous, Open Source, Secure Blockchain-Based Messenger
serious question: what is the alternative as an interface to something like this that isn't a DSL? Is something that looks a bit like a familiar query language (like SQL) better? Is finding yourself in the uncanny valley of a language a feature or a bug?
Include every possible bug?
They called Splunk out at the top of their SAAS list.
... but you must be thinking in a different context or have a different set of assumptions to other people, given that it's presumably not obvious if you've had to say it. Here's an opportunity for everyone involved to expand their minds by trying to understand other people's assumptions, axioms and contexts.
Why does it have to be either SQL or a custom language anyway? We have developed many generic query languages for various different structures [0].

[0] https://en.wikipedia.org/wiki/Query_language
I use a slight variation of that: I can't make the thing perfect right now because of unknowns I can turn into knowns only by doing the good enough version, hence trick myself into thinking the "do it" part is part of the "design for the perfect version" part, and generally discover that my initial vision was too broad and that the good enough version I just completed not only is much closer to the goal than I thought but it's more efficient, easily refactorable, and generally nimble, as well as immediately useful. In a way I'm fighting a natural tendency to excessive generalisation with deceitfully self-imposed serendipity.

There is another situation where procrastination kicks in and the above does not work: when I do have some weird, "code smell style" feelings about blind spots in my approach but things need to subconsciously percolate until I get a a-ha moment. In such scenarios I should not work on the thing and do something entirely different as if I try to force myself into it then consciousness and subconsciousness seem to deadlock each other on a shared mutex.
I certainly do like the art. Although over the years, a lot of art has become more generic. The first sets of cards had in my opinion much more iconic art. Look at Llanowar Elves, for example.

And some cards are really pure works of art.
I get why people hate on ORM's, but let's not throw out the baby with the bathwater here - I don't want to go back to the time where you had to write object definitions for each table the database, and manually sync them. Nor do I want to manually write trivial 'select name from foo where id=1' queries all day, and do all the plumbing to execute it. So when hating on ORM's and unnecessary abstraction layers, please qualify that with 'ORM's should not try to be too smart' and 'ORM's should provide fall throughs into whatever they're abstracting for non-trivial use cases', and not give people the idea to ditch ORM's all together.
Keystone – Open-Source Secure Hardware Enclave
>likely much less, if paid in BTC mined earlier).

You realize that bitcoin is money, right?

It's like saying "You can afford to sell me your house for $10k today, afterall you only bought it for $5k back in 1910".

When the BTC was spent at the time of the ETH crowdsale... the person doing the buying compared options of:

A) Selling BTC at prevailing prices

B) Doing nothing

C) Spending BTC on ETH at prevailing prices

Another analogy:

Because you bought a car today for 30k, funded by the 150 shares of AAPL you sold just now.... means you only realy paid 3k for that car because you bought AAPL shares cheaper in the 1990's.

I'm just pointing out the absurdity of the statement and the significant misunderstanding about the nature of capital.

Then going on to talk about the Gini coefficient as though it means anything at all seals the deal that you are out of your depth and just trying to sound smart
I did a video series on programming a while back. I wasn't teaching. I was just sharing being a fanboy with some experts.

Boy, did that suck. Every little thing that happened, I couldn't help but think through all the mistakes and omissions being made. I can't imagine doing the same thing at the scale of YC.

I'll probably do it again. I love writing and expressing myself. But I can see where PG did the right thing to get out of the light a bit. I remember on HN the guy would say something like "It's raining outside" and 14 people would respond with misunderstandings, clarifications, arguments, nit-picking. At some audience level all in the same room, it becomes impossible to communicate back-and-forth. The long-form essay is probably best.
It's an interesting podcast, but wanders a bit, and there's no transcript. But does mention Jordan Walke who wrote the first prototype of react for Facebook ads. Jordan is currently working on reasonml:

https://github.com/jordwalke

And Pete Hunt is:

https://github.com/petehunt

I should've remembered the bit about sml - it's mentioned here after all! :

https://reasonml.github.io/docs/en/what-and-why.html

I do wonder if it'd be easier to port sml syntax to ocaml rather than make reasonml - I guess not. But it might give similar benefits: a pleasant syntax dialect for ocaml, a mature compiler for js and native, and bringing in th js and ocaml library ecosystems.
[ed: but not, perhaps, 90% overlap with js syntax.]

As I mentioned - I haven't really played with reasonml/reason-react - I think maybe some of the impressions alluded to in my first comment came in part from this:

https://medium.com/@Imaginary_Cloud/reasonml-react-as-first-...

In particular sentiments like:

"When using ReasonML, we don’t need Redux anymore. ReactReason stateless components already come with the concept of a build in reducer, which is meant to take care of the problems Redux used to address."

Discussed here:
https://news.ycombinator.com/item?id=17143494

As well as the introduction here:

https://github.com/reasonml-community/reductive/blob/master/...

"Reductive

A reimplementation of redux in Reason.

Word of Caution

You might not need this library, especially so in a language which provides good enough construction blocks out of the box. ReasonReact already comes with reducers!"

Also somewhat related (re: state) :

https://reasonml.github.io/reason-react/docs/en/state-action...
Quarantine != Gatekeeper. They are two different things, stop conflating them. Even with a signed app, you’ll get the quarantine dialog. See this Apple Support page for confirmation and to see an example:

https://support.apple.com/en-us/HT201940
Machine Learning Research That Matters for Music Creation [pdf]
I agree, say no to garbage query languages, including SQL. Datalog has been a thing for aeons, why not use it?
I agree with the author's sentiment, in the context of relational databases. I can't get back the time and effort spent porting SQL to query builder and/or orm syntax. The best I can do is learn from my lapse of sound judgment and instead use parameter binding against raw SQL and never interpolate strings of SQL.

I regret not adopting this practice sooner.

Most of my substantial work resides in that raw SQL feature. So, I use a library that offers good support of that.

I have written hundreds of SQL using query builders and ORMs.
To win the game you must kill me: John Romero
> Impossible to make a coherent point about a situation like that.

I don't think the situation itself is incoherent, just your comment.

> Japan is a strange failed-capitalist state

Is it? Who says?
He forgot the Jira Query Language. To be fair, it really works!
I had to check the date because this could've been written 20 years ago.

Developers don't need other developers to tell them when or when not to use ORM. We know how it works. Some use cases are better for a quick inline SQL whilst others where you have hundreds of tables would lend well to ORM. It's not one size fits all and I'm sure we've all written a few apps in our time to know this to be the case.

And this idea you can just learn "one SQL" is pretty laughable. There is a subset of SQL that works across many (but not all) relational databases. But each database has its extensions which you really should be using to get maximum performance. ORMs automatically take advantage of these just to mention. And the behaviours you will get can differ immensely.
How is this a hack? Isn’t it just procrastinating?
*2007
Show HN: Ngoceh.co – Anonymous Microblogging Built with Vue.js
Interesting point of view. I've been toying with the idea of using a controlled form of SQL as a DSL for an API instead of REST routes. Since I code in Clojure, I use a lib called Korma to help me build SQL queries. It has a rather good intermediary format and I started to extend it in order to support "additionnal SQL verbs and keywords".
For instance, consider my home-made CONJURE BY verb. It works like INSERT but with a find-or-create-by flavor. Here is how it looks like on the client side of the api.

(conjure my-record (by {:linked-record-id 1}) (values {:field "abc"}))

Upon reception, it is translated into requests with classical SQL verbs

(let [existing (select my-record (where {:linked-record-id 1}))]
(or existing
(insert my-record (values {:field "abc" :linked-record-id}))))

I really did this out of curiosity, and actually this works pretty well. Once normalized in an easily parsable format (here s-expr based), it's pretty easy and straightforward to manipulate SQL: extracting where statements, merging them and reinjecting the result in a new query is actually quite easy.

Want to have authorizations on what fields can be read/written by the client ? Well it's not that hard to deep-walk a query looking for unauthorized fields.

Want to return data as a graph of entities like GraphQL rather than as a table or at least resolve foreign keys to the subentity they're refering to ? This should be doable.

What about complex query features ? Joins, filters, conditionals and boolean combinators, limitation on the number of results, grouping, etc ... It's all already here.

This leads me to wondering why are we so opaque about our abstractions ? In my view, the relational model is very useful and convenient and should be extended upon. I don't like the way GraphQL has been implemented (disclaimer: i never used GraphQL): to me it's mostly rebuilding what lies one level below although it is more general than my own proposition since it abstracts away the relational model.

As for ORMs I have nothing against them. Actually with the "abstraction transparency" strategy described above, they would be a very convenient way to write a client for such an SQL-based API : it would essentially boil down to writing an adapter.
Shameless plug here, but this is exactly the reason why I did not create a query builder in the RedBeanPHP ORM. At the time (2009) query languages were a real 'hype' (as well as noSQL) but I have always loved SQL and I struggled with all the SQL-alternatives offered by other ORMs. So, when I created RedBeanPHP I decided to complement SQL rather than trying to replace it. Yes, there is some room for improvement, notably in the integration with the programming language (in my case PHP). So the ORM class has some methods to indicate you would like to apply a condition, but the condition itself is just written in pure SQL.I see my ORM more as a bridge between SQL and PHP than a carpet that hides the SQL.

Not all DSLs are necessarily bad though. Personally I like to create some very basic and straightforward DSLs to replace horribly complex GUIs with tons of nested menus (aimed at professionals). I think DSLs can be useful for educated computer users who don't know SQL (like people in finance, medicine, statistics). Also there should be a limit to the complexity of a DSL. Not every DSL needs to be turing complete. Simple DSLs that cover the required functionality are the most successful in my experience with customers.

However replacing SQL just does not feel right, it's already an awesome language to query a relational database so why replace it? So, for the most part I agree with the author - although I miss the nuance a bit.
Does this work? IS anybody using it?
I feel like people would complain it took say 20 developers hours to fix some trivial bug where in fact that specific bug was not that trivial to fix.

Then the situation is complicated since you don't control the upstream and if I fix a bug in upstream software X I may have to spend more hours convincing the maintainer that the fix should be included, sometimes the meinteiner has different ideas on how it should be done,

Now imagine the bug "There is no system ray anymore, I can't see my Slack,Skype,Dropbox icons there and I want them back. You can't fix this without forking GNOME and you get a new holly war with the GNOME camp (Canonical does not care about desktop anymore anyway this was just an example)
Smash it with a sledgehammer should do the trick.
What killed SPARC, Alpha, and MIPS wasn't that they became worse than others, but that cheaper x86 boxes running Linux became good enough. There is a point where running your workloads on higher end hardware ceases to provide benefit and only cause lower hardware utilization.

I'd love to be able to justify an IBM z14 or one of the higher end Sun (I refuse to call them Oracle) boxes, or even an 8-way Xeon Platinum, but more often than not, a couple VMs on your favorite cloud provider will solve the problem neatly with simpler accounting maneuvers.

Apple is already using its own IP on iPhones and iPads (and, increasingly, in components for their x86 computers). They also have a good idea of what their hardware runs and that places them in a great position to optimize the hardware to their software - to the point they could implement OS-level functions into microcode or do some other types of highly specialized tuning other companies who make chips for the general market can't (or won't - see the PPC heat issue that made Apple go Intel).

That said, Apple didn't abandon PPC because PPC couldn't be better than Intel. They abandoned PPC because their laptop volume didn't justify the investment needed to make PPC G5 have similar performance per watt to what Intel was achieving with their Core series (itself a direction change from the Pentium IV family's dead end). IBM offered Cell to them and Jobs didn't think it'd work (the Cell, with its crappy PPUs and memory-disconnected SPUs is probably the hardest thing to program I've ever seen) well. Intel, on the other hand, was looking for a huge PR win and Apple was it.
VuePress Examples
I've used Hibernate's HQL for many years but now I've started using raw SQL in my Java microservices with libraries like JDBI.
Every ORM (and I mean every one) has the ability to let you either (a) use raw SQL, (b) use raw SQL interpolated with column names or (c) has a syntax which is very close to SQL.

Porting should not have been some onerous or career destroying activity. As Job would say I think you've made a huge mistake.
I find it even more troubling that people like this apparently cannot read instructions and follow them.

There's a simple stepwise list of instructions on the box/can/jar. They're making it as easy as humanly possible, short of actually providing a person to cook for you, and yet some people still can't do it.
Perhaps the best thing to do is to file the bugs against Debian. That way Ubuntu among the other derivatives will eventually silently upstream the fixes.
Great, so force SQL to 'join' things that aren't tables and 'select' things that aren't rows.

SQL wasn't built for querying every possible data store.
I personally like more Complex Doom. Modernizes weapons mechanics and adds random monsters variations.
Apple may not retain the data, but the underlying card issuer does.

I trust Apple more than Visa or HSBC to keep my data from prying eyes.

If someone could make apple pay be backed by a local bitcoin wallet, then I could feel far more secure nobody is going through my payment history.
Some companies do allow flat file export.

Others don't because sometimes it's not that simple to fetch all of the data to give you with one click. Many of these companies are just rolling up the metrics in some online database and hiding the original files away in cold storage.
Artificial intelligence can predict how cancers will evolve and spread
Rebellion and questioning authority is also a vital part of growing up.
I understand the evidence indicates that with long-term excessive long hours, performance is worse. You could be the outlier, able to work efficiently after ten to twelve hours, but I understand the probabilities are against this and that actually it is about perception; that the person in charge of saying how good you are at your job is effectively incompetent and can only measure time in office.
Yeah I think the only way you can use plain, vanilla SQL to query a system is IF its a relational database. Most of the examples are not.. they solve different problems and have vastly different architectures under the hood.

Lucene for example doesn't use SQL because its really solving a different problem - text search. Its a language dedicated to what could only be expressed using something like `LIKE` and regexes in SQL.

Same with Splunk, it addresses a different domain and solves different problems that cant be easily expressed in SQL.

Same with MongoDB.. its not a relational db. Just because there is a mapping from some SQL queries to some Mongo queries, does not mean they are identical databases.

The query language directly impacts the AST generated, which is necessarily tied very closely to the exact capabilities/internals of a system. This post just feels like its based on a cursory glance of what the systems do.

If all Lucene had was regexes, it would not perform much better than a SQL database throwing regexes at strings. Its precisely because the query language is finer-grained that it can be better optimized for that usecase.
Most likely you missed the "is often" part.
Yeah, that was my reaction as well. I fully understand his point regarding ORMs that are meant to be an abstraction over a relational database, but imposing the relational model over non-relational datastores sounds like a disaster.
Designers are from Saturn, developers are from Jupiter
For Debian - would you say that's mostly package owner dependent, or more tied to the policy of "bug-fix without api change only" in stable? Or just overall poor culture of communicating with upstream - when upstream != maintainer of Debian package?
Oh, well, if someone writes a book it must be true!

(That's not true, I'm sarcastic; lots of books are utter nonsense and this conversation was simple enough that we can point at direct evidence and first principles - passive-aggressive appeals to authority not needed)
Doom didn't run all that smoothly on a 386. A 486 was the 'recommended' system on the box.
Show HN: Truncate strings in React with no parameters
I recently wiped my Android phone and put lineage on with microg, to tide me over until I can replace with an iPhone. I'm simply done with the data collection on Android. Maybe I was naive, but I thought a user could switch most of it off, but you can't.

I really admire how Apple are pushing their secure enclave. AFAIK Google Pay uses temporary tokens pulled from their servers, whilst Apple replies soley on the ondevice SE for Apple Pay.
Ask HN: Which hackers should I be following these days?
10-15 years ago, I worked a corporate job, which I genuinely enjoyed for many reasons. While there, my imagination and energy exploded as I discovered and drank up all that Joel Spolsky, Paul Graham, Jason Fried, David Heinemeier Hansson, Jeff Atwood, and Michael Lopp had to write. It was a renaissance for the industry and for me personally. Their thoughts introduced and propelled me into the software startup world, made me a valuable asset to my employers, and led to me being in leadership positions. I'm looking for that sort of learning and insight again but not really finding it organically. These greats certainly haven't lost their mojo. They weren't a fad like most thinkers and writers online are or have been. I'm simply wondering if there are additional folks I should be following this decade because they're building the next renaissance.

Please list any up-and-coming changemakers you follow below.

Thanks!
> Tap-to-pay is easy enough, but today’s users expect evolving, personalized experiences that sync as they shop. They willingly share personal information to foster enhanced experiences with services like Netflix, Amazon,

I'm not sure it's entirely willing. More that they have no idea how much data is being collected, and convenience outways finding out about the other implications.
As for compatibility, Apple managed exceedingly well the moves from 68K to PPC and then to Intel, even keeping some binary compatibility. Few companies ever did that - DEC comes to mind, making VMS and Ultrix move from VAX to Alpha, and IBM moving the iSeries from AS/400 to POWER. iOS software will continue to be written for ARM for as long as we can see. macOS can, eventually, move to ARM too - if Microsoft can do it (emulate x86 at Celeron speeds on Snapdragon), Apple certainly can.
I've worked on large projects using ORMs and others using parameterised SQL strings. My experience, FWIW, is that the advantages listed in the article are all real, on top of which there are some more esoteric SQL features (like window functions) that may not be well supported by a given ORM.

On the other hand, there is a significant cost in terms of duplication. In ORM code it is trivial to decide a where clause at run time. Not so much in plain SQL. So you end up with a lot of copies of the same query, or else some sort of query assembly layer, at which point you're halfway to an ORM anyway. I am undecided on the issue.
I think micro ORMs like Dapper are a perfectly reasonable compromise between too much abstraction vs too much abstraction. Hand populating data structures from database query results is error prone and tedious. Using a “big” ORM like hibernate or EF is a leaky and expensive (over-)abstraction. Not just because they typically come with a query dsl but they also come with performance considerations and architectural consequences that are hard to predict. You end up in a situation where estimating work is hard because you don’t know if the ORM is going to play along (making a feature trivial to implement) or hit a snag (making it very time consuming). With smaller abstractions the estimates may be higher in the best case but they vary less. This is one of the most important qualities about a library or stack. Not the average, but the variance in difficulty.

On the topic of query DSL’s - the only acceptable ones are those that are native to your programming language. A good example is the F# SQL type provider. If that’s sufficient for your needs, it’s actually quite elegant as far as query languages go - and it’s all F# meaning it’s not a specific language for querying.
It never made sense to me how popular ORMs were. The very first time I used one, I understood straight away that it was a bad idea and I never changed my mind about it (though I tried).

Why is it that open source software which adds unnecessary complexity and slows down development tends to become popular but open source software which takes away complexity and speeds up development tends to not get any attention. It's like there is some kind of conspiracy.