dollspace-gay

Verified Spec-Driven Development (VSDD)

The Fusion: VDD × TDD × SDD for AI-Native Engineering

Overview

Verified Spec-Driven Development (VSDD) is a unified software engineering methodology that fuses three proven paradigms into a single AI-orchestrated pipeline:

• Spec-Driven Development (SDD): Define the contract before writing a single line of implementation. Specs are the source of truth.
• Test-Driven Development (TDD): Tests are written before code. Red → Green → Refactor. No code exists without a failing test that demanded it.

mucaho

First creation date: 2025-04-20
Latest update date: 2025-04-24

Changelog

• 2025-04-24: Updated solution for state-threading

Table of Contents

• Introduction
• State threading

kubukoz

runner.dialect = scala3
runner.dialectOverride.allowSignificantIndentation = false
# allows `if x then y`
runner.dialectOverride.allowQuietSyntax = true

Yummy-Yums

import zio._

case class Doc(
    title: String,
    description: String,
    language: String,
    format: String,
    content: Array[Byte]
)

kitlangton

package tttt

// Awesome 😄 That looks great. It maintains all of the properties of the Frank (or, Langton style 😛) encoding—where one can recurse with different handlers and short-circuit trivially—without losing the tail-recursive stack safety. And I fully trust you when it comes to the JIT-ability of it all!
// The only issues are minor UX ones, in that it could be confusing for the user to know whether to call

import izumi.reflect.Tag

type Id[T]    = T
type Const[T] = [U] =>> T
type MX[T]    = Any

kryptt

package eo

import cats.{Applicative, Bifunctor, Functor, Traverse}
import cats.arrow._
import cats.implicits._

trait Accessor[F[_, _]] {
  def get[A]: [X] => F[X, A] => A
}

chaotic3quilibrium

Effective Scala Case Class Patterns

Version: 2022.03.02

Available As

quelgar

Every Argument for Static Typing Applies to Typed Errors

Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.

An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.

Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty

l3nz

accountsd using 400% CPU on MacOS Catalina 10.15.7 (19H2)

TL;DR: Still open - see below.

This morning I woke up to some not-so-nice surprise - my 2018 MPB 13" would be kind of totally unusable. The accountsd process was stable at 400%, battery was going like ice-cream in the Sahara, and opening up LibreOffice was like a major achievement.

I did check the logs (that were growing at like 500 lines per second) and I saw a lot of lines at FAULT level:

fault 07:54:04.271342+0200 accountsd Unentitled access by client 'CallHistoryPlugi' (selector: accountsWithAccountType:handler:)

travisbrown

See this now-deleted thread (where Baez starts a long analogy with "Not just people, but also mathematical objects, can be oppressed!") and this tweet for context.

The responses quoted here have been described as "Thought Stasi" bullying (etc.), but in my reading most are respectful, very few are even confrontational, and only a couple are impolite.

This list is the result of a quick search and I may have missed relevant replies to the original thread, but if there are omiss