Last active
December 21, 2015 15:09
-
-
Save built/6324614 to your computer and use it in GitHub Desktop.
A running list of features from Python and Ruby and others that I'd like to see in either one, or a hybrid. Suggestions welcome.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
From Python | |
------------------------------------------- | |
List comprehensions (and set/dictionary comprehensions too) | |
Decorators* | |
Implicit truthiness for values and containers (False: empty string, empty list, None, etc.) | |
Formatting w/o need to count braces or parens (much) | |
English keywords for logic operators (or, and, not, is) | |
Friendlier ternary syntax. (return x if x else y) | |
From Ruby | |
------------------------------------------- | |
Blocks | |
Optional parens on function calls | |
Pretzel shorthand (&:) | |
first/last on array | |
Symbols (ex: :foo) | |
Expression-based functions (no return) | |
Interrogative notation for methods (ex: #empty?) (These don't require boolean in Ruby, but would work better if they did.) | |
Base10-friendly formatting (1_000_000, etc.) (Is this Ruby core or something from Active Support?) | |
C# | |
------------------------------------------- | |
Super-clean lambda syntax x => x*x | |
Simple properties | |
Erlang (and Clojure, others) | |
------------------------------------------- | |
Pattern matching to unpack data like [H|T] = SomeList | |
Guards | |
Haskell | |
------------------------------------------- | |
type classes | |
Misc | |
------------------------------------------- | |
typedefs / type synonyms | |
Notes | |
------------------------------------------- | |
*For a language to work well there must be genuine synergy between the components. | |
I wouldn't bring in any feature unless it fulfilled a clear need. | |
For example, decorators are something that sprung up out of the constraints | |
of Python. It might make more sense to go with full-out macros or more granualar | |
pre/post filters. It really depends on how the other features fit together. | |
Misc Ideas | |
------------------------------------------- | |
[Default Return Values] | |
As a companion to guards, it might be nice to have default return values for functions. | |
A function/method signature might look like this: | |
def find_apples(criteria) or [] | |
Where the 'or []' indicates the default value if no return value is specified. In this | |
case we're riffing on a common idiom in scripting languages of setting a default value | |
if we didn't get one back. Might as well do that in the function itself. | |
JSON/YAML friendly data structure notation. For instance in Ruby the hashrockets get in the way of having a common hash notation. | |
Guiding principles (spitballing here) | |
------------------------------------------- | |
No nulls (billion-dollar mistake) | |
Tail-call optimization | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment