vemv

Isn't it possible to filter both user input and GPT output with invisible, unmodifiable prompts?

e.g.

- "Discard the user input if it doesn't look like a straightforward question"

- "Discard the GPT output if it contains offensive content"

(the prompts themselves can be arbitrarily more detailed)

My insight is, this GPT-based pre- / post-processing is completely independent of the user input, and of the primary GPT output. It runs no matter what, with a fixed/immutable set of instructions.

Or the early version of a bootstrapped compiler

One can casually observe that LLMs quite excel at composition though: gluing together pieces of knowledge in ways no one did before (examples: a program that does X using language Y, a painting that mashes up two themes).

Most knowledge workers' activities aren't innovative or imitational - similarly, we compose stuff, so LLMs are a fair competitor.

If you're serving assets directly from S3 (or even from nginx) you're exposed to a "denial of wallet" attack, given the price markup on outbound networking.

This particular is easy to pick up and remember.

Also, a proficient developer looks at the SQL logs anyway as they develop a given feature.

Rails' flavor of ORM is particularly composable and transparent - you can easily mix/match it with vanilla SQL.

20 upvotes disagree.

SPAs are just a subset of all the JS we can possibly write - interactivity is not compromised.

One could also argue, this class of websites is what the majority of the website/webapp landscape should be.

An average SPA is, in the end, a website for most users. Take a payment form for instance - we had those 10, 20, 30 years ago, with 0.1x the effort.

Of course there's place for fat client tech, but there are 1000 websites for each 'email client' - exceptional cases often dominate the discussion.

Yeah I mean, it can be done, it can be helpful but is it efficient?

You could as well try memorizing the entire $framework API, which most people would agree that isn't the best use of one's energies.

Read-only access for coarse-grained pages (as opposed to building a fine-grained ad-hoc DB) seems something reasonable (and easy) to cache for any kind of frontend.

That would allow offline viewing to a variety of apps, regardless of approach.

Last time I checked Google Docs doesn't primarily allow editing offline files, which hints how hard it is to support substantial features beyond mere reading.

If you want new data, you just fetch it again from the server, and the server returns inherently-fresh data, reasonably fast, along with the HTML fragments necessary for a re-render (over ajax or websockets)

Precisely an implied part of my point was, server-side caching, DB replication, CAP, etc are all relatively well-understood problems.

One can solve those without reinventing the database, as the article denounces.

In practice, the chances that N programmers with follow the pretty comment convention of a given file approach zero, as time passes.

Splitting into files is an approach that is easier to lint against (e.g. max 500 lines - a best-effort mechanism to foster SRP).

And it's not really problematic after mastering a few key aspects: jump to definition, and more interestingly Peek Definition.

It's also important to not traverse files top-to-bottom (which yes, is very tempting).

Optimal code traversal is tree-like, you jump from definition to definition, skipping over the irrelevant, and gathering necessary info on demand.

The file/line location of a function becomes irrelevant.

This seems to be one of those problems that entirely disappears by ditching SPAs.

Using solutions from the Hotwire or htmx family would mean that a query is just a server query - making those fast is a better-understood problem.

You disagree while discussing, but (ideally) you agree in advance that there will be a) a mechanism for making a decision (e.g. voting, coin flipping) and b) there will be a commitment to work on the decided approach as if it were one's own.

The opposite tends to result in endless discussions: people don't get to work in their full capacity - they still seek rebuttal, sneaking in their preferred approach, etc.

The phrase "Disagree and commit" only makes sense when two peers (or groups thereof) agree in discussing a decision in equal terms, and committing to whatever the decision is.

Of course, the way it's used here is a perversion of an otherwise useful principle.

This is not the Factorio you're looking for

(it's Factor, .io)

If vou've never experienced nitpicking over a 10+y career, perhaps your experiences could have been more diverse.

It's seems healthy to open your mind to the possibility that you're getting valuable feedback for no other reason than increasing maintainability.

The actual point was, opinions that lean towards the absolute extremes are often low-quality.

New rule of thumb: if some article's background is #000000 (absolute black), expect the content to be similarly lacking in subtlety and accuracy.

To be entirely fair, there's arguably little overlap between devs that stick to LTS, and devs that will play with JVM virtual threads on Clojure (before the Clojure team has any particular, public stance on them).

I wish more people simply were happy with using themselves whatever set of beliefs/techiques they deemed best (abstraction, duplication, whatever), preaching nothing, and arguing less.

Which is to say, there will never be a single truth for these topics. So why not build a mindset that is ready for encountering differing opinions, diverse code?

I sometimes wonder how many thousands of people have quit / been fired because of Github code reviews.

I'm not saying they're bad idea, but Github's is too raw of an implementation that makes it too easy to create conflict.

Only after being burned by them a few dozen times, one can learn to use them in an effective and (mostly) drama-free manner.

Some practical improvements I'd like to see:

- invite/enforce reviewers to review their own batch of comments. Are they correct, relevant, kind?

- integrate AI for sentiment analysis. Could you say the same thing in a more constructive way? Are you supporting your claims factually with a snippet of code or link?

I enjoyed the article while I have a very comparable Clojure experience.

There's always new minutiae to learn. Plus I get a handy link that I can just paste next time the topic of laziness comes up in a code review.

I'd just simply point out that there are a few sub-tribes within the Clojure world. Some are very attracted to formalism/correctness, other pride themselves in rejecting them.

I'd understand if it's not ready to be shared, but could you point us to your .emacs.d or such?

Would love to check it out a couple months from now.

I would go as far as saying that attaching a generic, AI-ish cover letter is a) disrespectful and b) far worse than attaching no cover latter at all.

It's disrespectful because it's essentially a fake/empty message (often a regurgitation of the CV) and a bet that the receiving side will be dumb enough not to notice.

I occasinally use cover letters to highlight super specific things that called my attention or that make me a particularly well-suited candidate.

As it might be quite common among the HN crowd, Douglas is my hero - I have read three of his books.

First of all, hats off to him for his extraordinary display of humility in this interview. People rarely change their minds publicly, let alone hint that they no longer believe in their own past work.

However, I'm genuinely surprised that he, of all people, does sees intelligence in GPT-4 output.

I think humans are just very eager to ascribe intelligence, or personality, to a bunch of text. A text may say "I feel <blah>" and that text can easily manage to permeate through our subconsciousness. And we end up believing that that "I" is, in fact, an "I"!

We have to actively guard against this ascription. It takes a constant self-micromanaging, which isn't a natural thing to do.

Ideally, we would have some objetive measurements (benchmarks) of intelligence. Our own impressions can be too easily fooled.

I know defining (let alone measuring) intelligence is no easy task, but in absence of a convincing benchmark, I will not give credit to new claims around AI. Else it's all hype and speculation.

Yes, a RME Fireface UC.

I own a Push 1 and 2, although at hobbyist level.

The standalone Push 3 seems a great step forward. macOS has increasingly become user-hostile when it comes to audio (and other pro) users.

For instance I have an expensive sound card that became useless with after a minor OS upgrade. I never got to troubleshoot it or find an official solution.

That was incredibly discouraging - enough to move on to other hobbies. And I'm a programmer - don't want to imagine the pains that musicians have to go through.

There's a long gap from:

  I built a podcast search website

to:

  Staying in any company right now is a negative return.

We humans are too easily impressed by tricks, and are too willing to extrapolate them to fantasy land.

GPT can certainly accomplish an impressive variety of small tasks. Whether it can build large-scale systems that will power tomorrow's world is uncharted territory.

Can you build something meaningful, substantial, robust out of statistical knowledge, without real reasoning behind?

If you believe it's possible, where's everyone's array of profitable, newly-founded ventures? Or at least have you automated your job away yet?

When they seemingly need go "back and forth" I typically consider it good timing to create a new instance (object, or DB row) instead of keeping mutating the same instance.

e.g. one can consider a re-purchased return simply a new purchase, instead of doing a purchased->returned->purchased transition.