71–80 of 138 posts
I lost the line of reasoning (or perhaps the author did) at the second example. If I have 2 InputStream objects, nevermind equality. It just doesn't apply here. I don't even want `a.Equals(b)` to be considered valid code in the first place. Having __any__ default behaviour here is a lot like the permissiveness that is bashed in example 1 (a trifecta of unexpected variable scoping rules, the ability to re-type variabl…
Among reasonable programming languages (as defined in this article), which one compiles to the most optimized JavaScript that can efficiently interoperate with external JS code? Reason or OCaml via BuckleScript? F# via Fable? Scala? Maybe Kotlin is close enough?
https://github.com/rescript-lang/rescript-compiler/wiki/Why-...
https://www.javierchavarri.com/performance-of-records-in-buc...
Its Standard library Belt is optimized to compile to efficient JS too.
(edit: added line about Belt)
> Objects containing the same values should be equal by default. I strongly disagree with this. I’d take it one step further and say that there should be no equality operator or default equals function for non-primitive data types. Some specific type of records/tuples could use a default equality, but it should be opt-in or follow from using metadata like an attribute (e.g Rust derive) or only for those specific type…
So by 'general case' you mean 'every case'? Because to my mind, those instances you don't have the performance/power budget for 'it' are very much special cases, not general ones. It also seems a curious distinction; I mean, Python and Ruby both allow for mutable data, but are quite slow and memory intensive. Haskell doesn't allow mutability, but is quite fast, and also surprisingly memory efficient when written well. What languages do you consider to be able to address 'the general case'?
> Objects containing the same values should be equal by default. I strongly disagree with this. I’d take it one step further and say that there should be no equality operator or default equals function for non-primitive data types. Some specific type of records/tuples could use a default equality, but it should be opt-in or follow from using metadata like an attribute (e.g Rust derive) or only for those specific type…
Earlier quoted context omitted.
Its been a while, so I might be saying it wrong but, I was trying to create an entity collection. Essentially, a super basic scene graph. on every tick in my update call, i would update something about a specific entity in that collection (maybe position, transform etc). And then in my draw call I would render the entire updated collection. Just getting a specific entity from the list was a huge issue and then updati…
> Just getting a specific entity from the list was a huge issue and then updating it and putting it back was worse. I must be missing something, but this sounds like a pretty straightforward List.map
> I don’t care what my language will let me do, I care more about what my language won’t let me do. I think this is the best summary of the article. In short, please protect me from my own stupidity and/or laziness.
Alan Kay referred to this as the "Wirth school of non-programming". It obviously has some merit, but I'd rather have a language be an enabler rather than a disabler. And again, not having to worry about messing up is or at least can be a kind of enabler, but I prefer a more positive approach, with good defaults encouraging me to do the good and simple, but the language getting out of my way for things it might not kn…
Back when I first wanted to learn FP principles, I tried with Scala. It went nowhere. I had a problem, and I didn't know how address it in an FP manner. The language didn't help me by getting in my way when I went down a wrong path, so I never learned the 'right' one for FP.
As a trivial example - I want to iterate, I can use a loop; it doesn't prevent me from using a loop and instead directing me to recursion. In fact, with recursion I get all sorts of terrifying comments about making sure it can be tail call optimized, to use @tailrec to make sure of that, or else I might explode the stack, oh-God-what-is-this-why-would-I-ever-do-this-etc. Meanwhile there is that good ol' friend 'for' waiting for me to help me get things done...
Having used other languages, though, recursion holds no fears. I still am not a fan of Scala, but I'd be okay with being given all the options. Though not for any sort of team development unless everyone else had also been exposed separately to the paradigm we were standardizing on.
Earlier quoted context omitted.
Note that F# has the `[ ]` attribute for exactly that sort of case.
That's the wrong default though. There is no reason to assume equality is a sensible concept, so objects should not even be equatable by default, and you could have an attribute which gives them structural equality (with a third option of a full-blown custom equality if necessary) as e.g. Haskell or Rust handle it.
The article goes through a series of examples to show motivations for the following: 1. Variables should not be allowed to change their type. 2. Objects containing the same values should be equal by default. 3. Comparing objects of different types is a compile-time error. 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. 5. Once created, objects and collections must be immu…
Earlier quoted context omitted.
5. Once created, objects and collections must be immutable. So this language would not be general purpose, as it would not be suitable for high-performance computing. Large scale simulations almost always involve arrays that are modified in place. Being able to somehow declare a collection to be immutable would be highly useful, but not having the option of mutable collections limits the kinds of problems that can be…
I'm not going to claim that mutability is never useful for performance, but many large scale simulations can be expressed quite elegantly using bulk operations on arrays or other structures, with no mutability in sight. Both particle simulations a la n-body and stencil operations are in this category. An efficient low-level implementation of such bulk operations involves mutable updates, just like any functional lang…
> Objects containing the same values should be equal by default. I strongly disagree with this. I’d take it one step further and say that there should be no equality operator or default equals function for non-primitive data types. Some specific type of records/tuples could use a default equality, but it should be opt-in or follow from using metadata like an attribute (e.g Rust derive) or only for those specific type…
'You cannot program without mutation in the general case. You simply don’t always have the performance/power budget for it.' So by 'general case' you mean 'every case'? Because to my mind, those instances you don't have the performance/power budget for 'it' are very much special cases, not general ones. It also seems a curious distinction; I mean, Python and Ruby both allow for mutable data, but are quite slow and me…
I think e.g C# and F# handle mutation well, but I think F# does the right thing by not encouraging it like C#.
Being able to control the in-memory representation of data and do things like sort arrays in-place etc to some people seems to be rare and to others happens on day 1 even at toy scale. Depends on what problems you are solving I suppose.