12 ms·

CUPID – For Joyful Coding

69 points by dustinmoris 5y ago

spand 5y ago
Has anyone tried the D in a multi module jvm setup ? I attempted this[1] in Kotlin with Gradle but breaks in IDEA which is pretty much a dealbreaker. [1] https://github.com/spand/KotlinCUPID https://github.com/spand/KotlinCUPID
dlojudice 5y ago
Great article! The properties described are definitely something I look for in the software I create. Also, I can see a lot of these properties in our open-source project, especially Domain-based. The work we are doing goes a lot in this direction of closing the gap between the code, the developers and also the non-technical stakeholders. As the creator of BDD, I have great respect for Dan North's work.
eternityforest 5y ago
I don't think I'd feel a lot of joy if all apps were like like this. My personal set of properties might be more like: Correctness Just-works Robustness Standards-compliance Performance Encapsulation
- layer8 5y ago
  But CJRSPE isn’t a word. ;)
  - deleted 5y ago
    [deleted]
  - yoyohello13 5y ago
    If you change "Just-Works" to "It-Just-Works" it can be CRISPE.
    - mnsc 5y ago
      Or Epic Sr.! Who doesn't want to be an Epic Senior™?!
vinceguidry 5y ago
An anti-example from my own coding life. I work in a very iterative fashion, my favorite language is Ruby, which allows me to work as iteratively as my heart desires. Write one line of code, execute it, make sure it's doing exactly what I want it to be doing, then write another line of code. In order for an iterative coding workflow to be fun, I can't be jumping all over the place, one line at a time only please. But golang refuses to make that fun for me. I can turn the linter off, but the compiler is constantly, noisily, judging me, and the core golang team absolutely refuses to let me turn inconsequential errors off. So I'm constantly having to jump around the file to make the compiler happy with it's incessant complaints. I'm not using this variable, I don't have any new variables declared, so I gotta remove the ':' until it's time to add it back. Shut the heck up compiler! These are linting concerns! I wish desperately for language makers to start caring about workflow. It always seems to never even bother rating any kind of concern at all. I wish I could just stop using languages that don't respect coders.
throw10920 5y ago
Most of these are fine, but U is a massive mistake. The Unix philosophy is fine for tiny systems, but absolutely terrible for building any nontrivial system, because it causes the complexity of the system to grow super-linearly with the number of features - O(n^2), in big-O notation, where n is the intrinsic complexity of the application (roughly, the features you want) and the big-O measures the total complexity of the application. Why? Super quick breakdown: code has to be broken up into modules in order to prevent human brains from exploding, if the modules are too small then inter-module communication complexity dominates (because you then need a large number of modules to implement your features), if the modules are too large than intra-module implementation complexity dominates, and the Unix philosophy requires erring on the size of too-small modules. For empirical evidence: none of the non-trivial applications you use daily (bash, firefox, chrome, windows, linux, macos, blender, krita, gcc, cargo, llvm, npm, node, vim, emacs, vscode, sublime - whatever you want) are composed of a collection of Unix utilities, or the equivalent (flat program hierarchy consisting of thousands of call sites to hundreds of tiny functions). The evidence is very clear: the Unix philosophy does not work for anything but small systems.
- zozbot234 5y ago
  Modules can be built compositionally from smaller modules, even in the *nix shell - that's what a shell script is! Similarly, libraries can depend from other lower-level libraries. No flat structure is required, hence no huge increase in either implementation or communication complexity.
- jpitz 5y ago
  Contrary opinion: the Unix philosophy advocates a level of granularity larger than you posit - grep has a single responsibility, but is not a "tiny function"
- lambic 5y ago
  The "do one thing and do it well" philosophy can be taken to bad extremes, but the tools you list mostly fit the philosophy as it was intended. Vim is a text editor, it does that one thing and does it well. Firefox is a web browser, it does that one thing and does it well, notwithstanding attempts to cram everything into web browsing.
splittingTimes 5y ago
I like the idea of aligning on properties. Does not exclude to value certain principles as well. However, like with all abstract "code quality" properties (modularity, predictability, robustness, encapsulation, etc) how can you quantify/measure how modular an application or how predictable a code base is? It often comes down to a subjective "feeling".

69 points by dustinmoris 5y ago

Has anyone tried the D in a multi module jvm setup ? I attempted this[1] in Kotlin with Gradle but breaks in IDEA which is pretty much a dealbreaker. [1] https://github.com/spand/KotlinCUPID https://github.com/spand/KotlinCUPID

dlojudice 5y ago

Great article! The properties described are definitely something I look for in the software I create. Also, I can see a lot of these properties in our open-source project, especially Domain-based. The work we are doing goes a lot in this direction of closing the gap between the code, the developers and also the non-technical stakeholders. As the creator of BDD, I have great respect for Dan North's work.

eternityforest 5y ago

I don't think I'd feel a lot of joy if all apps were like like this. My personal set of properties might be more like: Correctness Just-works Robustness Standards-compliance Performance Encapsulation

layer8 5y ago
But CJRSPE isn’t a word. ;)
- deleted 5y ago
  [deleted]
- yoyohello13 5y ago
  If you change "Just-Works" to "It-Just-Works" it can be CRISPE.
  - mnsc 5y ago
    Or Epic Sr.! Who doesn't want to be an Epic Senior™?!

vinceguidry 5y ago

An anti-example from my own coding life. I work in a very iterative fashion, my favorite language is Ruby, which allows me to work as iteratively as my heart desires. Write one line of code, execute it, make sure it's doing exactly what I want it to be doing, then write another line of code. In order for an iterative coding workflow to be fun, I can't be jumping all over the place, one line at a time only please. But golang refuses to make that fun for me. I can turn the linter off, but the compiler is constantly, noisily, judging me, and the core golang team absolutely refuses to let me turn inconsequential errors off. So I'm constantly having to jump around the file to make the compiler happy with it's incessant complaints. I'm not using this variable, I don't have any new variables declared, so I gotta remove the ':' until it's time to add it back. Shut the heck up compiler! These are linting concerns! I wish desperately for language makers to start caring about workflow. It always seems to never even bother rating any kind of concern at all. I wish I could just stop using languages that don't respect coders.

throw10920 5y ago

Most of these are fine, but U is a massive mistake. The Unix philosophy is fine for tiny systems, but absolutely terrible for building any nontrivial system, because it causes the complexity of the system to grow super-linearly with the number of features - O(n^2), in big-O notation, where n is the intrinsic complexity of the application (roughly, the features you want) and the big-O measures the total complexity of the application. Why? Super quick breakdown: code has to be broken up into modules in order to prevent human brains from exploding, if the modules are too small then inter-module communication complexity dominates (because you then need a large number of modules to implement your features), if the modules are too large than intra-module implementation complexity dominates, and the Unix philosophy requires erring on the size of too-small modules. For empirical evidence: none of the non-trivial applications you use daily (bash, firefox, chrome, windows, linux, macos, blender, krita, gcc, cargo, llvm, npm, node, vim, emacs, vscode, sublime - whatever you want) are composed of a collection of Unix utilities, or the equivalent (flat program hierarchy consisting of thousands of call sites to hundreds of tiny functions). The evidence is very clear: the Unix philosophy does not work for anything but small systems.

zozbot234 5y ago
Modules can be built compositionally from smaller modules, even in the *nix shell - that's what a shell script is! Similarly, libraries can depend from other lower-level libraries. No flat structure is required, hence no huge increase in either implementation or communication complexity.
jpitz 5y ago
Contrary opinion: the Unix philosophy advocates a level of granularity larger than you posit - grep has a single responsibility, but is not a "tiny function"
lambic 5y ago
The "do one thing and do it well" philosophy can be taken to bad extremes, but the tools you list mostly fit the philosophy as it was intended. Vim is a text editor, it does that one thing and does it well. Firefox is a web browser, it does that one thing and does it well, notwithstanding attempts to cram everything into web browsing.

splittingTimes 5y ago

I like the idea of aligning on properties. Does not exclude to value certain principles as well. However, like with all abstract "code quality" properties (modularity, predictability, robustness, encapsulation, etc) how can you quantify/measure how modular an application or how predictable a code base is? It often comes down to a subjective "feeling".