3 ms·
I think the most cited reason they give is diminished developer experience. That is when developers write a recursive function without intending it to be tail c
by runarberg 3y ago
I think the most cited reason they give is diminished developer experience. That is when developers write a recursive function without intending it to be tail call optimized, they loose their call stack. In theory this makes debugging harder. However I don’t—and others interested in JavaScript design—don’t buy this reasoning. There is little—if any—data showing this happens to developers in real life.
I also believe that Google’s representatives at TC-39 (and Mozilla’s to a lesser extent) knows this. Meaning they have other reasons for not implementing TCO. My personal theory is that they are very much against expending the functional paradigm in JavaScript. TC-39 has been very hostile towards any proposals which would expand the functional paradigm in JavaScript. The decision to advance the hack style pipeline operator (which uses a placeholder) over the F# (functional/tacit) operator is a prime example of this.
This, I believe, is purely political.
- odyssey7 3y agoSadly I sense something amuck against the functional paradigm as well. Paul Graham wrote back in 2001 that Lisp was a secret weapon for building a startup due to the developer productivity gains. https://paulgraham.com/avg.html https://paulgraham.com/avg.html As a corollary, the more lisp-like JavaScript is, the more it reduces barriers to entry for launching a tech company, promoting more software engineers into potential new competitors. Could it be that Java and Python are taught in universities because some members of the industry prefer making it more cumbersome for new grads to launch a company? Having significant barriers to entry is business strategy 101.
- sroussey 3y agoHaving worked on debuggers in JS land I can tell you that it would generate lots of bug reports. Does the developer expect a call stack? Does the developer NOT expect a call stack? Maybe they want to see if the optimization was activated. Bug reports either way. That said, all sorts of weird changes happen when a debugger is enabled. The jit will eliminate various pieces of code and remove variables from scopes, but you better put them back if the debugger stops! This one I remember in Firebug. Oops! ¯\_(ツ)_/¯
- hajile 3y agoSafari has enabled proper tail calls for 8-9 years now and they haven’t caused issues despite Safari having 20% of the worldwide browser market.
- runarberg 3y agoI guess Safari doesn’t have this large a share of developers, who are the main concern here. But I guess we will truly see if this is an issue as Bun increases in popularity.
- hajile 3y agoThe major Google "objection" was automated trace loggers. When something goes wrong, they grab the stack trace and ship it off to the developers. In this particular case, devs definitely see the Safari traces when bugs pop up.
- sroussey 3y agoI feel like it could be represented in the trace or the debugger or both and eliminate everyone issues. Devs definitely don’t like surprises, but also absolutely hate their tools not telling the truth.