language.go 7.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271
  1. /* Tools suck.
  2. I tried my best to choose the one that sucks less.
  3. */
  4. package setup
  5. /* I can not name a programming languages that does not suck.
  6. All Dynamic Typed Languages Sucks
  7. Except for tiny programs,
  8. static typing helps programmers to detect errors,
  9. and makes refactoring programs easy.
  10. Dynamic typed languages do not have this important mechanism.
  11. Dynamic typed languages also have other issues.
  12. To name a few:
  13. Lisp
  14. Dynamic scoping. Period.
  15. Some Later Dialacts of Lisp
  16. Macros make debugging hard.
  17. Lua
  18. Everything is a table does not work if used as a general programming language.
  19. Perl
  20. Perl encourages to write unreadable code.
  21. AWK
  22. Worse than Perl.
  23. Ruby
  24. A cleanup of Perl.
  25. Just like Perl, it may feel nature to their creators.
  26. But I often surprised by it.
  27. Also, the classes in standard library usually have too many methods.
  28. Some methods are just aliases.
  29. Some methods are just with slight difference.
  30. Saving a few key strokes do not make up the pollution of auto completion list.
  31. Python
  32. Indentation sensitive syntax is error prone.
  33. One careless tab will break the language.
  34. Although Ruby is messy,
  35. at least it admits sometimes there are different ways to do the same thing.
  36. Python advertises itself as "there is only one obvious way to do one thing".
  37. But there is Python 2 and Python 3.
  38. Okay, since the support of Python 2 will end soon
  39. (they always said so, but then they just extend the support period again and again),
  40. let me just consider Python 3.
  41. Even in Python 3 there are many ways to do one thing.
  42. Take string formatting for example,
  43. there are three ways,
  44. C style printf format string,
  45. template string `"print({variable}", variable=value)`,
  46. and the f-string `f"{expression}""`.
  47. Another example is path and pathlib.
  48. Julia
  49. Julia supports all the following operators for comparison:
  50. > < >= ≥ <= ≤ == === ≡ != ≠ !==
  51. ≢ ∈ ∉ ∋ ∌ ⊆ ⊈ ⊂ ⊄ ⊊ ∝ ∊ ∍ ∥ ∦
  52. ∷ ∺ ∻ ∽ ∾ ≁ ≃ ≄ ≅ ≆ ≇ ≈ ≉ ≊
  53. ≋ ≌ ≍ ≎ ≐ ≑ ≒ ≓ ≔ ≕ ≖ ≗ ≘ ≙
  54. ≚ ≛ ≜ ≝ ≞ ≟ ≣ ≦ ≧ ≨ ≩ ≪ ≫ ≬ ≭
  55. ≮ ≯ ≰ ≱ ≲ ≳ ≴ ≵ ≶ ≷ ≸ ≹ ≺ ≻ ≼ ≽
  56. ≾ ≿ ⊀ ⊁ ⊃ ⊅ ⊇ ⊉ ⊋ ⊏ ⊐ ⊑ ⊒ ⊜
  57. ⊩ ⊬ ⊮ ⊰ ⊱ ⊲ ⊳ ⊴ ⊵ ⊶ ⊷ ⋍ ⋐ ⋑ ⋕
  58. ⋖ ⋗ ⋘ ⋙ ⋚ ⋛ ⋜ ⋝ ⋞ ⋟ ⋠ ⋡ ⋢ ⋣ ⋤ ⋥
  59. ⋦ ⋧ ⋨ ⋩ ⋪ ⋫ ⋬ ⋭ ⋲ ⋳ ⋴ ⋵ ⋶ ⋷ ⋸ ⋹ ⋺ ⋻
  60. ⋼ ⋽ ⋾ ⋿ ⟈ ⟉ ⟒ ⦷ ⧀ ⧁ ⧡ ⧣ ⧤ ⧥
  61. ⩦ ⩧ ⩪ ⩫ ⩬ ⩭ ⩮ ⩯ ⩰ ⩱ ⩲ ⩳ ⩴ ⩵ ⩶
  62. ⩷ ⩸ ⩹ ⩺ ⩻ ⩼ ⩽ ⩾ ⩿ ⪀ ⪁ ⪂ ⪃ ⪄ ⪅ ⪆
  63. ⪇ ⪈ ⪉ ⪊ ⪋ ⪌ ⪍ ⪎ ⪏ ⪐ ⪑ ⪒ ⪓ ⪔ ⪕ ⪖
  64. ⪗ ⪘ ⪙ ⪚ ⪛ ⪜ ⪝ ⪞ ⪟ ⪠ ⪡ ⪢ ⪣ ⪤ ⪥
  65. ⪦ ⪧ ⪨ ⪩ ⪪ ⪫ ⪬ ⪭ ⪮ ⪯ ⪰ ⪱ ⪲ ⪳ ⪴ ⪵
  66. ⪶ ⪷ ⪸ ⪹ ⪺ ⪻ ⪼ ⪽ ⪾ ⪿ ⫀ ⫁ ⫂ ⫃ ⫄
  67. ⫅ ⫆ ⫇ ⫈ ⫉ ⫊ ⫋ ⫌ ⫍ ⫎ ⫏ ⫐ ⫑ ⫒ ⫓ ⫔
  68. ⫕ ⫖ ⫗ ⫘ ⫙ ⫷ ⫸ ⫹ ⫺ ⊢ ⊣
  69. To make things worse, some operators are same under certain conditions.
  70. For example, in for loops and array comprehensions,
  71. `=`, `in`, and `∈` is the same.
  72. To make things even worse, all theses operators can de extended by users!
  73. Like some dialects of Lisp, Julia also supports macros,
  74. though its debugging information is better.
  75. BTW, although as a language Julia sucks,
  76. it shines when it is used as an advanced calculator.
  77. PHP
  78. The list of its flaws is too long to be list here.
  79. JavaScript
  80. It lacks basic mechanisms like modules.
  81. Also, the semicolon auto insertion rules and type auto conversion rules are unnatural.
  82. Here I am talking about modern JavaScript,
  83. e.g. `const` and `let` instead of `var`,
  84. `=>` instead of `function`, and so on.
  85. Groovy
  86. Groovy pretends that it has fix Java's Null issue
  87. by returning null instead of throwing NullPointException.
  88. Passing null everywhere does not fix the problem and makes debugging harder.
  89. Groovy also does not fix Java's non first-class function issue.
  90. Well, at least in Groovy a method can be converted to first-class
  91. by prefixing it with `&`,
  92. instead of wrapping in an anonymous class which implements a function interface.
  93. And Groovy introduces new problems Java does not have.
  94. I will give two examples.
  95. One is an implementation issue.
  96. For example, in Groovy 1, private fields and methods are not private.
  97. And Groovy 2 still does not fix this.
  98. Will Groovy 3 fix this?
  99. The other is a design issue.
  100. Java's checked exception is evil.
  101. But just removing it is more evil.
  102. Static Typed Languages May Suck Less
  103. In above sections, I have listed issues of popular dynamic typed languages,
  104. other than the dynamic typing itself.
  105. Similarly, although static typed languages do not have the issue of dynamic typing,
  106. they may have other issues.
  107. Assembly Language
  108. No abstractions.
  109. Bound to a certain type of machines.
  110. Fortran
  111. To many confusing features to list.
  112. It lacks abstractions, encouraging unmaintainable code.
  113. C
  114. Accessing memory out of the bound is hard to detect in C,
  115. e.g. array index and pointer arithemetic.
  116. Managing memory by hand is tedious and distracting for a general programing language.
  117. C++
  118. It tries to fix C's problems,
  119. but in the end it brings in so much complexity,
  120. which causes more troubles than improvements.
  121. Java
  122. Functions are not first-class, NullPointerException,
  123. unnecessary differences between value type and reference type,
  124. and generic type erasure.
  125. To be fair, those issues, or similar ones also exist in C and C++.
  126. C#
  127. C# is similar to Java.
  128. It fixes Java's generic type erause.
  129. However, like Groovy, it just removes Java's checked exception.
  130. Haskell
  131. Just like many other static typed languages (C, C++, Java, C#, etc),
  132. in most Haskell programs function signature is explicitly written out.
  133. Thus HM type system's global type inference does not make any difference,
  134. except that it makes programs harder to write.
  135. To fix the limits of HM type system,
  136. Haskell introduces concepts from more advanced type system,
  137. which makes the language more complex, like C++.
  138. Also, the unnecessary pursuit for pureness and lazyness
  139. make code even harder to write.
  140. To be fair, Haskell is not bad as an experimental languages for type systems,
  141. just do not abuse it for practical projects.
  142. Go
  143. Similar to Java and C#, except that
  144. Go fix the non first-class function problem of Java and C#,
  145. and introduces new problems,
  146. e.g. abusing multiple return values to represent errors,
  147. zero values,
  148. and no generics.
  149. Kotlin
  150. Unlike Groovy, it fix Java's NullPointerException.
  151. Like Groovy, it just removes checked exception and use `::method`.
  152. Also, Java's generic type erasure remains.
  153. Kotlin borrows too many features from other languages,
  154. making the language complex.
  155. Swift
  156. Like Kotlin, Swift fix the nullability problem with optional typing.
  157. In Swift, functions need to declare if it `throws`,
  158. without specifying the types of exceptions it may throw.
  159. Thus the caller is forced to have a default cause,
  160. i.e. `catch (Exception)` in Java.
  161. If necessary, a function that may throw may be converted to an optional type.
  162. This is a crippled balance between the soundness and verbosity of checked exceptions.
  163. In Swift, only classes are reference types.
  164. All collection types (arrays, sets, and dictionaries) are value type.
  165. Thus despite the Swift documentation at apple.com stated that
  166. the mutability of collections depends on
  167. whether it is be assigned to a variable or const,
  168. in fact all collection types are immutable.
  169. Mutable collections returns a new collection under the hood.
  170. In other words, Swift redefine mutability:
  171. a mutable value is an immutable value assigned to a reassignable variable,
  172. and it has methods to mimic a mutable value.
  173. The implementation uses copy-on-write to reduce the cost of copying,
  174. which may cause unpredictable slow down of the program.
  175. To be fair, the two issues above may not cause serious problems in practical projects.
  176. But Swift makes breaking changes on every versions,
  177. which is a serious problems in practical projects.
  178. */
  179. func ProgrammingLanguagesSuck() {}