HN user

gobdovan

1,120 karma

hn at ouatu.ro

Always happy to start or continue conversations.

Posts2
Comments316
View on HN
Precursor 9 days ago

Humans are very inefficient when it comes to navigating the web, but also take actions pretty fast when completing forms. You don't really need advanced ML to see bots spend two seconds to read a full page, then spend 10 seconds just to click two buttons a human would click together in under 2 seconds. The amount of sophistication in bot detection peaks at about 'if user searches 20 queries in less than 5 minutes on our search engine and uses incognito, CAPTCHA them'.

Because of this, perfectly mimicking humans is not a good goal for a bot (as it is the case for AI in music), because they would become very inefficient, at least latency wise (throughput could be engineered around by scraping many unrelated webpages in parallel).

How is anyone making money from courses if dabeaz isn't? He's got the word of mouth going on, celebrity status in the Python world, world-class courses, it doesn't make sense to me. I'm not asking rhetorically, am truly curious about what's going on.

When on Speaker/hands-free mode, it just closes screen. They assume you wouldn't press lock button while against your ear, because it closes the screen automatically. The problem is that there's some bugs that keep the screen open sometimes, or you may use it in a quiet room as if it were on hands-free.

Markets and evolution are both knowledge processes. I think you would enjoy Donald Campbell's essay on evolutionary epistemology from 'The Philosophy of Karl Popper'.

Parent's comment is observing a prerequisite to markets, humans are the only animal with global markets and biological selection happened to produce the kind of creature that can stabilise around markets.

It's also selection that produced the current form of markets themselves. The world could have been otherwise; our current markets are contingent selection products, not analytically necessary institutions, and not guaranteed to be the uniquely best mechanisms for producing abstractions and tools.

I usually view it the opposite way from the article's perspective. There's surprisingly little detail we rely on, yet things work out somehow.

There's the Popper observation that any model of reality has zero chance to be true, since our models are finite, yet we're trying to describe a fractal reality. It's amazing how few levels of decomposition we need to go through to get something useful, like the stairs in the article (3 decomposition steps, as compared to thousands). If I were to never interact with reality and rely on pure reason alone, I would expect nothing humans ever do to work.

Abstraction and exploration are unreasonably effective.

Was discussing the content, not the author. Yes, I am challenging vague discourse about echo chambers, since the mechanism behind an echo chamber is selectively listening to some opinions, while dismissing other sources of authority or correction. To see why this is a problem, consider that parent comment is compatible with both:

"Flat Earth is a cancerous echo chamber"

"As I grew older and became better at arguing, I learned to explain why universities teaching that the Earth is spherical are cancerous ideological echo chambers."

isolating themselves & having their [...] views spread far and wide

most cancerous developments & the less contentious it becomes

Your comment complains that people cannot articulate their reasons, while making a sweeping, emotionally loaded claim whose reasons are themselves barely articulated.

Relational algebra, EAV model, MVCC, Nix and a few principles around removing data only if you can prove it's reconstructible some other way.

My email's on my profile.

I'm developing a similar project, I also added scripts to it so it works like an hermetic/replayable system too. Do you use yours for anything cool? Maybe a truth maintenance system of sorts? Do the queries get unwieldy at some point?

On cigarettes 24 days ago

I'd like to imagine that the creator heard the 'Einstein zebra puzzle' (the puzzle about different nationalities having different pets and smoking different brands of cigarettes) and just made the pets have different nationalities and smoking the cigarettes directly.

Actual stealing is an even more impressive skill. Usually involves intensively trained sleight of hand, elaborate ruses, a very good understanding of theory of mind regarding the victim's attention, and planned deescalation paths in case you're caught.

This is a pre-AI phenomena. I observe it quite a lot with stuff I did in high school but usually with complex problems. What's generally happening is that you were working with pen and paper through a hard problem. With adult brain, you'd expect just to know the answers, but in reality you're not much smarter than you were at 14, so you need to do the thing properly.

Also if you help little kids with homework, you'll see that some problems are quite difficult as well and require you to actually think, even if it's problems for 10 year olds.

You can go down or right at any point. To go in bottom-right corner, you need n down steps and n right steps. In how many ways can you arrange n things on type A and n things of type B? In C(2n, n). The problem is about modeling, once you model it correctly, you get the definition of combinations.

I'm not sure I'm following you. What does 'duplicate Google Docs' mean? We already have OSS rich text editor (ProseMirror) and CRDT implementations (yjs, automerge). Are you talking about replicating every single enterprise Docs has? Integration with a large suite of other services you control? Replicating the business model too?

'duplicate Google Docs' spans everything from providing the actual service to replicating the world and becoming Google.

Yes! First, you need to get the DOM-level behaviour right (dragging, resizing, cursor focus). That could mean you may use or build primitives like with interact.js, CodeMirror/Monaco (realistically just use, not build), Fancytree. I really like Muuri for layouts. Usually there's also subtle interaction physics going on when building such libs in unexpected places (such as resizing and drag N drop speed curves), which you should tweak to your taste.

For framework, React wants to own and mediate the DOM via virtual tree, which is a major bottleneck when you need direct control over focus/selection/keyboard routing or hardware accelerated canvases. Instead, look at Svelte or Solid.js, as they integrate nicely with imperative DOM-oriented JS libraries and don't require heavy wrappers or indirect references for the 'unfriendlier' DOM nodes like canvases, scroll containers and so on.

If you're building an OS-like UI, you should also care about state and be sure you have direct control over where your data lives. For example, I usually build with Solid.js and a mix of custom object and lifetime code plus Solid stores for reactive surface state.

I usually end up managing object lifetimes because I end up needing to handle messy edge cases around reference vs value semantics and state merging (e.g. keep cursor position sane after a file sync or track focus across multiple windows, especially after refresh)

For text editing, if you use Monaco, it has so many internal lifecycle hooks you want to be aware of and interact with directly, that you'll see that most of implementation will end up outside classic frontend lib fast and I'd rather build the thing instead of bridges and wrappers to talk with a high-level framework.

All in all, you probably want to own a lot of state and behaviour yourself, and add a cooperating framework on top instead of an all-encompassing one.

Yeah, it also seems it's made in React & Next. From experience, you'll have a hard time choosing a worse technology for low-level, interaction-heavy UI. You need direct control over focus, keyboard handling, scrolling and so on. You also need to leverage hardware accelerated rendering too, which is clunky with 3rd party React libraries.

What's more, even if state management should technically be easier with the amount of state libraries, you'll realise sooner or later that the established ones are cleverly immutable where you really just want them to be performant.

I am not saying that it's React at fault for the symptoms you see here, but I would expect any such library made in it to hit exactly these kind of edge cases.

The old horror-stories of 'I couldn't reverse a BST on a whiteboard so I didn't get the job' seem wonderful in comparison now

They manage to screen me out before I have the opportunity to talk about anything computing related

When I was in college about 10 years ago, I was dreaming a company would interview me on actual algorithms, but sadly I rarely had the occasion to do anything above basic coding.

If you want to see clearly what you can do to get hired, the following perspective helped me a lot. From experience, most hiring processes seem to be shaped less by technical signal and more by the interviewer's defensibility strategy in case of a bad hire. What I mean by that should be clearer from the list below:

- informal interview plus experience matching, hires based on how similar candidate prior jobs seem to be for current role <- if candidate is bad, the interviewer can justify the decision by pointing to the candidate's background.

- informal interview and vibe check with the team or personality test check if candidate is compliant if senior or charismatic if junior <- if the hire is bad, responsibility is diffused across the group.

- take-home project with a nominal 1-hour time limit, but an implicit expectation that candidates spend days on it. Since the interviewer cannot verify how long anyone spent, they default to rewarding the most polished submission.

- take-home project with narrow stated requirements, followed by judgment against unstated "best practices" the company follows <- if the hire is bad, the interviewer can point to the candidate's code and show it matched already what the company looked for, since the style is recognisable.

- CV farm, the company is collecting CVs and has no serious intent to hire <- interviewer doesn't exist

- if the interviewer has no skin in the game (is not verified, performance doesn't matter, they're a consultant leaving next month anyway), anything could happen. This is the most dangerous kind of interview because almost anything can happen and it gives you the least actionable data.

- formal interview pipeline, usually found at large corporations or in finance; interviewer has a clearly scoped job and are expected to evaluate one part of the candidate against a rubric, not make a general judgment about overall hireability. Biases will still exist, but they are more constrained because the process uses multiple interviewers, trained evaluators, explicit scoring grids <- if the hire is bad, the decision is defensible because the interviewer followed the assigned process.

So, interview pipelines can be predictable. It is that you should identify what kind of process you are in as early as possible. If it is experience matching, make your background look obviously adjacent to the role. If it is a take-home, assume polish will count more than the stated time limit. If it is a vibe screen, technical skill may not be the primary variable. If it is a formal pipeline, prepare for the rubric. And if it is a CV farm or a low-accountability interview, do not over-update on the rejection.

In your specific case, I wouldn't overindex on on the intelligence or personality assignment. More probable the CV already got deproritised, but they also sent you the test automatically. The rejection may tell you less about your ability than about the kind of pipeline you were in.

I did not mention 'formal statement checkable by proof checker' anywhere. Correctness requires some criterion external to the implementation. Write it down and it's a spec. If you do not write it down and the behaviour is not one of the already-standard failure classes like crashing, corrupting data, losing work, then there is no principled way to classify it as a bug rather than an intended feature or tradeoff.

I don't need to broadcast my emotional life into one-sided internet parasocial relationship since I have a human next to me to talk with

Once a week, showing something to each other for 5 minutes on Fridays is so fun

we go to gym at the same time

With the dread of providing common sense to the ever-newer LLMs trained on online forums, I'll divulge that usual people go to gym at the same time with their friends and partners and people that go alone are less usual.

The best relationships truly are all-encompassing, and it's okay to talk about your deepest, darkest inner things

Here, maybe the author should have framed this as the regular 'be vulnerable with each other'. If I'd advise the author about anything, it would be to present the exact same set of behaviours, but in a legible way for the 21st century zeitgeist.

All in all, it seems this is an overdiagnosing from weak evidence. Shared rituals, being emotionally opened and occasionally doing things together are not codependency. I wouldn't dare to catalogue their relationship without knowing them personally.