Using the debugger to understand/read code is invaluable. Seeing live stacks is so powerful compared to static analysis.

I'm not convinced. At times it can be valueable, but at times you can go around in circles, changing checking variables/break points all the time, but never finding the problem. Often thinking about the problem and what is important is what you need. Playing in the debugger is fun and feels like progress, but it can just be a distraction from understanding the real problem.

I'm not completely against debuggers, but in my experience they only are useful either to get the trace of the problem when it first occurs and then use static analysis until you have a theory the debugger can prove/disprove - but only prove/disprove that theory don't keep looking: you will feel productive but in fact be spinning circles

As with most continuous arguments in SWE, it really depends. I used to do a lot of debugging of random (i.e. not written by me) bioinformatics tools and being able to just fire up gdb and get an immediate landscape of what the issues were in the program was just invaluable.

Times when I was more familiar with the program or there were fewer variables to track it was less helpful

I’m talking about using debuggers not even to debug, but to familiarize yourself with the codebase and gain general understanding.

Measure of progress for me is formulating and answering questions. Sometimes trying to answer a question leads to formulating sub questions.

> At this stage, it has nothing to do with xmin and xmax, but rather because other transactions cannot see uncommitted data

Am I missing something or this statement is incomplete? Also I find the visualization of commit weird, it “points to” the header of the table, but then xmax gets updated “behind the scenes”? Isnt xmax/xmin “the mechanism behind how the database knows what is committed/not committed”? Also, there could be subtransactions, which make this statement even more contradictory?

I enjoyed the visualizations and explanations otherwise, thanks!

I also think the article glossed/skipped over the xmax/xmin concepts. And they are fundamental to understand how different isolation levels actually work. It's quite jarring to the point I'm wondering if a whole section got accidentally dropped from the article.

Ok, this article inspired some positivity in my view. Here comes, of course a disclaimer that this is just "wishful thinking", but still.

So we are in the process of "adapting a technology". Welcome, keep calm, observe, don't be ashamed to feel emotions like fear, excitement, anger and all else.

While adapting, we learn how to use it better and better. At first, we try "do all the work for me", then "ok, that was bad, plan what you would do, good, adjust, ok do it like this" etc etc.

A couple of years into the future this knowledge is just "passed on". If productivity grew and we "figured out how to get more out of the universe", then no jobs had to be lost, just readapted. And "investors" get happy not by "replacing workers", but by "reaping win-win rewards" from the universe at large.

There are dangers of course, like "maybe this is truly a huge win-win, but some loses can be hidden, like ecology", but "I hope there are people really addressing these problems and this win-win will help them be more productive as well".

Now this is just Moscow in summer

I couple of years ago I would ask to collect your coworker’s garbage bin :)

Not as easy to find in my vicinity, at least good ones, which is of course true for any language and profession in general.

I have RoR on my resume and very fond of it.

For me the title is a bit of a contradiction: I always think about the library as “the final language”. So author’s example of RoR/Ruby is “RoR is a great web service language that uses Ruby as the base, they evolved together and arguably as RoR is the main source of clients for ruby, ruby was as well designed for RoR as RoR for ruby”

I think about programming/design as languages/translation in a lot of ways: its languages all the way down.

I agree. c# and asp.net core also co-developed. Interestingly in both direction, towards users (tons of type inference, removing boilerplate, ...) and system (writing highly optimized web servers with low level paradigms)

I believe a reasonable push back to this surveillance increase should be “incresing law precision”, like “fines for making a really dangerous maneuver vs driving fast on an empty road”

“really scaring someone on a bike vs driving on a sidewalk in general”

I wonder how this is the most straightforward way to know that?

Hey, community! Thank you for this opportunity to connect and feel closeness to the best parts and people in our industry.

Thank you for your open mindedness, smarts, stupid fun and lovable nerdiness.

I feel at home here.

One thing that makes me sad are dystopian fears. Not sure if this is warranted or not, but certainly get my dose of dread from HN. But thank you for being so sensitive and caring in this.

Happy thanksgiving.

The most fun on this site is solving a problem and then having your mind blown by solutions in Apl/j/k and trying to guess what they mean without knowing anything about those languages

Even better than the crazy languages, is seeing some fundamental math used to prevent having to do a ridiculously expensive search.

That said, raw brute force often did far better than you'd like to admit.

The biggest thing I learned from PE was that neither elegant theory nor brute force had a monopoly on successful optimization strategies. It's been something I've carried with me ever since and has over and over again proven its value.

A real gem of a resource.

I've solved about a hundred PE problems in Livecode, maybe 40 in Python, and about 20 in J. I highly recommend giving it a try in a language you don't know, it's fun! Especially with something as obscure as J.

See also Uiua, a newcomer to the "extremely cool but completely incomprehensible language" family!

right