-
-
Notifications
You must be signed in to change notification settings - Fork 4
Bad
The following ideas for the Angle language need some serious reconsideration:
But before condemning some progressive ideas as bad, ask questions about how to resolve ambiguity etc
Cleverness in code starts working against you as a code base and organizations scale
Overuse of significant whitespace
ambiguity in braceless function calls:
fibonacci number = if number<2 : 0 else fibonacci number-1 + fibonacci number-2
Could easily be a read as (fibonacci number)-1, resulting in infinite recursion :(
While Using Emojis in Mathematical Notation can be cute, it is certainly a bad idea to promote: Unicode is full of invisible character, potential diacritics, similar-looking glyps, control character that can break the display in a lot of annoying ways. Here is one way to fix it: Automatically all Unicode operators to their textual representation.
Are there situations in which broadcasting is detrimental? If so could it be mitigated by overloading the function?
Writing bad or ugly code should be discouraged systematically:
- by making dangerous and ambiguous constructs ugly.
- by giving compiler warnings
- by giving compiler hints of how to transform bad code into good code
Most Everything in computing is a trade-off. Identify yours!
Not everything in computing is a trade-off. Identify your false trade-offs, and break through established falsehoods
The operator =
and its equivalent keyboard is
can act as
five=5
fib int i = if i<2 : 1 else fib(i - 1) + fib i - 2
if fib 3 = 5 : print "of cause"
Since one may quickly run into ambiguities and there is a high chance that all versions of the compiler do not catch it it's a strongly encourage to use other keywords for the function declaration and equality comparison:
fib := if it<2 : 1 else fib(it - 1) + fib it - 2
if fib 3 == 5 : print "of cause"
In fact it may be a bad idea to ever allow “natural” usage of =
This implementation may turn out to be so difficult that it is currently postponed.
As always: Don't fall into the trap of "make random changes until it looks like it works" and call it done.