4 ms·

Static typings + type inference Parse, don't validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/20

by valand 7y ago

Static typings + type inference Parse, don't validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... All libs/products should be pure functions, with input output documented, making libs/products predictable Use in-app event sourcing to reduce the need for global states states DoD https://youtu.be/yy8jQgmhbAU https://youtu.be/yy8jQgmhbAU In non bare-metal languages, this will be useful for readability For errors, return instead of throw

charlieflowers 7y ago
Thanks for that "Parse, don't validate" link. It definitely is the clearest explanation for type driven development I've found. Turns out, years ago I was writing some C# code and I found myself wanting to explore something like that. However, it wasn't idiomatic for C# (especially at the time), and I talked myself out of it. Since then, I've wondered if that's what people mean by type driven development. It's cool to see that is at least in the general ballpark.
- valand 7y ago
  Is C# nowadays friendly enough for type driven development? Using TypeScript daily, I have a great time with type driven development. (C# and TS was created by the same guy) I was never comfortable with Java community approach of automating stuff, with their heavy use of reflections, method name parsing instead of being strict in typings, use generics, macro, templating, etc.
  - charlieflowers 7y ago
    Well, you can "force" some of it ... make an object whose ctor can only succeed if a certain check passes, for example. You'd be using types in a way that pretty much no one in C# does (not idiomatic), except for maybe those who are explicitly trying to go for type driven development (for example, people doing things like railway oriented programming).
j88439h84 7y ago
> in-app event sourcing What's the difference between in-app and not?
- valand 7y ago
  Event sourcing is already widely used as app to app communication. But few realize that it is plausible to take that paradigm and use it for module to module communication in-app. That line serves as reminder to utilize that, not to exclude non in-app event sourcing
  - jlokier 7y ago
    I'd love to see a good example of in-app module-to-module event sourcing. By module to module, do you mean between very loosely decoupled systems such as microservices, or closely associated things like queues and method calls in a single-process process?
    - valand 7y ago
      Both in-process, inter-process, and inter-machine. The event sourcing technique really helps decouple components, reduce the need for higher order state. I work with TypeScript on daily basis and I'm in the middle of building this library to help with event sourcing and other stuffs. https://github.com/Kelerchian/florcky https://github.com/Kelerchian/florcky I'll be working with rust, C++, and C# in a few weeks due to professional demand and I might get somewhere with event-sourcing using those language. In the long run we might be utilizing wasm and ffi to introduce universal protocol for event sourcing.

by valand 7y ago

charlieflowers 7y ago

Thanks for that "Parse, don't validate" link. It definitely is the clearest explanation for type driven development I've found. Turns out, years ago I was writing some C# code and I found myself wanting to explore something like that. However, it wasn't idiomatic for C# (especially at the time), and I talked myself out of it. Since then, I've wondered if that's what people mean by type driven development. It's cool to see that is at least in the general ballpark.

valand 7y ago
Is C# nowadays friendly enough for type driven development? Using TypeScript daily, I have a great time with type driven development. (C# and TS was created by the same guy) I was never comfortable with Java community approach of automating stuff, with their heavy use of reflections, method name parsing instead of being strict in typings, use generics, macro, templating, etc.
- charlieflowers 7y ago
  Well, you can "force" some of it ... make an object whose ctor can only succeed if a certain check passes, for example. You'd be using types in a way that pretty much no one in C# does (not idiomatic), except for maybe those who are explicitly trying to go for type driven development (for example, people doing things like railway oriented programming).

j88439h84 7y ago

> in-app event sourcing What's the difference between in-app and not?

valand 7y ago
Event sourcing is already widely used as app to app communication. But few realize that it is plausible to take that paradigm and use it for module to module communication in-app. That line serves as reminder to utilize that, not to exclude non in-app event sourcing
- jlokier 7y ago
  I'd love to see a good example of in-app module-to-module event sourcing. By module to module, do you mean between very loosely decoupled systems such as microservices, or closely associated things like queues and method calls in a single-process process?
  - valand 7y ago
    Both in-process, inter-process, and inter-machine. The event sourcing technique really helps decouple components, reduce the need for higher order state. I work with TypeScript on daily basis and I'm in the middle of building this library to help with event sourcing and other stuffs. https://github.com/Kelerchian/florcky https://github.com/Kelerchian/florcky I'll be working with rust, C++, and C# in a few weeks due to professional demand and I might get somewhere with event-sourcing using those language. In the long run we might be utilizing wasm and ffi to introduce universal protocol for event sourcing.