mpoteat

You can actually do better: hint - variational selectors, low bytes.

I also have a corresponding blog post here, where I use this capability to embed custom JSX types as an alternative way to express 'concatenative' higher-kinded pipelines: https://code.lol/post/programming/jsx-hkt/

I just think it's neat

I've had similar issues with conversation memory in ChatGPT, whereby it will reference data in long-deleted conversations, independent of my settings or my having explicitly deleted stored memories.

The only fix has been to completely turn memory off and have it be given zero prior context - which is best, I don't want random prior unrelated conversations "polluting" future ones.

I don't understand the engineering rationale either, aside from the ethos of "move fast and break people"

This is a LLM directly, purposefully lying, i.e. telling a user something it knows not to be true. This seems like a cut-and-dry Trust & Safety violation to me.

It seems the LLM is given conflicting instructions:

1. Don't reference memory without explicit instructions

2. (but) such memory is inexplicably included in the context, so it will inevitably inform the generation

3. Also, don't divulge the existence of user-context memory

If a LLM is given conflicting instructions, I don't apprehend that its behavior will be trustworthy or safe. Much has been written on this.

Actually, it's even simpler: you should just be able to use signature overloading:

  myFunc(x: true): number
  myFunc(x: false): string

I also avoid technologies where the code I write is different from the code being executed.

Not to be snarky, but as opposed to writing assembly? Where do you draw the line if you don't allow TypeScript (which is, with limited exceptions, only type erasure unless you specifically request polyfill), but allow other forms of compilation? Would you define JVM bytecode or IR as messy-looking junk code?

It's hard to see how a principled line could be drawn here.

@marvinborner

Is there any hope for a "hashlife" style cache for a TC language? My understanding is that hashlife exploits spatial locality / "causation speed" in GoL, which isn't available in LC because of beta reduction. Thoughts?

I like to refer to code that has been overly injected with syntactic sugar as "caramelized". We need more culinary metaphors for programming jargon!

Recently, LeetCode has begun hiding instructions (using css) in their competitions to use particular unique variable names like 'dexolarniv' - and anyone using such a variable name in their submission gets summarily banned.

In their implementation, the hidden prompt does show up on copy/paste - however I tested this method, and the LLM (i.e. ChatGPT) does still follow the Unicode-hidden instruction and uses 'dexolarniv' in the code returned! So I think this is (right now) a viable invisible injection strategy.

Look at what they need to mimic a fraction of our power.

If folks are interested in this sort of thing, but want to play around with higher order building blocks, http://hkt.code.lol may be worth checking out.

In addition to type-level analogues of your normal Lodash-esque functions, it includes a suite of type-level parser combinator utilities and is built on higher-kinded type abstractions.

I took a look at the source for the attached repository - the parser is in fact clearly written as a generic type. The presence of ?, :, and ... operators represent conditional types and tuple level destructuring respectively.

This is a very impressive project in my view - it's baffling that you would have the wherewithal to link the discussion you did but not realize the novelty here.

High energy protonic rifle? We already have extraordinarily high energy lasers in a handheld format.

If a stream of bosons can do that much damage, I wonder what a stream of hadrons can do!

More fundamentally O(n^(1/2)) due to the holographic principle which states that the maximal amount of information encodable in a given region of space scales wrt its surface area, rather than its volume.

(Even more aside to your practical heat dissipation constraint)

Columbia has it right. In a just world, this behavior would be derided and considered anathema. This is moral bankruptcy plain and simple and ought to be considered a violation of CFAA.

Even if you are against modern interviewing practices, you should be more against deceiving your prospective coworkers. This is borderline sociopathic.

On reflection I agree.

Still, I feel the author should have explicitly acknowledged the fact that there are underprivileged kids out there that would kill for the opportunities he was given.

A standard CS program will cover statistics (incl. calculus-based stats e.g. MLEs), and graphics is a very common and popular elective (e.g. covering OpenGL). I learned all of this stuff (sans shaders) in undergrad, and I went to a shitty state college. So from my perspective an entry level programmer should at least have a passing familiarity with these topics.

Does your experience truly say that the average SWE is so ignorant? If so, why do you think that is?

The key, from my perspective, is to focus on real work which produces real value for other human beings. In an academic context I admit that it can be difficult to attach this value to your work.

As well, in this article, a person bemoans the opportunities their parents gave them; piano lessons, math competitions, etc. Even though they have clearly benefited from these advantages, it's unclear to me if the person acknowledges the position of privilege that such an upbringing grants.

Well, slower compile times, and additional complexity are the biggest cons.

There is a project I'm working on to eliminate the latter bit - ideally, a way to represent these complex types with "zero type-level code"

At the risk of too much self promotion, I have a much deeper and more feature complete treatment of many of these type-level computations, represented with higher kinded types (which are thus composable) here:

http://hkt.code.lol/

This is my "lodash for types" project. It supports integer division for up to 2^64, for example. It has over 200 composable utility types.

Yeah, it can get somewhat expensive (e.g. $10 in a day) with very frequent use. I find it much more helpful than Github Copilot, as it performs actions 'autonomously', i.e. it can identify which files to modify to solve a task, etc.

The I in PID is referring to a pretty simple arithmetic sum inside of a control loop. Around 30 lines of simple C.

The original post is presumably referring to symbolic integral calculus, perhaps in a multivariable context if we're referring to partial DEs.

The level of rigor and complexity here is a couple orders of magnitude difference. I think there's still a case to be made for autodidaction of higher mathematics (it was certainly the path I went down), but I think unschooling is probably not best for most folks.

There exist problems where finding the solution is hard but verifying the solution is easy. example in the general case: prime-factoring numbers.

Are you claiming that for all possible problems posed, verifying the correctness of the output of an LLM is equal or higher difficulty than solving the problem itself? If so, that seems like a claim more arising from emotion than reason.

In the general case, you can have it generate code in a proof based language that "proves" the code is correct against formal specification. Unless you consider math itself to be "bullshit" too.

I have openly used LLMs to build a custom prompt engine that allows me to make systemic refactors across an entire open source codebase of mine (of 250 files) with a bash command, in parallel.

There are big changes on the horizon.

Reading the question, I thought the answer was six as well. Such a question is so misleading that I would hope that an AI answers as it has in this case, because not all problems are fully logically specified, and you need to remain robust against the question being posed incorrectly.

In other words, I would posit the probability of you having meant for the answer to be 5 low, because the question itself becomes trivial. For a system that needs to deal with many people asking questions, this robustness is helpful in my view.

In other words, it's not totally clear that time has not passed between sentences in your prompt. So the second instance of "now" could be a different "now".

As well, you should be creating regional servers to minimize latency for folks in other geographic regions. Can't beat c!

Let's spend multi-million dollars a year on a team of highly specialized FPGA engineers writing assembly and HDL so that we can save 5k a month. Feature velocity will be 100x slower as well, but at least our application is efficient.

I think that this may make sense for some applications, but I also think that if you can utilize software abstractions to improve developer efficiency, it reduces risk in the long run.

You don't need to prove anything in court to send someone a cease and desist. It's often cheaper to settle.

There does exist the concept of 'originality' in copyright law, which I was erroneously conflating with length.

This is the code of the future to ensure your code remains original: https://twitter.com/TylerGlaiel/status/1611115741809627139

If this lawsuit succeeds, I have a startup idea that I think would be effective.

Create a for-profit copyright registry for code snippets that are long enough to qualify for copyright protection. You can be the canonical owner of the copyright for a given piece of code! For a premium fee, we can generate and submit a patent on your behalf as well.

Once I have a large corpus (perhaps millions of entries of code, most one or two lines long), I can automatically scan new respositories and send cease and desist letters for violating my client's copyright. Even if a piece of code is very common, that doesn't mean its unoriginal, it just means that there are many people violating its copyright after all. According to the logic of the folks in this thread at least.