mgsloan2

Joined 5 years ago

Karma

Submissions

Member since

Aug 10

Recent submissions

A cross-crate dead code analysis would mean that compilation of a crate now depends on information about its dependents. This would break reuse of compiled crates and cause recompiles when the analysis changes.

Something does seem a little off about this, though. Ideally for this `Debug` case there would be an annotation that says "compile this lazily, don't inline". Maybe there doesn't even need to be a new annotation, just `#[inline] #[cold]`. Which looks pretty weird, but might work already.

Comment · 1 year ago

My homedir is just a git repo, similar to https://www.atlassian.com/git/tutorials/dotfiles. The .git folder has a different name so that git commands aren't accidentally applied to it. What I love most about this is keeping my homedir clean - I can see what files are new (untracked) and either delete them or add to .gitignore

Comment · 1 year ago

Very fun to peruse! Curious why the olivetti typewriter has such strangely shaped key caps.

While it seems like OLPC didn't really achieve the full vision of the project, I have some anecdata of success - my coworker got an OLPC when young (otherwise without access to computers), learned to code on it, and is now an awesome programmer.

Comment · 1 year ago

Collection of data from code completions is off by default and opt-in. It also only collects data when one of several allowlisted opensource licenses are present in the worktree root.

Options to disable crash reports and anonymous usage info are presented prominently when Zed is first opened, and can of course be configured in settings too.

Comment · 1 year ago

You could, but it is extremely expensive to train an LLM that is competitive on coding evals. So, I was assuming use of a model someone else trained.

Also, if it is only trained on code, it's likely to miss out on all the world knowledge that comes from the rest of the data.

Comment · 1 year ago

Sounds like cool stuff, along the lines of structure editing!

The question is not whether it can work, but whether it works better than an edit tool using textual search/replace blocks. I'm curious what you see as the advantage of this approach? One thing that comes to mind is that having a cursor provides some natural integration with LSP signature help

Yes agentic loop with diagnostic feedback is quite powerful. I'd love to have more controllable structured decode from the big llm providers to skip some sources of needing to loop - something like https://github.com/microsoft/aici

Comment · 1 year ago

I agree the current way tools are used seems inefficient. However there are some very good reasons they tend to operate on code instead of syntax trees:

* Way way way more code in the training set.

* Code is almost always a more concise representation.

There has been work in the past training graph neural networks or transformers that get AST edge information. It seems like some sort of breakthrough (and tons of $) would be needed for those approaches to have any chance of surpassing leading LLMs.

Experimentally having agents use ast-grep seems to work pretty well. So, still representing a everything as code, but using a syntax aware search replace tool.

Comment · 1 year ago

See for example https://opensource.google/documentation/reference/using/agpl...

> Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

Comment · 2 years ago

Doesn't seem like its proven to work, but looks like it can be purchased, called "Profi Nasal Spray".

Comment · 2 years ago

Whoah, that interpretation seems pretty wild to me. They put a lot of effort into building a pizza oven and someone else tore it down, and they should feel nothing about this?! If an artist sells their painting they shouldn't care if the new owner paints over a section?

Beyond the sentimental attachment to the pizza oven, I'd be bothered by the sheer inefficiency of it.

Comment · 3 years ago

https://mgsloan.com - 11 posts about unorthodox computer ergonomics. 6 posts about Haskell ideas / weird tricks. Haven't posted in a couple years but would like to get back to it. Notable HN discussions:

- https://news.ycombinator.com/item?id=28118381 - Supine Computing (2019)

- https://news.ycombinator.com/item?id=21842663 - Outdoor Computing with a Deck Desk

Comment · 3 years ago

Same path for me, I like the v-moda headphones a lot, but the hinge mechanism is way too fragile, and the charge port broke, so the bluetooth pair was my last v-moda headphone. I also switched to beyerdynamic and have been very happy with them. Only downside of this durability is that they are not foldable - would be great to have headphones with a high durability folding mechanism

Comment · 3 years ago

I love this concept! When I got tired of replacing headphones in the past I got some beyerdynamic dt770 modded by jfunk.org. They are repairable and durable. Though they are not natively bluetooth, can use a short cable + qudelix 5k to make them wireless. No noise cancelling.

Would be very nice to have durable / repairable noise cancelling headphones. These headphones from fairbuds look great overall, but I'm skeptical of the durability of the hinges.

Comment · 3 years ago

> if your type-system is sufficently strong to express this

No fanciness needed, just plain old sum types. It is certainly possible to express those invariants directly in languages with a dependent type systems or refinement types like in liquid haskell - see https://ucsd-progsys.github.io/liquidhaskell-tutorial/Tutori.... It's typically much easier to reason about and use sum types, though.

Of course these examples are trivial and silly, but I see instances of these patterns all the time in big co software, and of course usually the invariants are far more complex but many could be expressed via sum types. I've seen loads of bugs from constructing data that invalidates assumptions made elsewhere that could have been prevented by sum types, as well as lots of confusion among engineers about which states some data can have.

> Field X is only set if field Y is true

Original gnarly C style pattern:

    struct TurboEncabulatorConfig {
        // When true, the turbo-encabulator must reticulate splines, and 'splines'
        // must be non-null. When false, 'splines' must be null.
        bool reticulate_splines;
        struct Splines *splines;
    };

Rust (let's ignore pointer vs value distinction):

    enum TurboEncabulatorConfig {
        NonReticulatingConfig,
        ReticulatingConfig { splines: Splines },
    }

> If field X is non-null then field Y must be null and vice-versa.

Original gnarly C style pattern:

    struct TurboEncabulatorConfig {
        // When non-null, lunar_waneshaft must be null. 
        struct Fan *pentametric_fan;
        // When non-null, pentametric_fan must be null.
        struct Shaft *lunar_waneshaft;
    };

Rust:

    enum TurboEncabulatorConfig {
        PentametricTurboEncabulator { pentametric_fan: Fan },
        LunarTurboEncabulator { lunar_waneshaft: Shaft },
    }

Comment · 3 years ago

In my experience with languages that lack concise sum types and pattern matching, you end up with data types that have lots of implicit invariants. If you find yourself writing docs or thinking in your head things like "Field X is only set if field Y is true" or "If field X is non-null then field Y must be null and vice-versa", then these are indications that sum types would model the data better. Then these invariants can be followed by construction, and it becomes clear what's available at data access - great for interface clarity, robustness, dev tools, morale, etc.

Relatedly, storing booleans is a smell, imho typically an enum or sum type is always better in languages that have concise syntax for these. True and False are meaningless without context, and so can easily lead to errors where they are provided to a different context or generally misused due to a misunderstanding about the meaning.