3 ms·

That a language might overcome the "any hunk of code bigger than a screenfull is too complex to manage", other than by chopping the code into functions and clas

That a language might overcome the "any hunk of code bigger than a screenfull is too complex to manage", other than by chopping the code into functions and classes or whatever, is news to me. What are other methods for slaying this complexity? And what are the languages that use it?

pornel 4y ago
I think it's all of the languages people complain are "too complex": to be able to deal with more of program's complexity, you take on more language complexity. e.g.: • Encapsulation. Keeping implementation details private is pointless when you deal with a small program (the implementation is right there on your screen), but it becomes valuable when otherwise it'd be too hard to check which details you can change and which you can't. • Strong type systems. All the types are obvious when the program fits in your head, and seem like unnecessary boilerplate. However, when the program is large, it off-loads a bunch of sanity checks from your head to the compiler. Same goes for design patterns. Writing an `AbstractWidget` and `WidgetFactory` when you have two widgets to deal with is overcomplicating. But when you have 50 widgets, you need something to avoid drowning in copypaste and spaghetti if/elses.
- analog31 4y ago
  Ideally, the features needed for writing bigger codes should be optional. For instance, a beginner can write a Python script within a single screen that does something like graph some data. Encapsulation can be treated as an add-on, as can be the type system. That's assuming you want scalability. If a language is absolutely never going to be used for scripting by beginners, it doesn't need to be used that way.
  - zozbot234 4y ago
    > Ideally, the features needed for writing bigger codes should be optional. Newer languages like Rust, Swift and arguably Carbon don't make programming-in-the-large features "optional"; they make them as lean as possible, so that users can more easily apply them at the outset compared to older languages like Java/C#. That way even a screenful-length trivial script can potentially grow into a larger system without becoming unmaintainable in the process.

pornel 4y ago

I think it's all of the languages people complain are "too complex": to be able to deal with more of program's complexity, you take on more language complexity. e.g.: • Encapsulation. Keeping implementation details private is pointless when you deal with a small program (the implementation is right there on your screen), but it becomes valuable when otherwise it'd be too hard to check which details you can change and which you can't. • Strong type systems. All the types are obvious when the program fits in your head, and seem like unnecessary boilerplate. However, when the program is large, it off-loads a bunch of sanity checks from your head to the compiler. Same goes for design patterns. Writing an `AbstractWidget` and `WidgetFactory` when you have two widgets to deal with is overcomplicating. But when you have 50 widgets, you need something to avoid drowning in copypaste and spaghetti if/elses.

analog31 4y ago
Ideally, the features needed for writing bigger codes should be optional. For instance, a beginner can write a Python script within a single screen that does something like graph some data. Encapsulation can be treated as an add-on, as can be the type system. That's assuming you want scalability. If a language is absolutely never going to be used for scripting by beginners, it doesn't need to be used that way.
- zozbot234 4y ago
  > Ideally, the features needed for writing bigger codes should be optional. Newer languages like Rust, Swift and arguably Carbon don't make programming-in-the-large features "optional"; they make them as lean as possible, so that users can more easily apply them at the outset compared to older languages like Java/C#. That way even a screenful-length trivial script can potentially grow into a larger system without becoming unmaintainable in the process.