5 ms·
Whenever someone has asked me "what would you change about Javascript" for the last 15 years, my answer has usually been "it badly needs a standard library." T
by wwweston 5y ago
Whenever someone has asked me "what would you change about Javascript" for the last 15 years, my answer has usually been "it badly needs a standard library."
The standards committees have partly advanced that and Deno is following those leads, but I've got my fingers crossed that Deno will also fill in gaps (and those will make their way back into standards committee considerations).
(My other answers have been more ... controversial, like: make [] false-y, add macros, and bring back `with`!)
- __ryan__ 5y agoA couple of questions: “Make [] false-y” Why? “Add macros” Why? How? “Bring back `with`” Why?
- SonOfLilit 5y agoNot GP, but I really like [] being false in ruby and python because I often want to ask "is this variable that should hold a collection holding a collection of things, or is it empty/false?"
- PufPufPuf 5y agoI always found it strange that in Python, stuff doesn't get implicitly cast to string (even Java does that!), but for whatever reason the idiomatic way to check if a collection is empty is to do "if collection:", implicitly casting to bool.
- heavyset_go 5y agoNothing gets casted to a bool in Python if statements.
- djur 5y ago[] is truthy in Ruby. Only false and nil are falsy.
- emmelaich 5y agoYeah, sadly zero is not falsy in Ruby.
- dschooh 5y ago[] is truthy in Ruby but there is #empty? on collection types. Rails also has #blank? which additionally works on false and nil.
- hyperhopper 5y agoLuckily, most languages have a `.empty()` method! You should use that instead for readability purposes.
- derekbaker783 5y agoAnd in that vein, JS has some().
- alerighi 5y agoWhy an array with zero element should be false? It doesn't make a lot of sense. And writing if (array.length > 0) is more explicit than writing if (array) anyway. Even in python, I prefer to be explicit and say if len(array) > 0 than to rely on implicit conversion rules.
- marcosdumay 5y agoPersonally, I don't like if even accepting things that are not boolean. But an empty array being false makes exactly as much sense as an empty string being false, and both should have always the same behavior. If you want objects to behave like dictionaries, an empty object should also behave the same, by the way.
- heavyset_go 5y agoI'd argue that `if empty_list` is already explicit in Python.
- 65 5y agoIt would be better if Javascript had Array.empty() instead of comparing array length. It would make things even more explicit and more convenient.
- dorianmariefr 5y agoYou are thinking about `[].present?` I think
- recursive 5y ago[] should be falsey so it can be used in an if(). I'm not sure about macros. I kind of want to see `with` back also. The problem with it was ambiguity. The syntax could be adjusted to avoid the ambiguity. .e.g `.prop = val;` could be legal inside the block. But "why though" you ask. A `with` block makes it visually obvious that a block of code is specifically relating to getters/setters on a particular object instance.
- adam_arthur 5y agoI'd argue truthiness implicated by the presence of an object is more logical than having an arbitrary definition of truthiness depending on the data type. If I have a cup that's empty, there's still a cup there. It's presumptuous to assume I care about the contents.
- recursive 5y agoIn that case "" should be truthy. And 0 should be truthy too probably.
- ckolkey 5y agoYes and yes. Ruby got it right, no question :)
- adam_arthur 5y agoThey should be, to have consistency in design. Note that if the language operated this way, checks on these types would be more explicit (though more verbose too). Checking for presence of a number with a truthy check is a common source of errors, if 0 is a valid number. I just don't agree at all that Python's interpretation of truthiness (or equality, for that matter) is inherently the "right" one. If I clone somebody are they equal because they have the same genetic makeup? No. Though a pretty contrived example that requires common understanding of equality. At least from a programming perspective, I usually care more about instance equality rather than structural equality. Of course Python supports that too via the `is` keyword
- 5y ago
- PufPufPuf 5y agoWhat about not making [] any kind of boolean? Let's be explicit and use [].empty() or something, implicit conversions are confusing.
- wwweston 5y ago> implicit conversions are confusing. Are they? All of them? 0:1 <≠> F:T? Boolean and binary are and should be distinct, and never the twain shall meet? A bold thesis in the world of computing. Context-sensitive meaning is something people navigate all the time. You probably do it in some software contexts w/o even realizing it (and we all do it with human language and relationships w/o thinking consciously about it). It's most likely to be confusing if you're unfamiliar with the context, or if the context-specific rules turn out to be convoluted. 0:1 maps on to F:T or even nothing:something or empty:non-empty pretty effortlessly. Even rigorously, with the right level of attention. Implicit can mean subtle. Whether that means confusing (or whether there's some other cognitive load imposed by some forms of subtlety) is a separate question. And probably subjective. Explicit can be a virtue. Concision can also be a virtue, and sometimes context-sensitivity promotes that.
- dgb23 5y agoMacros with a standard library would have saved us from many compatibility and bloat issues when they would have arrived before things like the class keyword.
- alerighi 5y agoMacros doesn't have that utility in a language with high-order functions.
- brundolf 5y agoGonna guess you're a lisper ;) Definitely it's biggest warts are around core data types - mainly the implicit-casting rules - but those are also impossible to change at this point. "Don't break the web" and all that.
- wwweston 5y agoMore like wannabe lisper. Maybe someday I'll land that Clojure job. And yeah, making [] false-y would probably do bad compatibility-breaking things. That's from the department of wishes more than good practical going-forward choices.
- noveltyaccount 5y agoA standard library, a proper date/time/timezone implementation, and robust number support (all sizes of integers and for the love of god Decimal). Every time I get excited about Deno and Typescript and all of that, I get so frustrated that 0.1 + 0.2 != 0.3 and that I need to find and vet a community Decimal library. (I know BigInt is a thing and Temporal is coming.)
- bern4444 5y agoI agree a standard library for JS would be great, but .1 + .2 != .3 is the case in several languages and is not anything to do with JS. This also is or can be the case in C, C++, Clojure, Python, and many other languages [1]. [1] https://0.30000000000000004.com https://0.30000000000000004.com
- noveltyaccount 5y agoYes... It's an artifact of floating points. My issue is that JS only has floating points and not Ints and Decimal.
- hajile 5y agoJS has had integers since pretty much day 1 with bitwise operators. They just (from a user perspective) convert back afterward. If you were choosing just one though, floats would definitely be a better choice than integers. It's also possible to make length 1 typed arrays of integers and operate on them if you really need. Then, as you mention there's BigInt numbers which are supported on the last few versions of every major browser except IE11.
- runarberg 5y agoThere is a stage 1 proposal for BigDecimal. https://github.com/tc39/proposal-decimal https://github.com/tc39/proposal-decimal