Don't Be Afraid of Types • Hacker News Board

Re: Don't Be Afraid of Types

#231

Post by lurking_swe » Thu, Mar 27, 2025, 2:01 AM UTC

DaiPlusPlus wrote: post #82

lurking_swe wrote: post #54

Earlier quoted context omitted.

not to mention having some actual confidence when making changes to a project! especially one you didn’t author.

...even in a strictly-statically-typed language with a perfectly expressive type-system, it would be unwise to rely _only_ on a "Build succeeded!" message for having confidence in any changes to the system: there's no substitute for well-trodden unit and integration tests for any codebase of nontrivial importance or complexity.

it does eliminate an entire class of issues thougj. The typical “property not found” type of issues that are common in vanilla javascript, python, etc.

Having types helps the IDE help YOU! That’s my favorite part about types and a strong IDE like Webstorm or IntelliJ. I agree it’s not a substitute for proper testing though.

Re: Don't Be Afraid of Types

#232

Post by turtleyacht » Fri, Mar 28, 2025, 8:44 PM UTC

veqq wrote: post #223

turtleyacht wrote: post #219

Earlier quoted context omitted.

> missing language features Yes, Holub mentions C folks had to make do with what they had--but that those implementations, despite differences, would point to one or another common pattern (or done enough times similarly to be a pattern). > bug reports against your programming language Yes and no. I daresay no programming language can expect to be a universal one and still have the same ergonomics as a purposeful one…

> We've only been speaking in terms of single languages, though. Have you combined different programs together before and thought, "Hmm, this is kind of like a pattern for..."? It's metacircular all the way down. In Forth or Tcl, every command can be its own program. Deploying over many machines has similar dynamics to multithreading on one etc. The same concepts, notation etc. apply - you abstract over them and voil…

> OOP without the boilerplate

Agreed. Dr. Samek says as much too and presents an object-oriented version of C, C+, in Practical Statecharts in C/C++.

Thank-you for your replies. If you happen to see this comment, I wanted to ask about reification.

The pattern is the idea, the design reifies--"makes real"--the pattern. Something else--whether code, constellation of programs, or pigeons--implements the design.

There can be many reifications of a pattern, and there can be many implementations of a design.

Do those ideas ring true?

> compile your company

I've seen this done. Human-readable instructions coexist with SQL snippets and scripts. However, once it becomes tribal knowledge, folks may not understand it.

If manual approvals had also been processed through a pipeline instead of emails and "stop and start," it may have still been in use.

Re: Don't Be Afraid of Types

#233

Post by Capricorn2481 » Sun, Mar 30, 2025, 8:13 PM UTC

gleenn wrote: post #22

motorest wrote: post #9

Earlier quoted context omitted.

> Every darn little thing in Java needs a name. Don't all types need names, regardless of what language you use? Look at typescript, and how it supports structural typing. They don't seem to have a problem with names. Why do you think Java has that problem when nominal type systems simplify the problem? > There's no need to declare a type ObjectWithFirstNameAndLastName. It would be quite silly. Naming things is hard,…

All types don't need names exactly like the Clojure example shows. There is no "type" for the argument, likely it's a map under the hood. And maps with keywords are used broadly across Clojure projects as a method of pass groups of data and no, you don't have to name that arbitrary collection of data. Rich Hickey has an amazing presentation on the silliness of a commonly used Java Web Request library where the vast m…

> Hickey is also famous for saying he would rather a few data structures and a 100 little algorithms instead of 10 data structures and 10 algorithms per data structure

This is a quote from Alan J. Perlis, not Rich Hickey, and it's certainly not what Rich is famous for.