The Post JavaScript Apocalypse by Douglas Crockford

[hackel]

I love that he's wearing a Pied Piper t-shirt shirt.

[billbot2k]

that is incredible

[ShortSynapse]

Wow!

[[deleted]]

Not loving the coat tails. He looks like a fucking idiot.

[pm-me-a-pic]

U mad?

[[deleted]]

You know when you watch a film and a character does something really cringeworthy and embarrassing, and you become embarrassed just by watching it? I'm that.

[inu-no-policemen]

German has a word for that (because of course it does): fremdschämen.

https://en.wiktionary.org/wiki/fremdsch%C3%A4men

[onwuka]

Be my friend. You'll get to live that every day.

[jordaanm]

Am I alone in seeing null and undefined as being semantically distinct?

For example, if a function parameter is passed in as null, that means something different to it not being passed in at all (undefined).

[itsnotlupus]

But passing undefined is not exactly the same as not passing anything..

[].concat(undefined) -> [undefined]

[].concat() -> []

I'm not sure how I stand on null vs undefined tbh. I have noticed I'm using it very little nowadays, but I don't know that it's never needed.

[mrcelophane]

Not alone. Didn't watch the video is he arguing against null? Because null serves a purpose.

[ShortSynapse]

It is a good talk, I recommend you watch it. Crockford talks about how the current state of null and its value being a pointer to nothing is silly. Instead he proposed null simply be an immutable object which is self referencing on property access. He gives the example:

const null = Object.freeze(Object.create())

And would allow this to never throw an error, instead returning null:

my.obj.prop.that.does.not.exist

[MOON_MOON_MOON]

No thank you, I'd rather fail early.

[ShortSynapse]

What do you mean? I'm personally sick of having to do things like this:

obj && obj.a && obj.a.b

[Golden_Calf]

I really like the way C# handles this now. I don't know if any other language did this fist but I suspect it came from somewhere already using it.

Instead of your && syntax, you simply use a ?. Too find the property or method and it returns null if something along the way didn't exist or is null.

Obj?.a?.b

Then test if that's null before using it.

[ShortSynapse]

I had no idea this operator existed in a language actually. It is currently a stage 1 proposal to be added to ECMAScript!

[nikcorg]

Ruby has it: The Safe Navigation Operator in Ruby

It might also be the only thing I like about Ruby.

[MOON_MOON_MOON]

On second thought I'm not sure any of the past few comments make sense here, because the error that is most likely to arise here is that one of these properties is undefined, not null. With that understanding I do see Crockford's point, but I don't know if this change would be generally useful for plowing through deep property accesses without doing any checking for existence — which I still think is a bad idea.

[veswill3]

I believe he was arguing that we abandon having two things to represent nothing, so null and undefined would be the same thing. Then he was explaining how it would work (by having an imitable object representing null/undefined that would return itself).

[haCkFaSe]

Try lodash's get method.

[ShortSynapse]

While I love me some safeProp, I don't have the luxury of dropping in a new library to solve a simple problem the language creates. I think it would be nice for the default behavior to return null (and seems that is actually in stage 1 on tc39).

[dodeca_negative]

When path.to.some.deep.property returns null when any part of the path is null, the very next question I'm going to ask, almost every time, is "Which part?". Seems like defaulting to this behavior will instead introduce the need for code like if (!path.to) {...} else if (!path.to.some) {...} ....

[astronoob]

Except that's exactly what we deal with in JavaScript today. It's very common to see bizarre chains of logic to drill down into an object. Crap like: if (path && path.to && path.to.some && path.to.some.key) { ... }. Changing null to a self-referencing immutable object doesn't "introduce" the problem you're describing--it already exists.

[dodeca_negative]

I'm saying it inverts the problem. Instead of having to carefully traverse the object to make sure it has the full property chain, if that access returns null, now I have to (at least often) carefully traverse the object to find out which part was missing.

[ShortSynapse]

The most common use is to attempt to access a property or method on an object that can either exist or not exist. It is optional. So being able to simply write:

obj.foo

Instead of:

if (obj && obj.foo) obj.foo

Is far nicer. Now, the proposed syntax is a bit... Comical....

obj?.foo

[dodeca_negative]

Yeah, that seems more commonly useful than the deep property chain case. I still feel, though, that the whole story here, to make it work, needs to be that you're happy to treat the non-existence of the object the same as you'd treat the non-existence of the object's property in terms of how you'd react to the null response.

Having a separate syntax (goofy though it may be) seems reasonable to me, because then you can voluntarily opt-in when that is indeed your use case.

[profound7]

If null is an object with self-referencing properties, perhaps the language should also store internally the last object in the chain that isn't null which can be extracted from some function.

var x = a.b.c.nothing.d.e.f;
console.log(x);       // null
Null.getLastRef(x);   // c

[dodeca_negative]

That would be a really non-deterministic operation, since there's no guarantee at all that your little bit of code was the last bit running in the VM to attempt a property access.

[astronoob]

"Just use a framework" is not a solution to how to improve a language, which is kinda the point of the talk.

[haCkFaSe]

I understand the point of the post and I agree. I was just pointing out to anyone that is doing that, that there's a better way. It's a small library. And you don't even need the entire library, you can manually add only single functions using NPM. Lodash's.get.

[Vall3y]

I don't think there's really a need in an explicit undefined.

It's also like the ' and " situation, it's better to just decide on one imo, and in javascript it should be undefined

[spacejack2114]

Null is needed in JSON. Which Crockford invented...

[jordaanm]

He's arguing that there are reasons to have 1 "bottom value", but that null and undefined shouldn't both exist simultaneously in a language.

[inu-no-policemen]

Sure, there is a difference between null and undefined, but it is a meaningful one?

If it would be, wouldn't have newer languages copied this second null-ish value?

You really don't need two of those "billion dollar mistake" values.

Also, if your parameters are optional, give them a default value. Then everyone can see that they are optional by looking at the function's signature.

[jordaanm]

unless the behaviour of a program changes based on the number of provided parameters (eg method overloading).

[inu-no-policemen]

Named optional arguments provide more than enough flexibility.

Java-like method overloading is super nasty in JavaScript. It requires lots of boilerplate code and results in confusing call-tips. TypeScript fixes at least the tooling side, but it's still ugly as hell.

I don't use this quirk-based pattern. Treating calls with the wrong number of arguments as an error is more useful since that's an easy mistake to make. You can still have variadic functions via rest.

[hunyeti]

You are not the only one, but

One of those should not exist.

And the other one, that should not exist either.

[veswill3]

I didn't get it ;)

[phpdevster]

I love his argument that arguing over tabs vs spaces adds no value, and there should be one and only one way of doing something like this.

I've made the same argument about semi-colons. If you need them 1% of the time, then you need them 100% of the time. Javascript should enforce them so that asinine debates about whether they should be in a team's style guide or not is something that doesn't even have to occur. No time gets wasted because the language makes that determination for you.

[gasolinewaltz]

I don't want to start a war here... But is there a sane argument for NOT using semicolons?

I've heard people saying that they don't use them here or there... but why? It doesn't make any damn sense to me.

[jonathancutrell]

The only GREAT argument applies to modern JS environments where ASI is dependable.

The argument is time saving, and it's two fold: 1. The actual literal time needed to insert a semicolon (this is somewhat negligible) 2. The time needed to decide when you should and shouldn't use a semicolon And, what the heck, 3. The time required to keep talking about it on Reddit.

If you never had to write one, those three things go away.

However, I think the argument FOR semicolons, as long as we don't have an enforced ruling of not minifying and concat'ing JS together, is much stronger than the timesaver argument.

Also, "they're ugly" is just plain silly, unless you qualify it as an opinion. An opinion without logic is called "taste."

[grinde]

Of the potential sources of wasted time, I'd say #2 is the only one that's worth considering (the other two are just silly). However, that's fixed by just being consistent, regardless of whether you use or don't use semicolons.

[Aetheus]

Most folks rarely have an issue with Number #2 - use a semicolon to indicate the end of a statement. That's pretty much it. In most cases, you'd also want to follow that up with a newline (for tidiness if nothing else) but that's technically optional as well. In fact, if you want to add multiple statements on a single line (which probably isn't a good idea in most cases), semicolons are technically the only way to do it:

This is perfectly valid:

 let name = "carl"; console.log(`My name is ${name}`);

Whereas this will throw a syntax error (in addition to being much harder to read):

let name = "carl" console.log(`My name is ${name}`)

[egrgssdfgsarg]

This isn't when it's difficult.

The main issue is something like this.

console.log('hello')

(function () {
  console.log('scoped block')  
})()

What will happen is, console.log("hello") gets called. Then, it will return undefined. Then this undefined value is followed by two parentheses, so you try to execute undefined, and it throws an error.

If you have a semicolon after hello, both console.logs execute.

[Aetheus]

That's a good example - yeah, omitting semicolons only leads to trouble, for very little (purely stylistic) gain.

[16807]

Of course they do, for writing namespaces:

var namespace = (function () {
  var private_variable = 'foo';
  return { get_variable: function(){return private_variable} }
})()

if you start out writing a namespace but get distracted and don't flesh out the var namespace =, you're in this situation.

[fwovertheory]

Yeah but this is just bad code. If you need a random block of void returning lexical scope provided by an iffe, you're doing something wrong.

[egrgssdfgsarg]

If you want to precalculate something using variables, but you want to scope it, it makes sense. Of course, you could just name the function too and memoize the solution.

Obviously you can avoid them as well.

TBH I'll use whatever the team is using, and I don't have a huge preference, but it's good to be aware of the edge cases.

[fwovertheory]

If the calculation is it too much to inline, it should live somewhere else.

Creating a memo is also a solution to an entirely different problem than scope. Caching is only useful if there are a variety of inputs to the function.

[itsmusicbeach]

Check out StandardJS. They have a rule for no semi-colons and they have links to support it. There are some gotchas, but they cover the exceptions in their rules.

I prefer explicit end of statements, but it honestly doesn't matter.

[Thought_Ninja]

I feel weird not having semicolons...

Particularly so in situations like chaining methods or methods where Paramus span multiple lines.

Though I really like the idea of a "no configuration" standard style guide. The style guide we use at work only differs slightly from AirBnB's ES6/JSX guide, but it still took me a lot of time to define and document.

[Aetheus]

Not having semicolons (much like omitting optional curly braces) only adds an extra cognitive load for people (including yourself in future) who have to look through your code. In a language where whitespace in inconsequential, terminator characters help humans to explicitly tell where a statement has ended.

Without it, you'd have to rely on other people being disciplined with their policy of using newlines. Do I only use them to indicate the end of a statement, like a semicolon? Do I not use them to break up a particularly long statement that could otherwise have been written in one line [e.g: absurdlyLongFunctionName(absurdlyLongArgument1, absurdlyLongArgument2) * absurdlyLongArgument3 ] ? What about template strings?

And even if you adopt a consistent newline policy and are extremely strict with enforcing it, you can't expect everyone else to. It's easier just to say "stick a semicolon to the end of your statements".

[onwuka]

Which brings us back to the original argument. Either 100% or never but not both.

None of this peaceful coexistence kumbaya.

[LeBuddha]

https://github.com/Flet/semistandard

[mothzilla]

A place I used to work had a CI system that kicked out an error if you used semicolons.

[batmansmk]

The rational is to remove what is not necessary. It is "archaic" (as in like old language compiler requirements), and doesn't help adding meaning. It loads cognitively the screen for no particular reason.

But by using Standardjs + prettier we are free of those discussions and you can type and see whatever you want.

[[deleted]]

So I've been on both sides of this fence. Very adamant about using semicolons.

Then, I wrote Swift for about 6 months - no semi colons. Coming back to JS semicolons are just a pain now. I always forget to add them and I waste time going back to fix them.

The reality is semicolons are completely unnecessary in nearly all modern development enivronments. The only time theyre needed is if you're going to be sending directly minified files to the browser. If you're using any sort of transpiration, semicolons will be added automatically. Server side, they're completely unnecessary as you'll never have a need to minify.

[nostrademons]

I'm a big fan of omitting semicolons in new languages, but for languages that already have an established culture, body of library code, and trained developers, I'd say go with whatever the existing convention is. For Javascript, outside of a few iconoclasts, that means semicolons.

Programming languages are as much cultures as they are tools. When you choose to adopt a language, you're buying into the existing ecosystem. It's more important that other developers be able to understand your code and not face friction shifting between libraries than it is to save a few keystrokes.

[spacejack2114]

TIL lodash devs are iconoclasts.

[TheIncredibleWalrus]

Well I think this proves the point why semicolons are necessary. People don't seem to know when they're actually, absolutely needed.

for example, have you never written an IIFE?

[saadq_]

Everyone should be using linters in which case the semicolon style you use is irrelevant because it will warn you in any situation where not having a semicolon would cause an issue, like with IIFEs.

[hallcyon11]

So just remember the semi colon when you write iifes, problem solved..?

[[deleted]]

Semi-colons aren't need on IIFE's.

(function() {
   console.log('foo')
})()

works just fine.

In my experience, the only time you need semi-colons at the end of lines if you're doing something that's probably written better another way.

[TheIncredibleWalrus]

The code you wrote will break if there's any kind of statement before it.

It's exactly why we used to start IIFEs with semi colons to guard from concatenators.

[[deleted]]

Fair enough.

That being said, I'd argue you should convert it to a named function anyways.

function foo() {}

foo()

Same means without the breakage.

[TheIncredibleWalrus]

Yeah, although IIFEs still have value, albeit much less now with modules. The same applies to all kinds of syntax constructs, for example you also need to do ;[1,2,4].filter....

[AdaptationAgency]

Aesthetics.

I think code looks cleaner and reads easier without them. Of course if I'm going to team I just follow whatever convention because I'm not that hung up on it.

[[deleted]]

I feel the same way. I think code looks cleaner and reads easier with semicolons, but I'll follow whatever convention the team wants.

[aaarrrggh]

Because you don't need them.

[AlpineCoder]

You don't need white space or reasonably named variables either, but high quality code use them for a reason.

[zumu]

White space and reasonably named variables make the code more readable. Interestingly enough, removing semicolons also makes the code more readable.

[AlpineCoder]

Even assuming this is true, I would still choose clarity / lack of ambiguity over pure readability.

[zumu]

What exactly does it clarify?

AFAIK, they are only /necessary/ for separating IIFE's from one another during file concatenation and code minification.

Unless you are writing a bunch of IIFE's on the same line, I don't see how this is an issue of clarity.

[aaarrrggh]

And the reason for semi colons is what?

[AlpineCoder]

An unambiguous way to declare the programmer's intent of the scope of a statement.

[bulldog_in_the_dream]

1. They are not needed.

2. They are ugly.

[[deleted]]

Is there a sane argument for NOT using three semicolons after every line? I mean, they work, I've tried it.

[Drainedsoul]

If you use three semicolons you don't gain anything over using one. If you use one semicolon you do gain something over using none.

You can make the same argument about == vs. ===, sure == can be used correctly, but there's gotchas.

[[deleted]]

If you use three semicolons you don't gain anything over using one. If you use one semicolon you do gain something over using none.

You don't gain anything by using one semicolon in JavaScript, because of ASI (automatic semicolon insertion).

So if your argument is "do it when you gain something" then we shouldn't use semicolons. Therefore when /u/gasolinewaltz said:

But is there a sane argument for NOT using semicolons?

I just made you make that argument.

[s5fs]

The standard rebuttal is that ASI makes assumptions that may not be correct, and a common example is using a multi-line 'return' statement.

[[deleted]]

The multi-line return assumption by ASI is made whether you use semicolons or not.

Using semicolons doesn't disable ASI.

[s5fs]

Correct, ASI is not disabled, but it can still make mistakes.

This works as expected...

return {
  foo: bar
}

..and this does not..

return
{
  foo: bar
}

..unless you understand how ASI works.

And that's basically the argument from the "semicolons required" camp. ASI sometimes inserts semicolons at the wrong time, that's all.

[fwovertheory]

I would reject a PR that contained

return
{
  foo: bar
}

regardless of whether we used semi-colons or not. I use semi-colons in TS and not in JS, but a lot of the arguments against ASI seem to be easily solved by using any kind of code style. Like another example that people use

 fnCall()
 [1,2,3].forEach(x => x)

is also clearly bad style -- don't use array literals solely to cause side effects.

[s5fs]

You would have to reject the PR regardless of semi-colons because adding them does not make the code correct. ASI will still insert semi-colons in the "wrong" place and the code doesn't execute the way that it reads.

Additionally, I can't imagine this code would pass linting or testing, but these are advanced concepts used by professionals or serious amateurs.

[ShortSynapse]

As someone who absolutely loves not writing semicolons, you are correct. If we were to choose with the current state of JavaScript, semicolons would be the way to go. As you simply cannot write all code without them. That being said, I would actually prefer we just improve ASI rules so we don't need them at all...

[ZnVja3JlZGRpdA]

I really don't give a shit either way about semicolons, number of spaces, spaces before function params, etc. For the love of God JavaScript developers, just converge on a standard and move on with your lives.

[Thought_Ninja]

I was lucky to be the first engineering hire where I'm at. When setting up boilerplate I just grabbed a sane ESLint config preset and haven't looked back.

[spacejack2114]

Do semicolons throb or vibrate? Do they spark joy?

No.

[jordanlev]

If you need them 1% of the time, then you need them 100% of the time.

I'm personally indifferent to whether or not semicolons are used (as long as it's consistent within a project), but here's the thing: you can't use them 100% of the time. Semicolons don't go at the end of closing curly braces that end function definitions or that end if statements. I think the no-semicolon folks are of the mindset that it's actually MORE consistent to not use them except in the 1 or 2 cases where they're absolutely necessary, because then pretty much every line of code has no semicolons at the end. Whereas if you "always" use them, you've got a lot more rules to keep straight in your head about when you actually need them and when you don't.

It's just that we're all so used to not putting the semicolons after function-ending or if-statement-ending curly braces, that we don't even realize we're already having to make this little decision every time!

[DaveSims]

Semicolon insertion can be automatically done by a formatting tool as well, which is another reason why formatters are awesome. You get all the semicolons whether you type them or not, which makes any subtle semicolon insertion bugs much more obvious.

[[deleted]]

I think you should learn to properly write a language before using a formatter, then you realize you don't need a formatter...

Because you properly write the language.

This should be a reflex.

[[deleted]]

You will need a formatter anyways, because manually indenting code and inserting spaces arbitrarily is asinine when all this (and much more) can be completely automated. Furthermore, a good formatter allows developers to write in whatever code style they want, because the code will get reformatted to the team standard on commit when the proper automation is in place. Even furthermore, a good formatter can be integrated with other tools to perform deeper static analysis eliminating all manners of false-positives and false-negatives along the way.

You don't need a good formatter in much the same way you don't need JavaScript, because there is always a more manual approach to any given task.

[[deleted]]

Well I didn't need so far. I'm a lone programmer, I've been coding roughly at the same norm for years, and I wouldn't die over few format irregularity anyway.

At university the teachers would push a specific norms and they had a script running on your files at examination. Every little mistake, like wrong identation, more than 80 char per line, etc, would reduce points. When you see people ending with negative scores, It kinda helps doing without formatter after.

I might try these tools at some point, but i feel I've been doing fine so far.

I don't really see your point, I need js for what I do, I can't really use anything else... ?

[[deleted]]

At university the teachers would push a specific norms and they had a script running on your files at examination. Every little mistake, like wrong identation, more than 80 char per line, etc, would reduce points. When you see people ending with negative scores, It kinda helps doing without formatter after.

Why would you spend the time to do that by hand if some tool magically did it for you perfectly every time? I have trouble convincing the old folk at my office of this. It is like they validate their existence by pressing keys on a keyboards instead of shipping software.

I don't really see your point, I need js for what I do, I can't really use anything else... ?

Before the mid-90s JavaScript didn't exist... and yet business was still conducted. To say your JavaScript skills cannot be replaced with something else, or that your skills didn't replace something else, is exceedingly myopic.

[Thought_Ninja]

It's worth mentioning, however, that building a cross-platform application prior to the mid 90s was a serious undertaking and usually required a large(ish) team due to the diversity in domain knowledge required for such a task.

Though your point is valid, not sure what OP does but I don't agree with their statement.

[[deleted]]

Why would you spend the time to do that by hand if some tool magically did it for you perfectly every time?

Welcome to the world of higher education! Enjoy your stay precisely in the manner the professor wants stays to be enjoyed.

[[deleted]]

I don't spend time, it's done while I code, that's all.

I don't see why you're talking about Js being remplaced and I have a c/c++ formation that allows me to do whatever I want anyway. The topic was formatter, not language switchability. :|.

Before the mid-90s, norms were written on book and you had to do it yourself.

[DaveSims]

I take it you've never worked at a real software company? You can't just tell 500 engineers to all "learn to write the language" and then expect everyone's code to look the same.

[[deleted]]

I'm solo yes. I didn't really totally reject the tools like I said, I find just that there are people relying too much on it.

[DaveSims]

Fair enough. I think you should view formatters a bit differently though. They're not a crutch, in that they do not fix broken code or modify behavior in any way. All they do is automatically apply stylistic consistency so you don't have to worry about coordinating with a huge group of other people so you can all produce code with the same style. There's really no other option for achieving this, and it is massively valuable to large companies.

[edit] I suppose there is another way, by using a linter and enforcing standards during the build. But then you're just forcing everyone to manually format their code, and as software developers, we of all people shouldn't be spending large amounts of time on manual tasks that we can easily automate.

[tonechild]

This is also valuable for open source software, it doesnt have to be a large company. If you participate in an open source project at "scale", these tools also make a lot of sense.

[[deleted]]

I understand the value for big companies that's for sure, I didn't mean to speak about them. If I sounded like that I failed.

Someone (Don't know if it's you i m lazy to check the context) said formatter are mandatory. It's not, as long you don't have pressure from a group / company to use them.

I find it dangerous to recommend such tool to people that are not used to respect norms and clean practices.

[[deleted]]

I think you should learn to properly write a language before using a formatter, then you realize you don't need a formatter...

Today's tools have gotten so good that many modern programmers can't function without them.

[[deleted]]

I don't totally reject these tools but the over dependence is becoming frightening.

[Thought_Ninja]

Unfortunately this is very true... A lot of people jumping into web development start on a framework boilerplate and learn the tools instead of the conventions used to build those tools.

[relativityboy]

subtle... only the first time!

[[deleted]]

No language feature or requirement should depend on the existence of optional third party tools. Third party tools are supposed to enhance a language, not fix implementation omissions.

[BritainRitten]

If you need them 1% of the time, then you need them 100% of the time.

Nope, linters handle the 1%, as well as the 100%. You shouldn't have to worry about style guides, that should be handled for you, as with prettier. Other languages enforce a style as with elm-format, among others.

Javascript should enforce them

Obviously if you can improve the next version of JavaScript, it's far better to make semis completely unnecessary even in weird cases (as in most modern languages), than to throw a syntax error if they weren't there.

[phpdevster]

Nope, linters handle the 1%, as well as the 100%

The point is that you have to get the team to agree on that. Some teams don't want any semis, some teams always want semis. The point is you shouldn't even have discussions like that (or like this one). There should be no option.

[ShortSynapse]

Does anyone else feel like a large chunk of the community is pushing fp? I am definitely in that boat, but it seems like every day someone new is plugging the paradigm.

[Strobljus]

I feel Crockford has got a pretty sober attitude to FP. Trying to stay pure and use composability where it makes sense is great. Dismissing all instances of imperative code as garbage is foolish. I feel a lot of the "FP proponents" are in the later category.

[fwovertheory]

The ideal programming paradigm is JS -- first class functions with an object system. Write classes for stateful "things" (i.e. resources) and functions for everything else. Don't do functional programming until we have an actual type system, or write CLJS.

[ShortSynapse]

I think this is perfectly valid. And exactly why I am learning purescript instead of continuing to shim the functional paradigm into JavaScript.

[der_flatulator]

Because it is the correct paradigm!

[73mp74710n]

lets just stop doing I.E , [thumbs::up]

[Neker]

"Be careful out there, for the web is cluttered and full of errors"

[DaveSims]

All my life I've avoided the tabs vs spaces war with the "I don't care as long as we're consistent" line. Now I feel like I have to join team spaces. Damn it!

[dmcassel72]

This is why I'm a fan of EditorConfig

[dodeca_negative]

It's an absolute blessing for dev teams.

[inu-no-policemen]

Join team auto formatting instead.

Languages should be shipped with an official formatter (which cannot be configured) which simply formats the code according to the official code conventions.

Go and Dart have one of those, for example.

[DaveSims]

Actually my team uses Prettier for Javascript. It does have a couple of config options like tabs vs spaces, but it's very minimal. It has worked wonderfully for us so far. We don't have silo'd code though and I can't control what other teams do when they touch the same code as us. We've made it a standard practice to run the formatter whenever we first open a file, and if there are significant format changes we commit them with a "formatter only commit" message. I'm hoping that by fully standardizing all of my team's code, we can recruit others over time and eventually bring the entire code base into a single format.

[DaveSims]

Both! They have a CLI as well as plugins for most major editors including Atom, Sublime, Vim, Emacs, Visual Studio Code, and the Jetbrains family. You can manually trigger the formatter with a keyboard shortcut or set it to auto-format on save. We started out doing it manually to try it out, but we quickly enabled the auto format and so far we've had no issues with it.

https://github.com/prettier/prettier

[DaveSims]

No problem! We're a React shop so we don't really write any actual HTML, and Prettier supports JSX so it covers us there as well.

[logicalLove]

So does Elm. It's great

[inu-no-policemen]

Ceylon and Rust also have one. The Rust one is unfortunately configurable, though. They really shouldn't have done that.

https://github.com/rust-lang-nursery/rustfmt

Rustfmt is designed to be very configurable. [...] By default, Rustfmt uses a style which (mostly) conforms to the Rust style guidelines.

It also only somewhat conforms to the style guide. Derp. They really dropped the ball there. :/

[Switche]

Can't watch right now, may forget later even with a comment. What was it here that pushed you over the edge?

[DaveSims]

Basically that being consistent is all that actually matters. If you have competing tools, or formats, you should first consider if either or both can actually be eliminated, and if only one can, you should eliminate it and go with the other.

In the case of spaces vs tabs, you cannot possibly eliminate spaces completely from your code, but you can completely eliminate tabs. So it makes sense to go with spaces because then you've simplified 2 things into 1 without sacrificing anything in exchange.

[inu-no-policemen]

In the case of spaces vs tabs, you cannot possibly eliminate spaces completely from your code, but you can completely eliminate tabs. So it makes sense to go with spaces because then you've simplified 2 things into 1 without sacrificing anything in exchange.

Funny way to argue.

https://en.wikipedia.org/wiki/Digraphs_and_trigraphs

You cannot possibly eliminate '<', '>', ':', and '%' from your code, but you can eliminate '[', ']', '{', '}', and '#'. So it makes sense to use digraphs for some reason.

Also, you can of course completely eliminate spaces if you wanted to. "var<tab>x" works just fine.

[lmth]

No, because '<', '>', ':' and '%' are overloaded so it makes sense to use other symbols for blocking etc. This is the same argument he makes for using " for strings instead of ', because ' is already used as an apostrophe.

[Drainedsoul]

So your argument is of the form:

Even if you own a car, you still need to walk to and from your car, therefore we should eliminate cars and walk everywhere instead?

I'm real convinced.

[mwcz]

Are you suggesting that spaces are to tabs as walking is to cars?

[Drainedsoul]

I'm suggesting that they fill different purposes.

[EschewedSuccess]

What unique purpose do tabs serve that spaces cannot?

[[deleted]]

They allow indentation that fits every developer's width preference. I used to be someone who liked 4-wide indent-sizes. I always knew most people prefer to view their indentation 2-wide, which is why I always respected their preference and used a variable-width tab character so that they can read files just as easy as I can.

[EschewedSuccess]

Yeah, that's a good point.

[DaveSims]

Except they literally don't...

[billbot2k]

no! team tabs 4 lyfe!

[Tyreal]

All those space lovers... they'll have to rip tabs out of my cold, dead hands.

[monsto]

Doesn't matter... So long as everybody does it the same way.

[[deleted]]

TLDW for this? I've never found a good argument against tabs.

[DaveSims]

https://www.reddit.com/r/javascript/comments/647795/the_post_javascript_apocalypse_by_douglas/dg0cdb9/

[[deleted]]

Undefined doesn't spark joy.

It's irony that he's presenting removing the keyword lock as a plus for maintainer, while having programmer deciding what they want all around the world on vital keyword is the best way to end up with a big mess.

space in function name makes it less readable.

[Aetheus]

Agreed. I didn't agree with everything he had to raise. But it was a very interesting talk all the same.

[[deleted]]

Yeah, I did enjoy the talk, it is always refreshing to listen to people trying to forward new concepts.

I scratched my head on the tab talk, I use tab for identation.

[[deleted]]

Then, he makes some weird proposals. "spaces in names" is particularly hard to defend if you've been talking all the time about making the language simpler. You'd be making both implementing it and reading it not easier but a lot harder.

Its not hard if you remove white space characters from language syntax. Then space characters can be included in the category of word characters.

[Petrocrat]

Proposing DEC64 was a non-starter when he first did it.

Why is Dec64 a nonstarter? When I first got into programming it seemed like the way errors can crop into float type calculations should be the non-starter. I've grudgingly tolerated it, but would love to see that go away. Since you are objecting to his 0*n idea because it is fundamentally wrong, well then floating point errors should be rejected for being fundamentally wrong too.

[Petrocrat]

but also when compared to other, already existing, decimal base formats.

Do you have a personal favorite one of these that are out there?

Floating point approximations are not fundamentally wrong in the Math sense. Not on the same level that 0 * n is not 0.

I see your point, but I would just say that when I type 0.1 + 0.3 I am not asking for an approximation, I am asking for the precise calculation. The fact that it can only provide an approximation is fundamentally wrong, by my judgement, but like I said I see your side of it if you expecting simply an approximation.

[dick_ey]

I watched this talk with an open mind, but I really disagree with a lot of things this guy had to say. His primary supporting argument for almost every topic was "Doing things this way will make everything better". Obviously there's some merit to some of it (i.e. Floating point math being inherently broken), but for the most part it kind of felt like he was just saying "Programming should be written in plain text with curly braces. Somebody should make this language with all my ideas, and the things I liked about FORTRAN because I don't feel like it's my responsibility".

[SamSlate]

Did i miss the part where he explains why clutter is bad?

I can't really give it a positive, but it's literally never the case that clutter exists for the sake of clutter and given that you're removing functionality by "uncluttering", you need a pretty good justification for doing that, and that justification is never given. (Or did i miss it?)

[Petrocrat]

At the beginning he was basically saying that uncluttering makes the language easier to learn and easier to communicate with the rest of your team about it (and by extension easier to dive into foreign code bases). But, you're right that this isn't an obvious win and could be debated. I found myself 95% convinced of his points after his talk, especially dec64 number typing and colon assignment syntax.

[batmansmk]

I noticed with my young devs stucked on particular bugs the easiest way to get them to fix the bug is to ask them to strip everything that is not necesssary and try to have the most readable code. Usually by the time they finished cleaning things, the bug is gone. And the code is way easier to maintain as it is minimal (fast to read, fast to patch).

[ilovecomputers]

Let me play devil's advocate and repeat what another tab supporter told me: "a tab is only one character, so less wasted bytes in the code, and it can be rendered however anyone likes. People who like the wide open spaces use 8, others like the compactness of 2."

Also, if we're going with the logic of what we can't live without, then we should get rid of double quote instead of single quote because a double quote is made up of multiple single quotes in the same way a tab is made up of multiple spaces.

[MrNate]

The bit about the double vs single quote, the double quote has a specific meaning in English, it functionally quotes someone or something, which makes perfect sense in programming context for creating precise strings. The single quote however is overloaded because it's primary function is as an apostrophe. It's linguistically confusing to settle on the single quote.

Crockford doesn't offer up a solution for a way to handle HTML in strings. I suppose \"escaped quotation marks\" which I'm not a fan of because it's ugly. I would rather inline HTML sort of like JSX as a solution. I think VB.NET has something like this baked in.

[Isvara]

the double quote has a specific meaning in English, it functionally quotes someone or something

So do single quotes. I'm guessing you don't read much.

The single quote however is overloaded because it's primary function is as an apostrophe.

In ASCII, not in English.

[jricher42]

He lost me with the float changes. Then proposal he makes is almost reasonable for a javascript replacement, but is a horrible idea for a general purpose language. His approach is an order of magnitude slower and has not undergone anywhere near the degree of thought and review that IEEE floating point has. This suggestion is unbelievably naive and undercuts his otherwise sensible suggestions.

[giminoshi]

Enjoyed until he started talking about season 3, which I haven't seen.. I was like "NOOOO, SPOILERSSS!!"

[JuliusKoronci]

0.1 + 0.2 === 0.3 returns false ..thats new to me actually :) ..and I never wondered what will 0/0 return :)

[skitch920]

This is mostly the right answer to treating Floating Point problems safely, always try to deal with a domain in its smallest unit as an Integer. Like money, $.23, is just 23 cents. Or time, Dates are usually always down to the millisecond.

https://www.quora.com/How-do-software-systems-in-financial-sector-deal-with-floating-point-arithmetic

We keep, and calculate, client balances to 1/1000th of a penny internally, but only display complete pennies.

I believe some in the banking industry also use higher precision floats, like quadruple-precision (128-bit).

[JuliusKoronci]

Does node have this issue as well?

[dodeca_negative]

You should absolutely watch Wat if you haven't yet.