I love these kinds of discussions, but I'm also sure it will tire me out because the ideas are likely stated either too specifically or too succinctly.
> Everything should be able to be encapsulated
Not only should it be optional (default public), but it should be encapsulated with an escape syntax (similar to Python's underscore or Go's package level, backdoors). This is specifically good for testing. Note later, "no runtime reflection" either.
> No need to keep things in human memory for more than about 20 lines of code at a time. If extending that, then there should be an conceptual model
Not a language issue. This is what people think of when talking about a function. The problem is how functions have to physically be defined, which causes a lot of jumping around code to understand it. The expansion of function definitions inline, on demand, is a capability that only a LISP IDE has had, afaik.
> Content-addressable code: names of functions are simply a uniquely identifiable hash of their contents.
I've been a proponent of this since I started writing unit tests. There is no unit test to defend against "someone added a statement with a new side effect".
> Since discipline doesn't scale.
That's wrong, as a statement. Discipline is, generally, the only thing that scales and that's a Good Thing (tm). The examples given, were not directly related (a language adding more ways to do things) and are not compelling.
> Perhaps the language should even restrict a function's scope only to what's sent in through its parameters. So no one can reference hidden inputs^
This kind of wish seems like silly idealism wrapped in ignorance of what smart people will do when a language restricts them too much. Statics are good to have and should be preferred for most operations (once you break functions into small functions, it's obvious), which is not the same thing.
Shortly thereafter it goes off the rails completely with lots of strange views:
> No magic / hidden control. Make Inversion of Control (IoC) hard/impossible(?).
Also the cited reasoning for avoiding exceptions is not compelling, lumped in with specific Java functionality instead of a general reasoning about the pattern.
The constant wish for immutability really isn't the panacea presented. The ability to remove items during iteration in Python is fantastic and preferred to swapping data into different structures to perform operations.
Some wishes I would add (rather than a big diff of what I think are missteps)
- No "new" keyword to create objects/instances. Object() creation should be trivially mockable. Inspired by Python.
- Normalize "Helpers", which are a structure to hold static properties and methods. An IDE should be able to analyze a function and recommend it become a static function.
- Comments should be separate from code, joined at IDE or joined via manual tooling. This would allow comments to span multiple lines/function and files. IDE could also alert when breaking changes are made. Pairs well with the Content-addressable code wish.
^This is an invitation to attach output buffers and input buffers (normally for UI) to transfer around information to static methods. I have read through this kind of code before.
> The expansion of function definitions inline, on demand, is a capability that only a LISP IDE has had, afaik.
That is a great idea. Take the definition, splice it into the call site, rename local variables to match the caller. Interesting take on step into while running a debugger too.
> Everything should be able to be encapsulated
Not only should it be optional (default public), but it should be encapsulated with an escape syntax (similar to Python's underscore or Go's package level, backdoors). This is specifically good for testing. Note later, "no runtime reflection" either.
> No need to keep things in human memory for more than about 20 lines of code at a time. If extending that, then there should be an conceptual model
Not a language issue. This is what people think of when talking about a function. The problem is how functions have to physically be defined, which causes a lot of jumping around code to understand it. The expansion of function definitions inline, on demand, is a capability that only a LISP IDE has had, afaik.
> Content-addressable code: names of functions are simply a uniquely identifiable hash of their contents.
I've been a proponent of this since I started writing unit tests. There is no unit test to defend against "someone added a statement with a new side effect".
> Since discipline doesn't scale.
That's wrong, as a statement. Discipline is, generally, the only thing that scales and that's a Good Thing (tm). The examples given, were not directly related (a language adding more ways to do things) and are not compelling.
> Perhaps the language should even restrict a function's scope only to what's sent in through its parameters. So no one can reference hidden inputs^
This kind of wish seems like silly idealism wrapped in ignorance of what smart people will do when a language restricts them too much. Statics are good to have and should be preferred for most operations (once you break functions into small functions, it's obvious), which is not the same thing.
Shortly thereafter it goes off the rails completely with lots of strange views: > No magic / hidden control. Make Inversion of Control (IoC) hard/impossible(?).
Also the cited reasoning for avoiding exceptions is not compelling, lumped in with specific Java functionality instead of a general reasoning about the pattern.
The constant wish for immutability really isn't the panacea presented. The ability to remove items during iteration in Python is fantastic and preferred to swapping data into different structures to perform operations.
Some wishes I would add (rather than a big diff of what I think are missteps)
- No "new" keyword to create objects/instances. Object() creation should be trivially mockable. Inspired by Python.
- Normalize "Helpers", which are a structure to hold static properties and methods. An IDE should be able to analyze a function and recommend it become a static function.
- Comments should be separate from code, joined at IDE or joined via manual tooling. This would allow comments to span multiple lines/function and files. IDE could also alert when breaking changes are made. Pairs well with the Content-addressable code wish.
^This is an invitation to attach output buffers and input buffers (normally for UI) to transfer around information to static methods. I have read through this kind of code before.