HackerLangs
TopNewTrendsCommentsPastAskShowJobs

bartread

10,381 karmajoined 14 年前

comments

bartread
·昨天·discuss
> humans will forget to replace the placeholders

I think you're right.

Or people screw up the placeholder content and call you by the wrong name, wrong job title, wrong company, whatever (off by 1 errors in some columns in their automation sheet?).

It's already happening with outreach messages on LinkedIn. Gets an instant block.
bartread
·昨天·discuss
I think you're right. It's already happening with outreach messages on LinkedIn. Gets an instant block.
bartread
·前天·discuss
> He seems to understand humans.

Yeah, I think this is it. The humans were the point, not the minutiae of the tech.

(Btw, I hadn't noticed you'd responded whilst I was editing my comment to express myself a bit more clearly - I hope anyway - so the quotes don't quite match but I don't think it matters, because the sentiment is hopefully clear enough both ways!)
bartread
·前天·discuss
It's funny... I enjoyed Neuromancer, although I didn't read it until about 15 years ago.

And, yeah, the memory thing hasn't aged well. Thing is, 1984 was a funny time in computing, particularly when you consider the kind of computers normal people had access to.

At that point even things like PCs and the new Mac had 128 or 256K of RAM[0], so I get that 3MB must have seemed like an ocean of memory at the time. And, realistically, more than 1MB of RAM in machines you'd typically see sat at home or on a desktop was uncommon until the beginning of the 1990s.

And, although Moore's law had been around since 1965 it's hard to know how aware people outside of specialist circles would have been of it in 1984.

I suppose Gibson must have done some pretty in depth research for Neuromancer, right? But the memory thing is sort of ancillary to the story, so how much would he really have focussed on that? Probably not much.

And then do you really want to harshly judge the book on that one slightly laughable thing, in other ways, it was incredibly forward looking and almost prophetic? Doesn't seem right.

I think the sensible position is you have to let it slide and see it as a possible alternative future that never quite came to pass in that way but that which we can see strong echoes and foreshadowings of even still.

[0] In 1984 microcomputers, as opposed to, cough, "serious" computers like the PC and Mac, with 128K of RAM were still very new, with 32 - 64K being the entry level, and if you had one with 128K you were king of the hill. 128K in 1984 seemed like a ton of memory to most of us, but it's worth bearing in mind that only a handful of years before computers like the ZX81, which had only 1K of RAM, were the common entry level, so the progression was already clear if you looked at the situation in the right way, but you had to have been paying attention for a while to have noticed. I remember the first time I used a machine with 4MB of RAM in, maybe, 1990 - an Archimedes at school - and feeling like it was just this absolutely inexhaustible ocean of memory. In 1984 3MB would have felt almost inconceivably huge unless you were in the high performance computing, or maybe the mainframe, worlds.
bartread
·前天·discuss
Ah, that's slightly disappointing. Although, realistically, when it comes to Amiga I only have DD floppies anyway.
bartread
·3 天前·discuss
Whoa, wait, what? It can? I did not know that. Back in the day I had an A500, and only bought the 1200 decades later. Had no idea it would accept HD floppies. TIL. Thank you!
bartread
·3 天前·discuss
Yeah, but eventually the downvoting/community moderation will do its work: it just takes a few hours sometimes. But the original unkind remark has gone from top level comment to nowhere near the top of the discussion (at least I haven't managed to find it other than via my own profile because of all the newer and more upvoted discussion that's happened) fairly quickly.
bartread
·3 天前·discuss
Probably a lot of people voting aren't aware of the terms of use. But, at any rate, it's certainly not the top comment now - it often takes a couple of hours or so for voting to settle out and the initial top comment quite often doesn't stay that way.
bartread
·3 天前·discuss
I think you're misunderstanding me or over-interpreting what I've said. I'm not justifying or excusing the unkind behaviour, and I'm aware of the site terms on HN.

What I'm saying is that in large online forums - regardless of terms of use - some people are unkind, and that it's a good idea to be prepared for that when you post something publicly.
bartread
·3 天前·discuss
Yeah, it's funny they never really took off as a data storage format the way zip disks and CDs did.

To me a MiniDisc would have been far better than a Zip disk but I never encountered MiniDisc used in that context. Certainly, whereas all the machines in the computer lab during my masters had Zip drives and floppy drives, making Zip the logical choice for my home PC, I don't ever remember seeing a PC with a built-in MiniDisc drive anywhere at all - not even in computer shops.

Shame really. I'm sure they probably existed but maybe rarely enough that they'd classify as oddware? (HT to LGR for that piece of terminology.)
bartread
·3 天前·discuss
There was a time when, for me at least, the 3.5 inch floppy seemed like the pinnacle of portable storage technology, especially as compared to the cassettes and 5.25 inch floppies I’d been used to.

I made regular use of 3.5 inch disks as portable storage up until, if you can believe it, 2000 when I mostly switched to Zip disks and, occasionally, CDRs. I never found CDRWs that useful.

Writable CD storage was always a bit of a faff to use though, whereas Zip disks behave exactly like floppies, only a lot bigger.

Fast forward to 2002 when I first got home broadband, and it just became easier to simply transfer files directly over the internet rather than toting disks around.

Not long after that cheap USB sticks started to get usefully large but, really, I’ve barely used them in 20-odd years.

It’s funny how, once floppies became too small for most practical uses - even though I’d used them exclusively for 10 years - I didn’t spend much time with anything else before jumping to just relying on the network for file sharing, syncing, and transfers.

Very occasionally I do still use them today: I’ve got an old Korg Trinity synth that uses 3.5 inch floppies for storage, and I’ve got a minty fresh box of them still hanging around in my office. I’ve also got an Amiga 1200 that uses DD as opposed to HD floppies.
bartread
·3 天前·discuss
It's not immediately more enlightening if you do click through either, except in the most general terms - some issue with changes to their Ts & Cs is alluded to in the first paragraph, and then there's a wall of text that probably does explain in more detail but simply didn't look like it was going to be interesting enough to bother reading.

And maybe that's the point: having just annoyed their customers, whilst they do need to communicate with and apologise to those customers - clearly the intended audience here - perhaps they don't want to kick up a massive fuss that lands on the front page of HN and other sites, and sparks a big discussion or controversy.
bartread
·3 天前·discuss
It's always fun to remember how rude people were about Dropbox on here.

More seriously though, in many ways HN is a pretty broad church. You're always going to get a spectrum of opinions, and some portion of people are always going to be particularly forceful about putting forth their opinion. Maybe it's a bad day, maybe it's habit, varies from person to person and day to day, etc.

But I think, if you're posting something to HN (or, really, any large internet forum), negative feedback - and dismissive feedback - is something you need to be prepared for as part and parcel of the experience because it often is going to happen.

Not that I agree with the person you're responding to - their remark struck me as quite a mean-spirited and unnecessary comment, and I very much prefer your perspective.

Anyway, I've bookmarked the site so make of that what you will.
bartread
·6 天前·discuss
All of this depends on the problems you’re solving though. There is no one size fits all approach to database development.
bartread
·6 天前·discuss
Yeah, exactly. I think the best approach is always to know SQL and know the ORM.

Most of the time you’ll be able to simply use the ORM, but every so often you’ll inevitably come up against a situation where a custom query gets the job done better, and you’ll still get the benefits of deserialising to objects that the ORM offers.
bartread
·6 天前·discuss
Your 3rd paragraph: I wondered if something like that might be the issue, hence my somewhat tentative musing.

Legacy of all kinds seems always to be so expensive to deal with.
bartread
·8 天前·discuss
Sounds about right. I approached this in a different way in my office.

The walls aren't straight, either vertically or horizontally, and they're not even consistently wonky along any given axis.

So I installed uprights vertically, using transparent polycarbonate spacers of different depths at the attachment points[0]. I then installed shelves on the uprights and aligned them horizontally.

The variation is only +/- 6mm or so (for around 12mm variation across the 2.5m x 2.44m wall) but, if I hadn't done this, my shelves wouldn't be level, and wouldn't even be consistently non-level, so would have been awkward to install along the full length of the wall, would all be misaligned with eachother, and would have looked incredibly janky.

[0] In hindsight I wish I'd gone for these in different colours rather than just plain transparent, to make more of a feature of them. The walls are white so I think orange, blue, red, and yellow would have worked well.
bartread
·12 天前·discuss
The takeaway from this for me is that, using an LLM to score anything takes multiple (maybe even many) runs and the result you’ll get is, at best, a sane-ish distribution.

Which sort of sounds workable until you scale it up to larger datasets, where at some point compute/time/energy costs will render it non-viable.

I am sure there’s some reasonable rule of thumb estimation on distribution that could be applied based off fewer runs per data artifact, but you’re always going to be trading off against confidence by doing this.

Beyond this, I’d bet that almost no implemented systems that use LLMs for scoring, ranking, or decision making use such a multi-run approach. Partly because people don’t understand their behaviour is stochastic, perhaps because a lot of people without a background in statistics don’t understand what stochastic actually means, and no doubt partly because of budget concerns: if you have to ask an LLM to do the same thing 10, 50, 100 times to get a sufficiently good result, then the cost saving argument is either weakened or completely destroyed.

There is at least one more aspect worth considering in the specific case of resumes/CVs: is the inconsistency of scoring by LLM worse than the inconsistency of scoring by a human following a similar process?

Because the reality is that, even for an experienced recruiter, reviewing hundreds or thousands of resumes or CVs gets pretty fatiguing. People get hungry, bored, tired, restless, irritable, etc.

That inevitably leads to inconsistencies creeping in, so there’s always an element of “luck” (or, perhaps better, uncertainty) as to whether your resume/CV passes screening.

So is that inconsistency better or worse with LLM screening? I don’t know. But, at least, if it’s not worse maybe it doesn’t matter for this specific use case. And if it’s notably better then maybe it’s raised the bar on what “good enough” screening looks like?

(And I’m sure other use cases warrant similar, “does it matter?”, questions, with the answers no doubt landing differently.)
bartread
·13 天前·discuss
Well, at least they learned from the experience, and that’s good.

The more interesting question, I think, is what proportion of businesses will choose the learn from Ford’s experience without first choosing to relive it?

Often people, and therefore also organisations, struggle to usefully learn from the experience of others without repeating the same mistakes, and experiencing the same pain.
bartread
·13 天前·discuss
I’d imagine precisely because they might be collecting regexes from user input such as parameter values or search terms, and the user may not know or care which technology your tool or service is built with. However, they will need to know which regex dialect(s) you support.

And I’d further bet that people who are casual about specifying that are relatively strongly correlated with people who are casual about santization, catastrophic backtracking, etc. (At least based on code I’ve seen over the decades.)