slaymaker1907

You can definitely use it as an incredibly powerful learning tool. I've been using it to guide me through Haskell and I've learned so much more than I did in college when I had spent way more time on it (that time being 10 years ago so I had forgotten most of it). It's invaluable being able to go and ask the AI questions and have it rephrase the parts you don't understand. I spent a good hour with it figuring out exactly what the traverse function does (`traverse (\x -> ['z', x]) "ab"` probably doesn't do what you think it should).

Spoiler: The <> combines lists as cross joins (for-loop within another for-loop). The lambda maps to new lists ['z', 'a'] and ['z', 'b'] (strings are just char arrays). It then computes the various combinations to recombine them so ['z', 'z'], ['z', 'b'], ['a', 'z'], ['a', 'b']. Note it's not all permutations since you don't have ['z', 'a'] even though that's actually one of the "base" arrays we got from the lambda. It took me a long time to really internalize that and it's still probably not a function I'd reach for.

It is kind of cool, though, that you can do `(,) <$> lista <> listb` and you get a nested for loop.

I have a huge disagreement here. You should absolutely be using Arc and Rc for any references *that live outside of the call stack.*

Don't do weird crap with lifetimes to try and convince the compiler that what you're doing is ok, just throw Rc/Arc on it and be done with it.

The Rc/Arc advice also applies to C++ IMO, though you use different constructs, std::shared obviously, but there is a strong argument to be made for a std::shared_st or something which is single threaded.

It would not surprise me if this advice comes from experience with C++ where there is no Rc so reference counting is very expensive. Even so, you can greatly reduce the expense by passing things by ref where lifetimes are simple which is the vast majority of the time.

You should check out the Racket programming language. They actually don’t have types at all in their documentation, they only have preconditions and postconditions which are very helpful in telling you if a function expects non-negative integers or something.

I’ve wondered the same, but with programming languages. However, there are a couple of reasons why I think programming languages and libraries will be important.

Most importantly, imagine a timeline where no one has invented any programming language beyond assembly. I think an LLM would have difficulties implementing complex programs in assembly without a bunch of supporting libraries.

Sure, the LLM might be able to make the libraries eventually (will it actually know them all without ANY domain knowledge from a human?) but it would take a lot of time and money to do that. And really, you’re still creating libraries, the only question is if you share them or not.

Another thing is that human written code can be much better than what the AI would write. For example, saw it basically duplicate the same complex operation three slightly different ways instead of just abstracting that away in a function.

The trick around that is to use some form of oblivious block storage. That would completely remove those traces, though it is very performance intensive to anything obliviously.

However, that would clearly make your phone look suspicious from forensic analysis. To counteract that, you have two hidden volumes leaving you with three total systems: your insecure system (first password), the honeypot volume for “clever” actors to find, and then the truly secure volume.

I think one honeypot would be ideal. It needs to be convincing and have data that seems sensitive which would take a lot of effort. Put your nude photos there or something.

And memcpy is kind of special to C/C++ compilers. Sure, it exists as a function, but it will often have special purpose code generated for that particular location.

It’s obvious why you want to inline memcpy, but the specialization is more interesting. For example, I’ve seen the compiler optimize a memcpy with a static number of bytes and then use SIMD registers to do the copying with no loop at all. It can even be smart enough to take advantage of memory alignment for this.

Unlimited retakes would be an enormous amount of work for professors/TAs/teachers.

Optional homework is often a disaster. At best, students would do it right before an exam and the goal of education is not to just pass exams. They’d probably still get a lower score than if they did the homework when they were supposed to.

What I think is better is to have a due date, but just make the maximum 10% each day it is late. So after 2 days, the highest score you could receive would be 80%.

I liked that system because it gave some flexibility with deadlines while still encouraging you to turn things in on time.

Try using a subagent loop where you have one agent generate text and another critique the text according to some guidelines/goal.

You're right, there are tons of different workflows you can do. One of the more innocent ones, regardless of you opinions on vibe coding, is just using the LLM to understand the code base better. Even if I'm vibe coding something, I will often start by having the LLM construct documentation for the current code flows. It's a document that is useful to me as a human because it mostly just gives me code pointers and tells me what it does as part of the larger whole. It's useful for the LLM since it saves a ton on time and tokens in the long run.

I've personally started focusing a lot more on code quality and communication skills over correctness of solving some leetcode problem. If I could get the infrastructure in place for it in the interview, I would have candidates generate something via AI and watch their process for that (how do they evaluate a plan, how do they review the code, etc.).

It will also cause a lot of trouble for companies with specific data access policies (probably most large companies). My money is on this new thing getting gutted very quickly as they figure out how much this constraint cuts into their bottom line.

That's definitely the case as model distillation is one of the explicit safety carveouts they mention. Though TBF, model distillation is also a big concern for general safety as distillation could allow you to have the model without the other guardrails. It's sort of a master key to the model.

While less necessary with AI, Excel is still the king of data entry and basic data manipulation (sorting, filtering, updating, etc.). I’d say that SQLite with a GUI for visualization is a far stronger competitor than Jupyter at those sorts of things. You can do that stuff in Jupyter, but it’s easier in Excel.

Jupyter also has a janky execution model. It doesn’t track dependencies so you have to be very careful in how you separate cells from one another and just running the whole notebook every time seems kind of pointless vs just writing a pure Python script.

std::array can sometimes give you the best of both worlds for stack allocation in that you statically constrain the stack allocation size (no alloca) while guaranteeing that your buffers are large enough for your data. You can also do a lot of powerful things with constexpr that are just not possible with arrays. It is very convenient for maintaining static mappings from enums to some other values.

That is not what they should do according to microeconomics because luxury goods are Veblen goods. Decreasing price would lower demand, at least until they lowered it enough that it was no longer a Veblen good.

Basic microeconomics is just that: basic and thus an oversimplification.