forgotpwd16

Could extract the toolkit into its own package and publish a CLI as a pdfkit alternative, so could run it like `npx bentopdf-cli merge {}`.

Overall not easy to read article. Quite confusing. It makes case rather rewriting in Rust* should instead rewrite in formal spec and generate the code, which is now easier due to LLMs, but why that code cannot be Rust? The memory model and structure may make Rust better AI target and helpful in cases human intervention is required.

*Something most here call waste of time anyway.

A (prompted in English) AI-generated Python-implemented (prog lang in part designed to mimic English) project converting translated-from-English-non-English asm into standard (English) asm. A project made without writing a single line of code to teach low-level coding concepts. This gotta be satire.

Can say install.md is to INSTALL.md what conventional are to ad-hoc commit messages.

Some are already doing it with scripts: https://github.com/andisearch/claude-switcher. Install.md is just specialization of this.

Looks interesting but Markdown is the only relevance. Submitted tool/page is about sharing/hosting. Markdeep is about making self-contained Markdown-written HTML pages.

Looks nice, but if it was just because needed such tool, there're already mdshare and peerpad. There's also jbt's editor that saves state on URL, i.e., https://jbt.github.io/markdown-editor/#U1bwyOTics9XSEpMzlYoy....

Ah, I see. My only other caveat (other models/agents) is addressed in upcoming work to do. Otherwise, looks good, simple/straightforward UI, functional. Great work overall.

>Do I need a Claude subscription?

>Yes, 1Code works with your Claude Pro or Max subscription. Sign in with your Anthropic account and use your existing subscription. We charge separately for the 1Code app.

Is this even after the recent events; Anthropic banning 3rd-party access to the Claude Pro/Max subscriptions and only allowing API access? Tool is nice but most certainly not* 800$ nice.

*Based on heavy Claude Max users here, the people that will be running 3-4 agents, saying API would've cost them $1k+.

Parody definition is humorous imitation so the ones I mentioned definitely are. Omgrofl (and similar LOLCODE) can be argued is also satire in regards to adoption of internet slang/memes in formal environments and chasing trends in programming/engineering design. The other two agree they aren't. But to me seemed, considering submitted language and their own examples, GP was asking for parody/thematic languages, which is why included those. The wiki links weren't meant to say joke/thematic == satire/parody. It's just that the wiki lacks explicit "parody" and "satire" categories, instead listing any relevant to those topics under the two given ones.

Some well-known satire/parody languages are Omgrofl, Shakespeare, ArnoldC, but there're many more. Can check https://esolangs.org/wiki/Category:Thematic & https://esolangs.org/wiki/Category:Joke_languages. But although weird esolangs, don't see how Velda and Piet be considered satire.

A rare example of language implemented atop PHP. Should've made with Llama for extra Meta points.

  >>> type(hodor) is hodor
  True

Will've been perfect if this also returned hodor.

Done few weeks ago: https://github.com/DGoettlich/history-llms (discussed in: https://news.ycombinator.com/item?id=46319826)

At least the model part. Although others made same thought as you afaik none tried it.

This isn't a very sane plan. The ~300 LOC example mini_grep (https://github.com/z-libs/Zen-C/blob/main/examples/tools/min...) compiles to a ~3.3k LOC monstrosity (https://pastebin.com/raw/6FBSpt1z). It's easier to rewrite the whole thing than going from the generated code.

At least for now, generated code shouldn't be considered something you're ever supposed to interact with.

They're are certainly going to be lots of languages because now with LLMs it's easier (trivial?) to make one + library (case in point: just within last month there're have been posted here ~20 new langs with codebases 20k~100k LOC) but don't really see them competing. Rust and Zig brought actual improvements and are basically replacing usecases that C++/C had limiting the space available to others.

Basically C2/C3 but Rust influenced. Missed chance to call it C4.

Yeah, it's in a weird state of officially being stuck to legacy channels/profiles and unofficially having moved to flakes. Excessive RAM usage with nix-env, which theoretically can be improved but requires deep design changes, was what driven me to flakes.

There's also the issue, which is also noted by the author, that LLM-optimization quite often becomes, when shouldn't be just that, token-minimization.

There was one other just yesterday: https://news.ycombinator.com/item?id=46571166

Wow, quite the extended article. Feels like something I'ld read on Substack, or similar, rather Twitter. (Actually... how happened link is Twitter rather X?) Well written overall. Basically, it's entrepreneurship 101: learn, keep notes, communicate ideas, create, make a business out of it.

Arch package management isn't just pacman, but also makepkg, namcap, dbscripts, devtools (pkgctl and others). As end-user/sysadmin you may not even have heard about them but distro is built atop them.

Considering Arch is one of the big upstream distros and, alongside Debian and NixOS, one of the big community-run ones, standardizing and improving its foundations is certainly not a waste. Moreover some results are usable beyond Arch, e.g. VOA (for storage and retrieval of signature verifiers). Choosing Rust though does impose some portability limitations. (Even if makes sense to not want to use C in 2020s.)

Then comparison will've been Haxe to TypeLua rather TypeScript. Typing addition seems inevitable.

They aren't book-length chapters. E.g. https://gibbok.github.io/typescript-book/book/strictnullchec... is one paragraph, https://gibbok.github.io/typescript-book/book/void-type/ is 1 sentence plus 1 3-line example. Near all of those "chapters" seem to be bit more than that. 1~2 paragraphs plus 1~2 code examples.

Depends on stage. Codex/Claude-generated code have hinting and doc strings, and will gladly add tests for every change you're doing. (That's why vibe coded projects have a gazillion tests.)

Startup time depends on hardware and (assume) features you're enabling. Better hardware and less features, less lag.

Issue is the cognitive overhead to know 2 distinct shell languages. One you use, and one (almost) everyone else uses. If later isn't of your concern and Fish is all you interact with then no issue whatsoever for interactive or/and scripting use.

>If I understand how the underlying physics and dynamics are working but don't know how to write the code then theres no world where I could make something like this.

You could learn coding same way as you learned the physics and dynamics. Programming and physics aren't mutually exclusive. Actually every physicist is (was?) required to know (multiple) programming (languages).

>If I were to be someone who just tells AI "implement drag"

That'll mean at least you understand drag. Could do even worse, regards to learning at least rather result, prompting something like "make a cool-looking physically-realistic 2d rocket launch simulator", which we're at point that will most certainly return a functional app.

>but im understanding whats happening

Do you though? You depend on AI correctly translating your natural language input to code. Though arguably this is something LLMs excel at, since math (logic) also plays role you've to be able to at least read and review the resulting code for correctness. (Assuming you actually care about the physical accuracy that is.)

The actual important part is consumer-grade. Because WebKitGTK itself is already commercially incentivized, developed primarily by Igalia (a quite underrated firm regarding their contributions in open source) who are offering consulting services mainly in embedded-related industries.