ldb

Very nice. This is up there with my favorite DUST short film, "Final Offer". https://www.youtube.com/watch?v=rv8kOzRZK8g

For me (in EU) the shakti.com site now forwards to k.nyc and shows a white screen with a single letter "k". Has Shakti been discontinued?

Oh man, what a legend this guy is. Using an ambiguity in Klingon lore to explore yet another micro-tonal system is just incredible. And he profoundly apologizes for an off-by-one error he made in the previous video ... as if that hasn't happened to most of us :-)

Wow, not in my wildest dreams would I have thought that such a deep dive into Klingon music theory exists. This is amazing. Thanks for sharing.

Very nice idea. Reminds me a bit of https://www.chessguessr.com/.

A great project.

FYI: I guess there is a minor typo in the README example: the argument of the second call to fib() in the non-coros version of the code should be "n-2" and not "n-1".

Maybe Apple competitors should start a campaign: "Only RAM can".

(paraphrasing the famous car industry’s slogan "There is no replacement for displacement")

Nice site. Found it a bit counter-intuitive that the selected airline button has a black border while it has a blue blue border in its unselected state. I would have expected it to be the other way round.

There are some nice Lisp related comics on xkcd, e.g. https://xkcd.com/224/ and https://xkcd.com/297/.

I used SQL a lot when working in the financial industry many years ago. Our "use-cases" were questions like "why did the P/L go down?" or "why did the risk position increase?". These are quite open questions (that require some creativity and interpretation to be answered) but I guess it is possible to train an AI to even answer such questions.

Nice. Why do I need to select a table? I tried "Customers with most orders" and selected table "offices" and still got the correct query on tables "customers" and "orders".

A great example page http://vcfmw.org/

Wow, "it's so dense; every single frame has so many things going on".

Love the walking cat gif http://vcfmw.org/friends.html

Yes, I do understand that. So there is a certain probability that my “i am a high population country” conclusion is wrong (e.g. if I am from Iceland). As already asked below: Do you know a way to quantify the likelihood of me making the wrong conclusion (without knowing the population numbers of the other countries)?

Thanks, that makes sense. Do you know if there is any "mathematical trick" to quantify the likelihood of me being wrong (without knowing the population numbers of the other countries)?

I am not a mathematician either and only read the “Quick Intro” but that left me with the following question: What happens if I replace the Earth’s populations with that of France and the Earth’s countries with the French cities? If I do that and then follow the logic in the Quick Intro then it makes sense to me that it is likely that I would be born in Paris, but I do not understand how I can follow from this that France is a high population country. What do I miss?

An open letter from Mars.

“Dear Earth,

it came to my attention that you are running a website called “marssucks.com” where you state some not so nice things about me. While I think that I understand why you are doing this it still hurts me to read that e.g. I am so terrible that “Matt Damon ate his own feces just to leave me”.

So I kindly ask you to take down the “marssucks.com” site. For a planet as rich and lush as you there should be other ways then making derogatory remarks about me to convince your inhabitants to treat you in a good way.

Love from your brother Mars”

Had to think of that Simpson's episode where MacGyver appears and says something like "Don't thank me, thank the gravitational pull of the moon". Well, it seems that that line wasn't complete nonsense at all :-)

> "Can I see your parts list?"

That one made me laugh, however, I wondered if an AI would consider this question as a bit too personal for a pickup line.

Congrats, this is a beautiful website. Very well made. I love it.

Figure 3.3 in [1] suggests that a belted driver has a 40% chance of survival in a full frontal crash at 50 mph. At 80 mph the survival changes are close to zero.

[1] https://nacto.org/docs/usdg/relationship_between_speed_risk_...

JavaScript seems logical, however, the TIOBE index for JavaScript is pretty much stable between 2% and 4% over the past decades. Shouldn't we have seen an increase in popularity of JavaScript?

The February TIOBE Index indicates that Apple lost a 10% share in the programming language market by "bluntly replacing Objective-C by Swift". Any ideas to what languages these programmers switched?

Same for me. From what I understood you want to say that "people love spreadsheets" but "spreadsheets have limitations" (e.g. they have weak/no data schemas). If this understanding is correct then it would be helpful to see a practical example where said spreadsheet limitations become a problem and how your solution overcomes this problem.

Couldn't find pricing information on the webpage. Does anyone have details on pricing for WayScript usage? (I assume it is not free as there is a "Payments" section in the terms & conditions)

It's probably me, but the (great looking) web-site gave me no idea what the use-case of nuronlabs is. Naming a problem that nuronlab solves (and ideally showing how this is done) would be helpful.

> The big boost in program readability is following a style guide with the rules for naming, indentation, commenting, and other important features, plus automated or manual style reviews.

I completely agree. I just wondered if there has been done any research where programmers are presented with some code they've never seen before and then the time is measured until they have understood the code (e.g. can correctly answer some test questions regarding the function of the code). In such a scenario one could try to find a "best" style guide, i.e. a style guide where most programmers understand new code the quickest. Have you ever heard of such research?

Thanks for your thoughts which are all good and reasonable.

Over the past years I've seen many programmers struggle with the combination of "data aggregation" and NULL. In the beginning I thought that these programmers should just "RTFM", but as this problem occurs so often it might very well be that the practical implementation of aggregation and NULL is "a bit off".

I like your "set" approach a lot, however, we still have "sum({1, 1, {}})" unequal to "1+1+{}" and "sum({}) = 0" which, while consistent, I think are somewhat counterintuitive and I am pretty sure will lead to misunderstanding.

Having said that, I suspect that any decent and consistent approach to this problem is subject to a very reduced form of John Lydgate's famous quote, that is "You can only please some of the programmers some of the time".

Many thanks for your time and this interesting and insightful conversation.

Hhm, this time your answer doesn't convince me. Setting "required" is not always possible, and using UPDATE to set a value works only as an ex-post solution, i.e. you must already know that there is an error. But this was exactly the point of my hypothetical example: the balance-query returns 0 which is a perfectly legal account balance and there is no reason to suspect an error in the first place.

So, I still think that the definition "sum({}) = 0" has more potential to hide errors than the definition "sum({}) = {}" would have.

Again, a very nice explanation. However, from a practical point, I see the following problem: Assume that "Select sum(amount) FROM Payments;" calculates the balance for a customer account, and assume further that for some reason (e.g. a programming error) the amount column for that customer has been filled with "{}", then the above query would still return the well defined result "0" which might indicate that everything is correct (while it is no).

This would not happen if "sum({a, b})" was defined as "{a} + {b}" (which is what a user would intuitively assume). However, this definition is also not very practical as any one occurence of {} in the sum would render the whole thing to {} (which is not what a user would expect).

I guess the handling of "{}" will always stay a bit tricky.