4 ms·

Glad to see this suggested. This is very similar to why OO programming was such a more humane system.

miguelrochefort 11y ago
A problem with most OO programming languages is that methods are declared as part of the class itself. This makes it difficult to extend an existing class you don't control, or reuse a method elsewhere. C# supports extension methods, which are basically static helper methods whose first parameter is the type to which you want to attach the method. For example, I could create a 'ToTitleCase' extension method on type 'string'. Then, given a string instance, I can simply do 'myString.ToTitleCase()'. One step further would be to add support for multiple parameters. For example, instead of listing all functions that accept an 'int' as an argument, you could ask for all functions that accept both an 'int' and a 'string' as an argument. Given 3 and "test", the 'repeat' function could be suggested, resulting in "testtesttest". To make things even better, one could provide (explicitly or not) the return type of the function they're looking for. For example, if you're assigning to a variable of type 'int', and all you have is a 'string', then you probably want to see a list of all functions that take a 'string' as an argument, and return an 'int'. In that case, you would see functions like "parseInt" or "getLength". It's kind of like playing domino, where you already know the type of the input and output, and only need to connect them together. Keep in mind that you can't always transform one type to the other in a single function call, which means the system would also need to recommend combinations of functions, such as "parseDateTime + getDayOfWeek" when you need to transform a 'string' to an 'int'. Perhaps the name of the arguments could even be used as some kind of sorting heuristics (a 'string' variable named "date" surely should be parsed to some kind of DateTime at some point).
- dllthomas 11y ago
  Over in Haskell-land, hoogle will perform fuzzy searches on type signatures. Having something like that at hand in the shell could certainly be neat.
lomnakkus 11y ago
This is an interesting point, but I raise you search and types. One of the points where "the Unix philosophy" (as usually espoused at least) is sorely lacking is that all programs interact with what is popularly called "text" (or a "single type"/"unitype"). For practical reasons it isn't always text, but more importantly (the first bit is a subset of this problem): almost every program has to understand (100%) the output of every other program it has to interact with. If output were typed our applications could ignore (reliably) the bits they don't care about. If output were typed we could search by output-type (e.g. diff produces patch-like-output, so don't bother piping to "xargs", but allow "less" (any type of input) or "git apply" (patch-like-input) or "patch" (patch-like-input). Types could add a huge amount of searchability to CLIs -- and for some reason this isn't appreciated even though we've seen it in a much more limited context such as OOP. (I think my original inspiration for this line of thinking is Paul Chiusano, and he probably deserves most of the credit, honestly.) EDIT: Actually, pondering this a little more: All programs should be forced somehow(!) to carry a "source location" for the source of their output. This is such an annoyance in the daily life of a programmer if you perform a chain of commands like "git diff ... | grep FIXME | grep ^+ | ..." just to get a grip on the FIXMEs you've introduced. The output doesn't show line numbers, because... well, for no really good reason, really. It's just that transformation as text meant that we sort of lost that bit.
- nitrogen 11y ago
  Two options for showing line numbers: (1) pipe the first command through nl; (2) use a single grep with the line numbering option (it's at least in GNU grep): grep -n '^+.*FIXME' You can also pipe git diff into less or "vim -" to use slash search. Note: on a phone so -n may not be correct.
  - lomnakkus 11y ago
    Thanks for the tip (and I think I might actually have it written down in a file somewhere), but this is missing the point. I shouldn't have to do this -- it should be automatic. Why? Because it's required for so many different tasks. For example: Source maps in the web world. EDIT: ... and it's actually possibly(!) even worse in the web world where you often have a ridiculous number of levels to your "transformation". Personally, I have never got "bower (source) -> grunt -> ts/(scala.js+closure) -> babel -> es5" (with source maps) to ever work even semi-reliably. (I know we have too many things in this pipeline, but it's what we have to deal with.)
SZJX 11y ago
Not sure what you're comparing OO to , but it certainly makes l little sense if you're comparing with FP. Grouping by function is so much more natural than artificially attaching the same function into different objects. When I copy, do I care whether I'm copying a document or a program? All I care about is the functionality, which is copying. This applies to many cases. OO design forcefully fractures every function into different objects, which makes extension a nightmare.

A problem with most OO programming languages is that methods are declared as part of the class itself. This makes it difficult to extend an existing class you don't control, or reuse a method elsewhere. C# supports extension methods, which are basically static helper methods whose first parameter is the type to which you want to attach the method. For example, I could create a 'ToTitleCase' extension method on type 'string'. Then, given a string instance, I can simply do 'myString.ToTitleCase()'. One step further would be to add support for multiple parameters. For example, instead of listing all functions that accept an 'int' as an argument, you could ask for all functions that accept both an 'int' and a 'string' as an argument. Given 3 and "test", the 'repeat' function could be suggested, resulting in "testtesttest". To make things even better, one could provide (explicitly or not) the return type of the function they're looking for. For example, if you're assigning to a variable of type 'int', and all you have is a 'string', then you probably want to see a list of all functions that take a 'string' as an argument, and return an 'int'. In that case, you would see functions like "parseInt" or "getLength". It's kind of like playing domino, where you already know the type of the input and output, and only need to connect them together. Keep in mind that you can't always transform one type to the other in a single function call, which means the system would also need to recommend combinations of functions, such as "parseDateTime + getDayOfWeek" when you need to transform a 'string' to an 'int'. Perhaps the name of the arguments could even be used as some kind of sorting heuristics (a 'string' variable named "date" surely should be parsed to some kind of DateTime at some point).

dllthomas 11y ago
Over in Haskell-land, hoogle will perform fuzzy searches on type signatures. Having something like that at hand in the shell could certainly be neat.

lomnakkus 11y ago

This is an interesting point, but I raise you search and types. One of the points where "the Unix philosophy" (as usually espoused at least) is sorely lacking is that all programs interact with what is popularly called "text" (or a "single type"/"unitype"). For practical reasons it isn't always text, but more importantly (the first bit is a subset of this problem): almost every program has to understand (100%) the output of every other program it has to interact with. If output were typed our applications could ignore (reliably) the bits they don't care about. If output were typed we could search by output-type (e.g. diff produces patch-like-output, so don't bother piping to "xargs", but allow "less" (any type of input) or "git apply" (patch-like-input) or "patch" (patch-like-input). Types could add a huge amount of searchability to CLIs -- and for some reason this isn't appreciated even though we've seen it in a much more limited context such as OOP. (I think my original inspiration for this line of thinking is Paul Chiusano, and he probably deserves most of the credit, honestly.) EDIT: Actually, pondering this a little more: All programs should be forced somehow(!) to carry a "source location" for the source of their output. This is such an annoyance in the daily life of a programmer if you perform a chain of commands like "git diff ... | grep FIXME | grep ^+ | ..." just to get a grip on the FIXMEs you've introduced. The output doesn't show line numbers, because... well, for no really good reason, really. It's just that transformation as text meant that we sort of lost that bit.

nitrogen 11y ago
Two options for showing line numbers: (1) pipe the first command through nl; (2) use a single grep with the line numbering option (it's at least in GNU grep): grep -n '^+.*FIXME' You can also pipe git diff into less or "vim -" to use slash search. Note: on a phone so -n may not be correct.
- lomnakkus 11y ago
  Thanks for the tip (and I think I might actually have it written down in a file somewhere), but this is missing the point. I shouldn't have to do this -- it should be automatic. Why? Because it's required for so many different tasks. For example: Source maps in the web world. EDIT: ... and it's actually possibly(!) even worse in the web world where you often have a ridiculous number of levels to your "transformation". Personally, I have never got "bower (source) -> grunt -> ts/(scala.js+closure) -> babel -> es5" (with source maps) to ever work even semi-reliably. (I know we have too many things in this pipeline, but it's what we have to deal with.)

SZJX 11y ago

Not sure what you're comparing OO to , but it certainly makes l little sense if you're comparing with FP. Grouping by function is so much more natural than artificially attaching the same function into different objects. When I copy, do I care whether I'm copying a document or a program? All I care about is the functionality, which is copying. This applies to many cases. OO design forcefully fractures every function into different objects, which makes extension a nightmare.