beckford

Docker Agent could be beneficial for research studies. For example, while writing a ML paper about agents I need to rerun experiments so that: - others can repeat my results - validate that variability from LLMs is not causing overconfidence in the results

But currently uv is good enough to create isolated, repeatable environments. And it isn't limited to Linux like standard Docker. So when I want to test small samples on my local PC's GPU (Windows or mac) before running on beefier hardware, I can do that easily.

As mentioned in the sibling comments, Andrew Gelman has covered this elsewhere. In particular, Gelman et al have a "Model Checking" chapter in their Bayesian Data Analysis book https://sites.stat.columbia.edu/gelman/book/BDA3.pdf . A popular intro Bayesian book Statistical Rethinking has a similar "Sampling from the Imaginary" chapter (https://civil.colorado.edu/~balajir/CVEN6833/bayes-resources...). Both books introduce the topic early (the latter book deals with it in the third chapter) if you are willing to do a bit of reading.

The part about being hardware-agnostic sounds something like ROS 2, but maybe at a higher level. I would love to see a post about that (with a bit of explainers for people like me who only lightly dabble with robotics).

But I'm also curious to know if the "Salem" name was searched first. When I first saw the title I thought it was talking about Agility Robotics, which is based in Salem, Oregon and is currently 3rd spot on Google search for "Salem Robotics" (and 4 of the top 5 results on YouTube).

The most important lines to me are the CFTC Chairman's quote:

> These are financial exchanges that offer financial instruments and operate across state lines. They match the bid from a resident of one state with the offer of a resident from another state and submit the trade to a clearinghouse that backstops the transactions of customers throughout the country. New York has no business regulating these interstate financial markets.

If true, it seems quite irrelevant that NY is limiting its suit to NY customers. NY would be restricting trade to people in other states. (I am not a fan or user of Kalshi)

They did the same for a Samsung Fold phone delivered to me last month (in the US).

Awesome! How did you find that out?

Using fragments for secure data has been discussed before on hn: https://news.ycombinator.com/item?id=23036515. Tldr: it may not go directly to the server (unless you are using a buggy browser or web client) but the fragment is captured in several places.

That hasn't been true for a few years at least. https://www.jetbrains.com/help/clion/cmake-debug.html is has had CMake debugging since cmake 3.27. Ditto for vscode and probably other C IDEs I am not familiar with. So does Gradle for Java. GNU make is hardly exclusive.

> One reason is that far more of their students actually applied than would be expected.

This sentence is buried midway through the article. It would be good for a future post to expand on this ... how much is explained by students simply applying more frequently to their local schools. This explanation was the only plausible explanation in the article I saw answer "why".

If you were looking at the parse link in the author's comment, you were looking at a spec (called a module interface in OCaml/OxCaml, similar to an interface in Java). The parse implementation is at https://github.com/avsm/httpz/blob/240051dd5f00281b09984a14a...

That said, I would be happy if all I needed to type in was a spec.

Since the link is paywalled, the TLDR paragraph is:

> Boasberg said in the ruling that the FTC had incorrectly excluded YouTube and TikTok from the market where it challenged Meta's dominance. "Even if YouTube is out, including TikTok alone defeats the FTC’s case," the judge said.

I agree. Meta does not have a monopoly since they compete with TikTok.

> The first main disadvantage is that they require the kernel to support syscall tracing, which essentially means they only work on Linux. I have Ideas™ for how to get this working on macOS without disabling SIP, but they're still incomplete and not fully general; I may write a follow-up post about that. I don't yet have ideas for how this could work on Windows, but it seems possible.

On Windows, Linux, and also macOS with SIP disabled (as implied, disabling is a bad idea), the https://github.com/jacereda/fsatrace executable exists today and can trace filesystem access. It is used by the Shake build system.

In particular, https://neilmitchell.blogspot.com/2020/05/file-tracing.html mentions that Shake copies system binaries to temporary folders to workaround the SIP protection. That blogpost also mentions other problems and solutions (like library preloading).

Good advice but still:

> investors warn the good times won’t last forever

Umm ... these aren't short-term investors. They are investing because they think at least one of their bets will pay-off.

Introduction paragraph:

Metalang99 is a firm foundation for writing reliable and maintainable metaprograms in pure C99. It is implemented as an interpreted FP language atop of preprocessor macros: just #include <metalang99.h> and you are ready to go. Metalang99 features algebraic data types, pattern matching, recursion, currying, and collections; in addition, it provides means for compile-time error reporting and debugging. With our built-in syntax checker, macro errors should be perfectly comprehensible, enabling you for convenient development.

Yeah, I don't disagree. I'd go further and say the examples are on-point for a "human oriented" language. But the formal spec reveals how simple or complicated this language is. (And I'm also writing this from the perspective of someone who uses a programming language that does not have a HOML implementation).

Not OP, but I think it does run Postgres as a process. However, IMHO the general use case for SQL is for external actors (humans, machines) to get access to the underlying data in a structured way. So I see a benefit for a true in-process embedding of Postgres if the process exposed a Postgres TCP/IP port 5432, etc. (Hook your software up to a query tool, a reporting interface, etc.)

Beyond that, why care whether the "embedding" involves a spawned process? It still works great for integration tests which I suspect is the main use case, and for specialized data analysis software where a spawned process is no big deal.

For something like this I would love to see a formal spec to go along with the examples.

Disclaimer: I took over maintenance of the Cap'n Proto C bindings a couple years ago.

That makes sense. There is some opportunity though since the Cap'n Proto RPC had always lacked a JavaScript RPC implementation. For example, I had always been planning on using the Cap'n Proto OCaml implementation (which had full RPC) and using one of the two mature OCaml->JavaScript frameworks to get a JavaScript implementation. Long story short: Not now, but I'd be interested in seeing if Cap'n Web can be ported to OCaml. I suspect other language communities may be interested. Promise chaining is a killer feature and was (previously) difficult to implement. Aside: Promise chaining is quite undersold on your blog post; it is co-equal to capabilities in my estimation.

Since Cap'n Web is a simplification of Cap'n Proto RPC, it would be amazing if eventually the simplification traveled back to all the languages that Cap'n Proto RPC supports (C++, etc.). Or at least could be made to be binary compatible. Regardless, this is great.

Yes, C and C++ have an odd symbiosis. I should have said C/C++.

Obviously C is the ultimate compiler of compilers.

But I would call Rust, Haxe and Hack production compilers. (As mentioned by sibling, Rust bootstraps itself since its early days. But that doesn't diminish that OCaml was the choice before bootstrapping.)

Thanks for some of the early feedback. I did a few tweaks: separated the quick start into two (one for students, one for experienced devs), moved up the examples, and duplicated some of HN summary text on the linked page. The latter because I, as an infrequent HN submitter, hadn't realized that some (maybe most?) people don't read the HN summary.

Yes, there is always verbal instruction (not really explanation) to start with the students. For example, most students I work with don't know how to open a terminal ... they need top-down guidance with copy and paste. The most explanation they would get at the start is that a terminal is where you can copy text and see a response. Pointing them at a web page with directions (mine or others) has never worked for the vast majority of them. The Rust pages in particular... some of them would not understand that they have to press the greater than symbol (>) to go to the next page, and almost all of them would not know they had to strip $ from the commands (or have a clue what Linux is). I think the success rate would be near zero (0%) for that Rust guide without hand-holding. Of course, once they've seen how to do something, they should not need as much handholding.

So eventually we come back and redo the content ... and that becomes the time that explanations are added.

I do like the Rust doc for experienced devs though, although I'll quibble that the doc is not good for Windows users. I'm add a separate explanatory quick start for experienced devs.

It is the OCaml language but it also isn't packaged like conventional OCaml. Please don't blame OCaml for that.

It _does_ need a primer for those unfamiliar with OCaml. I was thinking ... since this is scripting ... part of it will probably take the form of a cheat sheet for people coming from Java/C#, JavaScript and Python backgrounds. And another part of it would be how to read an OCaml expression from left to right. Other suggestions welcome.

Direct answers:

- the full explanation of why Std is repeated three times is covered over the first four sections of the first manpage "dk(1)": <https://diskuv.com/dk/help/latest/manual/dk-1/>. It will go over some of the design behind that and also introduce aliases so that "the tool `StdStd_Std.Run` can be typed as `Run`". Did I unnecessarily expose "StdStd_Std" in the introduction?

- the `Tr1Stdlib_V414Io` is a library described in the first reference manual "dkcoder-libraries(7)": <https://diskuv.com/dk/help/latest/manual/dkcoder-libraries-7...>

I usually structure teaching the same way done in https://www.writethedocs.org/videos/eu/2017/the-four-kinds-o.... So "the Quick Walkthrough Guide will explain what dk scripts are and give you small examples to run" is simply a learning-oriented tutorial which is mostly about giving students confidence and visual feedback. And simultaneously it an explanation of nothing (the video has a great explanation for why to do that). So, I agree that an explanation of threads + Internet + cross-compilation would quite nuts, but for an experienced developer I'd expect to see a meaty example (take a look at https://ziglang.org/ for comparison).

One concrete action may be to make two distinct Quick Start guides ... one for the experienced and one for the inexperienced students though. Is that your thinking?

TIL: Another instance of history repeating itself.

> The goal is that we can play Sudoku in TypeScript while the type checker complains about mistakes. This is not about implementing a Sudoku solver.

That goal could be extended to implement a Sudoku solver in the type system. One such solver was described at https://ocamlpro.com/blog/2017_04_01_ezsudoku/ for OCaml. TLDR: Your compiler can report the solution as an error message if your language supports refutation and has enough type machinery to accurately model Sudoku.

Having said that, I don’t think a Sudoku solver implementation embedded in a type system is practical (maybe fun for educational purposes though!)

That's fair. Assuming I introduced a new macro "compactexpr" it could have been written:

  [%%compactexpr
  "SumArStaged";
  [ arr; n ];
  let sum = ref 0 in
  for i = 0 to 3 do
    for j = i to min (i + 3) (n - 1) do
      sum := !sum + arr.(j)
    done
  done;
  !sum]
  ;;

  print_c "sum_ar" (module SumArConv) SumArStaged.expr;;

So that has the exact indent level of the C code. (Details: The above is formatted using the "conventional" profile for the "ocamlformat" tool)

Of course, there is a disadvantage. I had to use global variables in the above "compactexpr". Global variables mimic the C language (ie. C functions are globally-scoped or file-scoped functions) but wouldn't be a good fit when translating that code to functional languages. Additionally, the OCaml idiom `fun arr n ->` was lost, but that seems minor.

Do you and others find the above readable? (If so, perhaps it would be best to give some flexibility for the coding style.)

I'd consider that an extension of the "object database" approach mentioned. Just as you mention the application needs to decode (and encode and deal with missing fields) that JSON. And probably in any sufficient size of application you'd have to do this decode/encode in more than one place. That JSON encoding/decoding is a "variation" (more explicitly, a reshaping operation). The engineering costs of having variations strewn across your source code hasn't disappeared.

Author here. In the article I highlighted how easy it is now to translate OCaml line-by-line into other languages while at the same time preserving exact semantics. That was the cool news that deserved its own callout. But as you noticed I didn't spend any time talking about how translating OCaml helps solve the problem of managing types "all with slightly different variations".

Briefly: atd, Cap n' Proto, Protobuf and many others occupy the role of representing the same datatype in different languages and transmitting values of that datatype across the wire and/or persisting in storage. But I'm finding most programs have a need for multiple variations to that core record datatype. For example, when you persist an OCaml/Java/etc record datatype to a database, you don't use the OCaml/Java/etc record datatype. You use the data types provided by the database (VARCHAR, BLOB, etc). You can adopt an ORM solution, use an object database, or write a pair of type-conversion functions from OCaml/Java/etc to your database datatype. That is one example of a "variation" that you must spend engineering time on.

I mentioned in the article that my user needed 5 different variations. For example, with the sqlite3 database they were using, the database table variation required writing a pair of datatype-conversion functions to and from the sqlite3 database. What if there was a way where we could write these datatype-conversion functions in one place (cough cough: OCaml with a line-by-line semantics preserving feature) and have bindings to/from the database, the view layer, the controller and all the other variations generated in the appropriate Java/Swift/SQL/etc languages? And what if we could deploy modifications to that datatype (ex. adding a database field) in the same uniform way we do all other minor variations to a datatype? That is the "drastic QOL (quality of life) improvement" win my users asked for.

That QOL win deserves its own article. Yes, I'll post it when done.