5 ms·

This article feels like someone is defending their language. And that doesn’t bother me, but I don’t value that. I don’t care about what’s popular or what feel

by epgui 10mo ago

This article feels like someone is defending their language. And that doesn’t bother me, but I don’t value that. I don’t care about what’s popular or what feels most familiar. What I want is a dispassionate discussion of how different language features impact code quality, and I think you can only find that in more abstract discussions. The kind that turns people off with its talk of monads and applicatives.

SatvikBeri 10mo ago
Do you know of any articles/papers that try to do in-depth analyses of which features are helpful for building big systems? Most posts I can think of basically say "X language is good" or "Y language is bad", but I'd really be interested in arguments like "feature A is better at accomplishing goal Z than feature B"
- Towaway69 10mo ago
  That's a very good point. My experience is that for large project the architecture also becomes important. Large project have much code but if you can split out responsibility because your architecture allows this, then you keep your code concise. One feature Ruby has that helps here is creating Domain Specific Language without yacc or lex. This allows for concise code where its needed.
  - epgui 10mo ago
    There are languages much better suited for DSLs though.
  - SatvikBeri 10mo ago
    Not quite the same, but I find "data-oriented programming" to be a very strong method for managing large codebases. By that I mean having data structures that designate the end state that you want, having another set of code that gets you to those end states, and maintaining a pretty clear boundary between the two. (If you like with "Functional Core, Imperative Shell", this is a way to further divide the Functional Core.) It works well because it narrows the surface area of a lot of possible bugs: either your configuration is wrong, or your code doing the transformations is wrong.
    - Towaway69 10mo ago
      You kind of describe flow based programming (FBP) whereby data is passed to stateless functionality. Things like Unix pipes, Node-Red and n8n are inspired by FBP. I agree with what you describe, also reuse is simpler because code tends to be stateless.
- epgui 10mo ago
  There are some programming language journals that people like to dismiss as “academic”. But “academic” is what I value here.
  - SatvikBeri 10mo ago
    There are a lot of programming language journals – are there ones you'd recommend specifically for discussions of tradeoffs between features?
jasonpeacock 10mo ago
> What I want is a dispassionate discussion of how different language features impact code quality This can be difficult because code quality, productivity, safety are hard to objectively define and measure, so we always fall back to differences in interpretation and experience.
- SatvikBeri 10mo ago
  I would be interested in serious attempts to argue for this, even if they can't reasonably be backed up by data. For example, I think there's a pretty strong argument that immutability makes it easier to write multithreaded code (perhaps at some performance cost), because it entirely prevents common types of bugs. Similarly there's a good argument that making methods open to extension (like Kotlin or Julia) makes it easier for an ecosystem to adopt unified APIs without explicit coordination. There's obviously a very strong argument that Garbage Collection prevents a lot of memory safety bugs, at costs to interoperability and performance.
hartator 10mo ago
> dispassionate discussion of how different language features impact code quality I think we can start disagreeing here. The metrics shouldn't be solely code quality, but also simplicity, readability, and how fast you can express yourself in it. Code quality will go up the more language friction you add: types, "one way" of doing things, and function-oriented programming. Same code in a language with heavy types and strict functions will be of course "more solid". However, it will take 10x the time to write, be less flexible, and harder to understand.
- epgui 10mo ago
  > However, it will take 10x the time to write, be less flexible, and harder to understand. Not in my experience: only in the usual ramp-up period in the first few months.
solatic 10mo ago
You're looking for a copy of Eloquent Ruby: http://eloquentruby.com/ http://eloquentruby.com/

by epgui 10mo ago

SatvikBeri 10mo ago

Do you know of any articles/papers that try to do in-depth analyses of which features are helpful for building big systems? Most posts I can think of basically say "X language is good" or "Y language is bad", but I'd really be interested in arguments like "feature A is better at accomplishing goal Z than feature B"

Towaway69 10mo ago
That's a very good point. My experience is that for large project the architecture also becomes important. Large project have much code but if you can split out responsibility because your architecture allows this, then you keep your code concise. One feature Ruby has that helps here is creating Domain Specific Language without yacc or lex. This allows for concise code where its needed.
- epgui 10mo ago
  There are languages much better suited for DSLs though.
- SatvikBeri 10mo ago
  Not quite the same, but I find "data-oriented programming" to be a very strong method for managing large codebases. By that I mean having data structures that designate the end state that you want, having another set of code that gets you to those end states, and maintaining a pretty clear boundary between the two. (If you like with "Functional Core, Imperative Shell", this is a way to further divide the Functional Core.) It works well because it narrows the surface area of a lot of possible bugs: either your configuration is wrong, or your code doing the transformations is wrong.
  - Towaway69 10mo ago
    You kind of describe flow based programming (FBP) whereby data is passed to stateless functionality. Things like Unix pipes, Node-Red and n8n are inspired by FBP. I agree with what you describe, also reuse is simpler because code tends to be stateless.
epgui 10mo ago
There are some programming language journals that people like to dismiss as “academic”. But “academic” is what I value here.
- SatvikBeri 10mo ago
  There are a lot of programming language journals – are there ones you'd recommend specifically for discussions of tradeoffs between features?

jasonpeacock 10mo ago

> What I want is a dispassionate discussion of how different language features impact code quality This can be difficult because code quality, productivity, safety are hard to objectively define and measure, so we always fall back to differences in interpretation and experience.

SatvikBeri 10mo ago
I would be interested in serious attempts to argue for this, even if they can't reasonably be backed up by data. For example, I think there's a pretty strong argument that immutability makes it easier to write multithreaded code (perhaps at some performance cost), because it entirely prevents common types of bugs. Similarly there's a good argument that making methods open to extension (like Kotlin or Julia) makes it easier for an ecosystem to adopt unified APIs without explicit coordination. There's obviously a very strong argument that Garbage Collection prevents a lot of memory safety bugs, at costs to interoperability and performance.

hartator 10mo ago

> dispassionate discussion of how different language features impact code quality I think we can start disagreeing here. The metrics shouldn't be solely code quality, but also simplicity, readability, and how fast you can express yourself in it. Code quality will go up the more language friction you add: types, "one way" of doing things, and function-oriented programming. Same code in a language with heavy types and strict functions will be of course "more solid". However, it will take 10x the time to write, be less flexible, and harder to understand.

epgui 10mo ago
> However, it will take 10x the time to write, be less flexible, and harder to understand. Not in my experience: only in the usual ramp-up period in the first few months.

solatic 10mo ago

You're looking for a copy of Eloquent Ruby: http://eloquentruby.com/ http://eloquentruby.com/