dandelion9

il y a 3 moisdiscuss

Transducers don't really solve the same problem as async/await.

l’année dernièrediscuss

Your cited examples all make sense in the context of the article. How is a zero-click exfiltration of sensitive data vuln not "real security"?

Specialists require nuanced language when building up a body of research, in order to map out the topic and better communicate with one another.

dandelion9

l’année dernièrediscuss

Of those, scrypt or argon2id. PBKDF2 is for FIPS compliance.

dandelion9

l’année dernièrediscuss

At a basic level any Lisp-like with an editor integrated REPL lets you put your cursor over the `greet` invocation below and evaluate it, and have the results shown in the manner of your choice (IDE window, inline temporary comment, etc).

This is all in the file as saved to your version control:

  (defn greet [name] 
    (-> (str "Hello, " name "!")
         println))

  (comment
    (greet "worldsayshi"))

It's 90% of the way to being a test already, just from the typical workflow.

dandelion9

l’année dernièrediscuss

[flagged]

dandelion9

l’année dernièrediscuss

I agree. It's career-driven bullshit bingo. It gives junior's an opportunity to gain an advantage over senior's ("Oh you don't know JavaScript micro-framework 2025 #10?") and everyone involved in billing for time (employees and consultant) a reason to "refactor" and keep the magic money tree around.

dandelion9

l’année dernièrediscuss

WebSockets are often blocked by corporate firewalls/proxies, I don't think it's as simple as saying WebSocket > HTTP

dandelion9

l’année dernièrediscuss

Strong types are not orthogonal to dynamic types, but I'll assume you're referring to static typing instead. My opinion on this is static type systems are great and provide amazing fit when you can model an entire system (e.g. a compiler). I think they are overrated for typical business software subject to change over time. IMO this is because business data tends to outlive any particular code base, or compiler version.

The way I see it is there's a spectrum of ways of handling this, from type systems, validation code, documentation, integration tests (validating runtime behaviour), and static analysis tooling, but I don't agree that a static type system is the best (and is often only barely adequate) way of integrating modules. The optimal solution is going to vary based on each project's requirements: e.g., is the modular code going to be consumed via networked API or as a library, and is it internally controlled or third-party? How many teams are going to be working on it? How much care has been taken with backwards compatibility? If we break the interface of some random minor function every update, a static type system may help, then again if it's just for our team: who cares? I'm sure we've all seen updates make internal modifications that break runtime behaviour but don't alter data models or function signatures in a way that get's picked up by a compiler.

Even in the most extreme type systems, interfaces are eventually going to need documentation and examples to explain domain/business logic peculiarities. What if a library interface requires a list in sorted order? Is it better to leak a LibrarySortedList type into the caller codebase? The modularity starts to break down. The alternative is use a standard library generic List type, but you can't force the data to be sorted. To encode this type of info we need dependent types or similar. A different example would be a database connection library, every database supports different key/value pairs for connection strings. If the database library released a patch which deprecated support for some arbitrary connection string param, you wouldn't find out until someone tried to run the code. Static analysis tools may catch common things like connection strings, but IME there's always some custom "stringly" typed values in business applications, living in a DB schema written 10+ years ago.

We also have to consider that the majority of our data arrives serialised, from files or over the wire. It's necessarily constrained to generic wire protocols, which have lower fidelity than data parsed into a more featured type system. Given that this type of data is getting validated or rejected directly after deserialisation, how much extra value is derived from having the compiler reiterate your validation code? Non-zero for sure, but probably not as much as we like to think.

dandelion9

l’année dernièrediscuss

Based on the averages, a DSL is going to suck and be a curse upon your future self/maintainers.

You provided a Clojure alternative, but without using the precise feature designed to alleviate this problem: transducers[0]. Transducers are the combination of functional composition and an indirection designed to decouple the data transformation pipeline from any specific source (e.g. async vs in-memory doesn't matter).

[0] https://clojure.org/reference/transducers

dandelion9

l’année dernièrediscuss

Structural editing and editor-REPL integration

dandelion9

l’année dernièrediscuss

- Dynamic languages are good, actually. IDE auto-completion and full-project renaming are the features that hit above their weight when using static type systems. IMO the remaining benefits of static types are within the same order of usefulness as the pros and cons of dynamic langs; You can argue about them on a case by case basis. This means static types aren't inherently better than dynamic languages (which is the popular opinion of the day), there's just a tooling issue right now. Therefore, dynamic langs will eventually make a comeback in popularity.

dandelion9

l’année dernièrediscuss

- 90% of abstraction is dreadful. That means _your_ particular abstraction is almost certainly bad, and we don't want to learn it.

- There is a lack of respect for the history of programming. IMO it has caused the industry to be stuck in a perpetual cycle of half-baked rediscovery.

- Similarly, a type of "FAANG-syndrome" exists and allows sub-par ideas to take over mind share of the industry. Once a technology picks up enough momentum, it will snowball and we're stuck working with legacy trash almost immediately. Developers legitimately seem to believe each trend is good.

- Our industry's shared vocabulary is too weakly defined. Phrases like "The right tool for the job" are ubiquitous but essentially meaningless and used as a form of shorthand "I currently feel this is correct". If we had a real professional lexicon, the first thing juniors would learn would be to enumerate reasoning to a precise degree. IME most "senior" devs can barely do it.

comments