3 ms·

I don't like C-like languages. Prefer pascal/python. In delimiters think is far better "begin or do /end" than "{}", but mainly because if you have keywords lik

by mamcx 10y ago

I don't like C-like languages. Prefer pascal/python. In delimiters think is far better "begin or do /end" than "{}", but mainly because if you have keywords like "if, while, for" then switch to symbol then switch again is "ugly". I think symbols are for data structures or math or operators, not keywords. key...WORDS. That is. However apart for that, and also dislike the use of space and implicit type. I use F# and like it, except for how ambiguous is for a lot of things. What is the point of have a super-strong type engine and when you look at: let getProductById repository id You still need to use intelli-sense or check the code as with dynamic languages? If I'm into a static typing, I wanna fully use it. When I see: getProductById repository id Type inference defeat me as a user: The computer know what that is, yet, is hidden from me. Not much different than in dynamic languages. Ah, you can annotate it if want! But then you break the language convention. Is bad to let the user decide, because then everyone will decide, but different. So, I think is better in a type-static language to annotate the types, all the time. Because that is how the language really is, and is the way to unlock the benefit of better documentation/clarity that is one of the benefits of static type. This is my main gripe with F#/OCalm. Also apply code require gymnastic because something is unclear in a secuence: let result = getId code save result bla bla When things start or end?. And F# have let fun = and let fun()= both things different. This create a compile time bomb where call some effect trigger before things are ready. In short: have a way to group and mark blocks is great. Python is closer to how do things with space/indentation. ----- Syntax is very important. I don't dismiss it like other people that think is just "sugar". Syntax is our user-interface. When is closer to what the language is, better.

dllthomas 10y ago
> So, I think is better in a type-static language to annotate the types, all the time. I agree. ((int)((int) 5) + ((int) 5)) - ((int)2) is way clearer than 5 + 5 - 2.
- mamcx 10y ago
  Is well understood that that apply to function/classes/types, etc.. not the non-sense example you pick. And by the way, a + b + c is not more clear than Int + Int + Int... or sum(customer, products) vs. sum(Customer, ProductArray)
  - dllthomas 10y ago
    My real point was that it's a spectrum. Type information should go where it clarifies and should not go where it obscures. We should omit the type from intermediate expressions when (and only when!) it will be sufficiently clear from context and it does not serve as a clearer specification of intent than your terms. I contend that this is not a special property of expressions.
    - mamcx 10y ago
      Then we agree ;)

by mamcx 10y ago

dllthomas 10y ago

> So, I think is better in a type-static language to annotate the types, all the time. I agree. ((int)((int) 5) + ((int) 5)) - ((int)2) is way clearer than 5 + 5 - 2.

mamcx 10y ago
Is well understood that that apply to function/classes/types, etc.. not the non-sense example you pick. And by the way, a + b + c is not more clear than Int + Int + Int... or sum(customer, products) vs. sum(Customer, ProductArray)
- dllthomas 10y ago
  My real point was that it's a spectrum. Type information should go where it clarifies and should not go where it obscures. We should omit the type from intermediate expressions when (and only when!) it will be sufficiently clear from context and it does not serve as a clearer specification of intent than your terms. I contend that this is not a special property of expressions.
  - mamcx 10y ago
    Then we agree ;)