81–90 of 300 posts
Off serious topic: Naming it after you girlfriend is a risky move, like getting a tattoo of her. Better get married and stay that way or the next partner is gonna be like: "wtf", you still working on your tribute to your ex programming language!?
Her: "Why did you change the name?"
Him: "Because I'm hedging my bets in case our relationship does not outlast my pet programming project".
Her: "..."
Earlier quoted context omitted.
In Python: ["a", "b"].join(" ") This would mean the type list has a method join, how would it work with the following ? [1.5, "hello", None].join(" ")
>>> " ".join([1.5, "hello", None]) Traceback (most recent call last): File " ", line 1, in TypeError: sequence item 0: expected string, float found Why would `[1.5, "hello", None].join(" ")` be any different?
Why would you put a method on a class if only a small subset of it can use it?
When giving an example on how infix notation reads better: // This is obviously not too right ",".splitBy("1,2,3,4,5") // This should be right, because it reads out more naturally "1,2,3,4,5".splitBy(",") It's funny that in Python split works this way but join doesn't. This is because in the case of split both arguments are strings, but for join one of the arguments is a Sequence, which is a general protocol rather t…
I get this might just boil down to preference but I absolutely hate named parameters. They’re biased towards new users of a language and quickly become painful to write once you’re familiar with the function call. Plus they don’t always improve writability outside of IDEs because you then have to memorise the parameter names and in some functions there’s several terms that could equally apply (if you’re using an IDE…
You might have 3 related functions like so:
getStudent(datastore: DS, byId: number)
getStudent(datastore: DS, byAssessmentId: number)
getStudent(datastore: DS, firstName: string, lastName: string, birthdate: date)
Intellisense picks this up too and suggests the 3 different names. Works fantastic.
I find the syntax as the author intended it to be: clean. I agree with the ambiguity of positional parameters at first glance. Although named parameters (e.g. in Scala) somewhat solve this, they are optional. Having the parameters with their explicit name makes it quite readable. myList .append(5) .reverse .put(5) atIndex(0) .++(anotherList) .select(x | x.isEven) Edit: The same feature makes it look a little weird wh…
$.name("Keli" :age 50).isOld wold've been nicer to me but ah well.
Earlier quoted context omitted.
It is because in Javascript everything can be translated to a string: 1 + "hello" == "1hello" Therefore, the type Array can have a join method that have predictable results (unlike Python).
I don't know what that has to do with `join`'s call order. As mentioned above, it's because Python supports `join` on any sequence, not just the array class. Personally, I find JavaScript's solution neater: [..."hello"].join(" ") === "h e l l o"
Javascript always falls back to string, that is also why we have === and == operators.
Python's type system is a bit more strict because it will not attempt to serialize your objet if you haven't explicitly done it yourself.
My point is: Python doesn't use this notation because it would not make sense in Python.
Earlier quoted context omitted.
The only issue with F# is that it is a bit the black swan of Microsoft languages on .NET, so it doesn't get all the toys that C#, VB.NET and even C++/CLI get to play with.
I don't think F# needs toys, though. The language is so well put together you don't miss much IDE assist anyway, except to point to you where your code will have problems compiling.
No .NET Native, GUI designers, WCF/gRPC, EF designers, Blend, WinUI tooling, ASP.NET templates,... hinders adoption at corporate level.
I think it's great that Keli is designed with IDE support in mind. However I believe that this is only half of the reason why FP still doesn't really break through in the corporate world. The other reason is that many FP users are too enthusiastic about creating abstractions. This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report…
Earlier quoted context omitted.
How would function composition work without currying? You'd have to name everything, wouldn't you? I'm thinking of how you could write in point-free style or even have a `(.)` function to begin with if you had the Smalltalk "message passing" style. Sure the Haskell syntax is a bit much when you're not familiar with it but, like almost any language, it's often the least-interesting part of the language and the most ta…
That's the whole point of the syntax changes: to make the tradeoff that sacrifices terseness or efficiency or even composability in favor of readability. A lot of functional languages -- Haskell as I understand it is the biggest perpetrator -- optimize for code length and composability, trying to make things as expressive as possible, and decrying those who can't read something that has meaning densely packed into ev…
I'm curious if Keli plans to maintain function composition in the face of named arguments. It would be quite nice to have both.