Kissaki

joined 2 years ago
MODERATOR OF
[–] Kissaki@programming.dev 2 points 1 hour ago

This part from the article supports this sentiment:

In a pleasant surprise, reactions have been positive. Throttled organizations were "surprised and apologetic," mistaking issues for malice rather than "ignorance, unawareness."

[–] Kissaki@programming.dev 4 points 2 hours ago

I sneakily changed our pipeline to pull from the in-house docker registry, and for pipelines to require pulling from package repos only when locks changed. Our CI is faster than every other team, but nobody noticed.

So yeah, charge the companies! Please!

How come this is not an obvious improvement opportunity that materializes in other teams too, and visibly so, rather than "sneakily" hidden?

Isn't it better not only for performance but also for reliability?

[–] Kissaki@programming.dev 1 points 2 hours ago

Yeah, I was quite irritated copying that for the quoting 😅

[–] Kissaki@programming.dev 6 points 2 hours ago

The article doesn't even mention this critical risk and history. Huge gap.

[–] Kissaki@programming.dev 3 points 2 hours ago* (last edited 2 hours ago)

Think about whether TODOs will be revisited, and how you can guarantee that. What do you gain and lose by replacing warnings with TODOs.

In my projects and work projects, I advocate for:

  • Warnings and TODOs are fine only in initial development before release/stability and in feature branches during development
  • TODOs are almost never revisited, so document state and information instead of hypotheticals; document opportunities over TODOs, document known shortcomings and risks, etc
  • If there is good reason to keep and ignore warnings, document the reasoning, and we can update our CI/Jenkins quality gate to a new baseline of accepted warnings instead of suppressing them (this pretty much never happens)

Dotnet warning suppression attributes have a Justification property. Editorconfig severity, disabling, suppression can have a comment.

If it's your own project and you know when and how you will revisit, what do you gain by dropping the warning? A no-warning, but then you have TODOs with the same uncertainties?

[–] Kissaki@programming.dev 2 points 1 day ago

I do. But I'm very selective and critical in choosing and trusting the right ones. They're also not my only source.

I don't think YouTube reviews are any worse than other forms of reviews. There are plenty of bad text reviews out there, too.

[–] Kissaki@programming.dev 3 points 1 day ago* (last edited 1 day ago) (1 children)

It's a fund you donate to; they invest the money, then fund open source with the investment gains.

I posted a comment on this other post that summarizes the most relevant (because it wasn't clear to me either, and as a note/explanation to myself too).

 

About Deno:

Deno is an open-source JavaScript runtime for the modern web. Built on web standards with zero-config TypeScript, unmatched security, and a complete built-in toolchain.

 

Uiua () is a general-purpose array-oriented programming language with a focus on simplicity, beauty, and tacit code.

Uiua lets you write code that is as short as possible while remaining readable, so you can focus on problems rather than ceremony.

The language is not yet stable, as its design space is still being explored. However, it is already quite powerful and fun to use!

Uiua uses special characters for built-in functions that remind you what they do!

⚂ # Random number
⇡8 # Range up to
⇌ 1_2_3_4 # Reverse

cross-posted from: https://programming.dev/post/46403010

Sample with fibonacci:

⍥◡+9∩1 is the fibonacci in this language


Commenter maegul writes on the Programming community post:

I tried to go through the tutorial a year or so ago.

I can’t recall when, but there’s a point at which doing something normal/trivial in an imperative language requires all sorts of weirdness in Uiua. But they try to sell it as especially logical while to me they came off as completely in a cult.

It’s this section, IIRC: https://www.uiua.org/tutorial/More%20Argument%20Manipulation#-planet-notation-

When they declare

And there you have it! A readable syntax juggling lots of values without any names!

For

×⊃(+⊙⋅⋅∘|-⊃⋅⋅∘(×⋅⊙⋅∘)) 1 2 3 4

Which, if you can’t tell, is equivalent to

f(a,b,c,x) = (a+x)(bx-c)

With arguments 1, 2, 3, 4.

I wanted to like this, and have always wanted to learn APL or J (clear influences). But I couldn’t take them seriously after that.

[–] Kissaki@programming.dev 7 points 1 day ago* (last edited 1 day ago)

Data-driven grant model. There’s no perfect model for distributing OSS grants. Our approach is an open, measurable, algorithmic (but not automatic) model, […] We’re finalizing the first version of the selection model after the public launch, and its high-level description is at osendowment/model.

The fund invests all donations in a low-risk portfolio and uses only the investment income for grants, making it independent of annual budgets and market volatility. Even a modest $10M fund at this rate would generate ~$500K every year — enough for $10K grants to 50 critical open source projects.

Currently standing at $700k.

Regarding the model:

We aim to focus our support on the core of open-source ecosystems — like ~1% of packages accounting for 99% of downloads and dependencies. Our model shall be a data-driven approximation of the global usage of the open-source supply chain, helping to detect its most critical but underfunded elements.

[–] Kissaki@programming.dev 5 points 3 days ago* (last edited 3 days ago) (1 children)

Screenshots of both:

| "Classic" | "New" | |


|


| | | |

Well, you can see I use dark color scheme, which apparently got lost. Make a guess how much better I like that.

It's not my full monitor width because of vertical browser tabs, but even then the horizontal distance between left nav bar and top right nav toolbar is horrendous.

The spacing is wasteful, the sizing is unnecessarily big.

It's worse in every way. Less accessible, less readable, less scannable, less overview.

I wish they would simply drop their new design draft completely.


For anyone visiting the site thinking "looks like before for me" like I did, at the top there's a link to "try out the new site".

Their blog post, research blog post, previous community feedback, feedback form.

[–] Kissaki@programming.dev 3 points 3 days ago* (last edited 3 days ago)

We onboarded our team with VS integrated Copilot.

I regularly use inline suggestions. I sometimes use the suggestions that go beyond what VS suggested before Copilot license.. I am regularly annoyed at the suggestions moving off code, even greyed out sometimes being ambiguous with grey text like comma and semicolon, and control conflicting with basic cursor navigation (CTRL+Right arrow)

I am very selective about where I use Copilot. Even for simple systematic changes, I often prefer my own editing, quick actions, or multi cursor, because they are deterministic and don't require a focused review that takes the same amount of time but with worse mental effect.

Probably more than my IDE "AI", I use AI search to get information. I have the knowledge to assess results, and know when to check sources anyway, in addition, or instead.

My biggest issue with our AI is in the code some of my colleagues produce and give me for review, and that I don't/can't know how much they themselves thought about the issues and solution at hand. A lack of description, or worse, AI generated summaries, are an issue in relation to that.

/edit: Here is my comment on the post four months ago.

[–] Kissaki@programming.dev 10 points 3 days ago

And it's so popular! It must be good!

[–] Kissaki@programming.dev 1 points 4 days ago

Many times I've used piefed, wrote a comment, some longer some shorter, and without fail, it denied posting after writing it out but without telling me specifically why I can't post. Just no permission. Consequently, it never stuck to me.

 

The reasons behind this rise of the latency is mainly that systems have become more and more complex and developers often don't know or don't understand each part that can impact the latency.

This website has been made to help developers and consumers better understand the latency issues and how to tackle them.

 

After working on my weird shooter game for 5 years, I realized I'm never going to be finishing this project. In this video I explain why I've decided to quit my game and what is next.

 

From the README:

What is KORE?

KORE is a self-hosting programming language that combines the best ideas from multiple paradigms:

Paradigm Inspiration KORE Implementation
Safety Rust Ownership, borrowing, no null, no data races
Syntax Python Significant whitespace, minimal ceremony
Metaprogramming Lisp Code as data, hygienic macros, DSL-friendly
Compile-Time Zig comptime execution, no separate macro language
Effects Koka/Eff Side effects tracked in the type system
Concurrency Erlang Actor model with message passing
UI/Components React/JSX Native JSX syntax, components, hot reloading
Targets Universal WASM, LLVM native, SPIR-V shaders, Rust transpilation

Example

// Define a function with effect tracking
fn factorial(n: Int) -> Int with Pure:
    match n:
        0 => 1
        _ => n * factorial(n - 1)

// Actors for concurrency
actor Counter:
    var count: Int = 0

    on Increment(n: Int):
        count = count + n

    on GetCount -> Int:
        return count

fn main():
    let result = factorial(5)
    println("5! = " + str(result))
 

By streaming CSS updates/appends through an open HTTP connection

 

Girard's insight was that communities resolve internal conflict through scapegoating: the selection of a victim to bear collective guilt, whose expulsion or destruction restores social cohesion. The scapegoat need not be guilty of the crime attributed to it; it need only be acceptable as a target.

Some dangerous individuals, however, institutionalize such ritualistic practices into what I call Casus Belli Engineering: the use of perceived failure as pretext to replace established systems with one's preferred worldview. The broken feature is the crisis that demands resolution. The foundation becomes the scapegoat, selected not for its actual guilt but for its vulnerability and the convenience of its replacement. And in most cases, this unfolds organically, driven by genuine belief in the narrative.

The danger is not the scapegoating itself; humans will scapegoat. The danger lies in those who have learned to trigger the mechanism strategically, who can reliably convert any failure into an opportunity to destroy what exists and build what they prefer.

The linked article title is “Casus Belli Engineering: The Sacrificial Architecture”, which I didn't find particularly descriptive. I used the second headline, “The Scapegoat Mechanism”. It doesn't include the architecture or strategy aspects, but serves well as a descriptor and entry point in my eyes.

 

There exists a peculiar amnesia in software engineering regarding XML. Mention it in most circles and you will receive knowing smiles, dismissive waves, the sort of patronizing acknowledgment reserved for technologies deemed passé. "Oh, XML," they say, as if the very syllables carry the weight of obsolescence. "We use JSON now. Much cleaner."

 

In our previous post “Reinventing how .NET Builds and Ships”, Matt covered our recent overhaul of .NET’s building and shipping processes. A key part of this multi-year effort, which we called Unified Build, is the introduction of the Virtual Monolithic Repository (VMR) that aggregates all the source code and infrastructure needed to build the .NET SDK. This article focuses on the monorepo itself: how it was created and the technical details of the two-way synchronization that keeps it alive.

 

Users are not allowed to create Issues directly in this repository - we ask that you create a Discussion first.

Unlike some other projects, Ghostty does not use the issue tracker for discussion or feature requests. Instead, we use GitHub discussions for that. Once a discussion reaches a point where a well-understood, actionable item is identified, it is moved to the issue tracker. This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on.

This approach is based on years of experience maintaining open source projects and observing that 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features). Of the features requests, almost all are underspecified and require more guidance by a maintainer to be worked on.

Any Discussion which clearly identifies a problem in Ghostty and can be confirmed or reproduced will be converted to an Issue by a maintainer, so as a user finding a valid problem you don't do any extra work anyway. Thank you.

view more: next ›