valw

Or, you know, use a time-aware database like XTDB or Datomic.

I absolutely agree - one of the biggest shortcomings of SQL is that its primary programming interface is based on text and intended for human, instead of being based on data structures and intended for programs.

There’s not much difference in expressiveness

However SQL is declarative

Pick one :) the way I see it, if declarativeness is not a factor in assessing expressiveness, then expressiveness reduces to the uninteresting notion of Turing-equivalence.

Thanks for sharing this. I believe we essentially agree: chaining method calls is inexpressive compared to composing expressions in an algebraic language.

Btw, am I alone in thinking that DataFrame abstractions in OOP languages (like Pandas in Python) are oftentimes simply inferior to relational algebra? I'm not sure that many Data Scientists are aware of the expressive power of SQL.

Well, to be also fair, we also want quantum electronics to be deterministic in their behaviour. The difference lies not so much in randomness as in leveraging intrication.

I made the same remark in reply to another comment which used the phrase "factoring primes" :) Wikipedia does use the term "prime factorization": that seems legit to me, as prime is used as an adjective. https://en.wikipedia.org/wiki/Integer_factorization

factoring prime numbers

factoring into prime numbers ;-) (factoring a prime number is trivial, that's why it's called prime)

Are quantum computers overhyped?

Well, let's see:

When given the same problem, a quantum computer should be able to trounce any supercomputer in any problem in terms of speed and efficiency

LOL, no, not any problem, far from it. Some problems, rather specific ones, such as prime factoring.

Our current system, for example, taps into electrons and cleverly-designed chips to perform their functions. Quantum computers are similar, but they rely on alternative particle physics.

Um, no, they both rely on the same physics, that is a combination of Quantum Mechanics and electromagnetism. Note to the author: an electron is a quantum system, and classical electronics definitely rely on that.

So yes, quantum computers are overhyped, through no faults of their own, and this article contributes to the trend.

the annual worldwide energy usage of blockchain technology is roughly equal to the annual US energy waste from machines plugged in while in standby mode. It is also significantly lower than the annual worldwide usage of Christmas lights, and wash dryers.

... and it benefits much, much fewer people.

That's analogous to the pro-air-travel disinformation argument: "air travel is only 2% of CO2 emissions". It is only so because air travel is only adopted by a small minority of people: that doesn't stop it from being insanely carbon-intensive.

April fool's joke : we'll pretend that bugs in software are distributed as a homogeneous Poisson process, AND that Poisson distributions are bounded, while we're at it.

Poisson d'avril!

Reminder that the Computer Languages Benchmark Game itself recommends against using it to draw general conclusions about performance of languages in real-world apps: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

We are profoundly uninterested in claims that these measurements, of a few tiny programs, somehow define the relative performance of programming languages aka Which programming language is fastest?

Now, I challenge you to find a major bloated software where the main source of overhead is Python interpretation. IME it's always something else, like the surrounding UI framework.

The Office suite is written in C++ and is badly bloated, obviously not because of language execution overhead but because of technical debt, which if that's any indication recommends against using low-level languages.

Sir Tony Hoare famously said: “Premature optimization is the root of all evil.”

Er, wasn't it Donald Knuth? https://wiki.c2.com/?PrematureOptimization

I submit that Event Sourcing (or at least something very close to it) can be easy, once you've removed some technology locks. I've seen it happen with Datomic (https://vvvvalvalval.github.io/posts/2018-11-12-datomic-even...), but it can probably happen similarly with other tech, such as XTDB (https://xtdb.com/).

I wrote the blog post you cited (thanks!) but I disagree with both statements: that is not what is meant in the article.

1. I don't think Event Sourcing sucks - I think we are lacking accessible technology for supporting it. 2. For most difficulties encountered in Event Sourcing, I would rather blame distribution taken to the extreme.

Folks, just to clarify: "catalyst" is a very broad chemistry term for "something that helps a chemical reaction take place without being a reagent nor product of said reaction." So don't get the wrong idea: catalysts have quite specific uses, and you cannot substitute any one catalyst for any other.

Reminder: this sort of metric is sensational but hardly relevant. The relevant metric is how much fossil production is left, not how much low-carbon production we add. All the more so because production peaks of renewables tend to be outliers.

A shameless-because-related plug: https://www.reddit.com/r/patient_hackernews/

A Hacker News mirror biased in favor of thoughtful discussion, by enforcing that you cannot comment on something in less than 24 hours.

This might help you spend less of your attention on Hacker News, by:

  1. Showing you a subset of hot posts
  2. Enforcing high response delays (thus suppressing the impulse to frantically refresh for new comments).

Please give feedback!

Compiling means translating a program from one representation to another. Executing a program always involves a combination of compilation and interpretation (example: Java usually runs by compiling it to Java bytecode, which is then interpreted by a Java Virtual Machine).

The widespread belief that compilation and interpretation are mutually exclusive is unfortunate, as is the artificial distinction between 'compiling' and 'transpiling' we sometimes hear, because these misconceptions show that programmers today are a bit confused about the essence of how programs actually run. It's a pity we don't have more cultural interest in such things, because mastering those notions can really improve software engineering.

Interesting example, but it's funny how parts of the abstract read like an intro probability class:

The framework estimates the climate change risks in economic terms by modeling the main activities that a mining company performs, in a probabilistic model, using Bayes’ theorem. The model permits incorporating inherent uncertainty via fuzzy logic and is implemented in two versatile ways: as a discrete Bayesian network or as a conditional linear Gaussian network. This innovative quantitative methodology produces probabilistic outcomes in monetary values estimated either as percentage of annual loss revenue or net loss/gains value.

When you're in the business of sneaking in a Scheme-inspired language into the universal programming platform in a world of object-oriented dogma, you'd better add some camouflage ;)

And so the language was compromised in its name, and arguably in its syntax and (lack of) macro system.

Note that carbon credits are not all about afforestation - if you don't believe in afforestation, fine, you can buy from projects that do energy transition or industrial efficiency (at the same cost, preventing emissions is always better than capturing CO2). So that's not really an argument against carbon credits.

I'm not saying technology has no role to play - but this specific choice of technologies by Stripe seems dubious to me, and seems to optimize for futuristic enthusiasm rather than potential impact.

I'm not against researching uncertain technology. But all of these projects are about aiming for highly-uncertain technology to solve our problems. Not a single one is about changing the way we live or relying on proven techniques. See why I'm talking about Silicon Valley bias here?

As should be known in a community of programmers, it's misguided to blame tools from their potential abuses. Every single tool for the ecological transition can be misused for green-washing, from solar panels to electric cars to carbon taxes.

Let's welcome and improve the tools, while keeping an eye on how people use them.

The crazy thing about it, I think, is that removing CO2 from the atmosphere rather than where it's readily concentrated like power and cement plants, is picking the worse amount of entropy to fight.

I'm surprised to not see these investments directed towards the voluntary carbon market, in which projects such as those REDD+ certified achieve more than 10X higher efficiency, with significant co-benefits in biodiversity and support to the local communities (here's an example I give often: https://standfortrees.org/).

It looks like the projects were chosen through the biases of Silicon Valley, chosen to be futuristic and technologically impressive rather than impactful.

Carbon credits markets sometimes have a bad press due to the abuses in carbon offsetting approaches, but since the approach here is voluntary action rather than offsetting, I see no reason not to use them.

What seems more sensible to you, financing Western entrepreneurs at $100/tCO2e, or financing nature preservation, energy transition and poverty alleviation in developing countries at $10/tCO2e? Thanks Stripe, but I'll keep buying carbon credits.

Reminds me of the gray kingbird, a very common bird here in the Carribean, which has no problem attacking much larger animals such as vultures or dogs whenever they go near its nest.

Luckily for us, it never attacks humans, and sings quite beautifully :)

https://en.wikipedia.org/wiki/Gray_kingbird#Diet_and_behavio...

Are you aware of EDN, Transit or Fressian, which IMO improve a lot on the currently common approaches to encoding (JSON / YAML)? If so, how does Concise Encoding differentiate itself?

https://github.com/edn-format/edn

https://github.com/cognitect/transit-format

https://github.com/Datomic/fressian/wiki

Anyone who believes the above simply hasn't looked at the numbers. The speed at which we need to reduce emissions simply dwarfs anything technology has ever achieved - not to mention the fact that so far, technological progress has always had the net effect of adding to GHG emissions.

Let's take the example of the digital industry. Arguably, it's shown the most impressive trajectory of energy efficiency, with an exponential growth sustained over many decades, roughly gaining 3 orders of magnitude every 16 years (See Koomey's law: https://en.wikipedia.org/wiki/Koomey%27s_law#:~:text=Koomey'....).

But overall, what's the currently worst-offending industry in terms of GHG emissions / energy consumption growth? The digital industry! Our unmoderated consumption grows even faster than energy efficiency gains, to the point that it's the only major industry in which the energy intensity of added value is increasing.

(Many sources here: https://theshiftproject.org/en/lean-ict-2/)

We do need a lot of technological investments, but the narrative that says this will be sufficient is a very dangerous mirage. Please, be responsible, do your research, and don't spread ignorance - our children will have to bear the burden.

Here we see the classic tension between synthetic names and natural names.

The best discussion I've seen of this topic is in the 1st chapter (which is fortunately freely accessible and concise) of this excellent programming book:

https://leanpub.com/elementsofclojure/read_sample

Relevant excerpt:

Most natural names have a rich, varied collection of senses.3 To avoid ambiguity we must use synthetic names, which have no intuitive sense in the context of our code.

Category theory is a rich source of synthetic names. ‘Monad’, to most readers, means nothing. As a result, we can define it to mean anything. Synthetic names turn comprehension into a binary proposition: either you understand it or you don’t. Between experts, synthetic names can be used to communicate without ambiguity. Novices are forced to either learn or walk away.

Conversely, a natural name is at first understood as one of its many senses. Everyone understands, more or less, what an id is. In a large group, however, these understandings might have small but important differences. These understandings are refined, and gradually converge, through examination of the documentation and code. At the cost of some ambiguity, novices are able to participate right away.

Natural names allow every reader, novice or expert, to reason by analogy. Reasoning by analogy is a powerful tool, especially when our software models and interacts with the real world. Synthetic names defy analogies,4 and prevent novices from understanding even the basic intent behind your code. Choose accordingly.

I know what you mean, and I feel for you.

That said, what forces you to follow fads? I've basically stopped doing it when I got started with Clojure about 6 years ago and it's been fine. It does take some convincing to use that for a project sometimes, but the feeling of empowerment has not faded, and compared to JavaScript churn the still waters of the Clojure ecosystem are quite enjoyable. My point being, fads are not necessarily a fatality.