New language standards catering to abandoned libraries
-
I was reading the article Where The Web Is Going In 2016[^] and it discusses how the
prototype.containsstandard method was renamed.includesin order to not break a bunch of sites using the old MooTools library. MooTools defines its owncontainsso changing this method's implementation would break 6.5% of the web. Evidently. To me this is a bad, bad case of painting yourself into a corner. If you're going to keep not defining new language constructs because a library de jour once used it then you're going to run out of names. Wouldn't it be more sensible to start by defining a pattern by which new language versions could be introduced into the web without breaking old sites? I dunno - something like what we actually already have:...
That way if you want to use new features you explicitly use them. If you don't name your poison then you get the default. It won't solve version issues, but it would allow a path forward and a reasonable path to deprecation.
cheers Chris Maunder
-
I was reading the article Where The Web Is Going In 2016[^] and it discusses how the
prototype.containsstandard method was renamed.includesin order to not break a bunch of sites using the old MooTools library. MooTools defines its owncontainsso changing this method's implementation would break 6.5% of the web. Evidently. To me this is a bad, bad case of painting yourself into a corner. If you're going to keep not defining new language constructs because a library de jour once used it then you're going to run out of names. Wouldn't it be more sensible to start by defining a pattern by which new language versions could be introduced into the web without breaking old sites? I dunno - something like what we actually already have:...
That way if you want to use new features you explicitly use them. If you don't name your poison then you get the default. It won't solve version issues, but it would allow a path forward and a reasonable path to deprecation.
cheers Chris Maunder
I agree. And in this particular case, I further argue that "includes" and "contains" and not synomyms -- sort of like the "search" versus "find" debate.
-
I was reading the article Where The Web Is Going In 2016[^] and it discusses how the
prototype.containsstandard method was renamed.includesin order to not break a bunch of sites using the old MooTools library. MooTools defines its owncontainsso changing this method's implementation would break 6.5% of the web. Evidently. To me this is a bad, bad case of painting yourself into a corner. If you're going to keep not defining new language constructs because a library de jour once used it then you're going to run out of names. Wouldn't it be more sensible to start by defining a pattern by which new language versions could be introduced into the web without breaking old sites? I dunno - something like what we actually already have:...
That way if you want to use new features you explicitly use them. If you don't name your poison then you get the default. It won't solve version issues, but it would allow a path forward and a reasonable path to deprecation.
cheers Chris Maunder
It was bad enough that non-standard extensions made their impact on naming process - now this?
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
I was reading the article Where The Web Is Going In 2016[^] and it discusses how the
prototype.containsstandard method was renamed.includesin order to not break a bunch of sites using the old MooTools library. MooTools defines its owncontainsso changing this method's implementation would break 6.5% of the web. Evidently. To me this is a bad, bad case of painting yourself into a corner. If you're going to keep not defining new language constructs because a library de jour once used it then you're going to run out of names. Wouldn't it be more sensible to start by defining a pattern by which new language versions could be introduced into the web without breaking old sites? I dunno - something like what we actually already have:...
That way if you want to use new features you explicitly use them. If you don't name your poison then you get the default. It won't solve version issues, but it would allow a path forward and a reasonable path to deprecation.
cheers Chris Maunder
I don't think the web will be better with badly molded javascript language. No versioning, js has to be redesigned from ground up. That's final!
-
I was reading the article Where The Web Is Going In 2016[^] and it discusses how the
prototype.containsstandard method was renamed.includesin order to not break a bunch of sites using the old MooTools library. MooTools defines its owncontainsso changing this method's implementation would break 6.5% of the web. Evidently. To me this is a bad, bad case of painting yourself into a corner. If you're going to keep not defining new language constructs because a library de jour once used it then you're going to run out of names. Wouldn't it be more sensible to start by defining a pattern by which new language versions could be introduced into the web without breaking old sites? I dunno - something like what we actually already have:...
That way if you want to use new features you explicitly use them. If you don't name your poison then you get the default. It won't solve version issues, but it would allow a path forward and a reasonable path to deprecation.
cheers Chris Maunder
Chris Maunder wrote:
MooTools defines its own
containsso changing this method's implementation would break 6.5% of the web.So, our implementations are now dictated by the errors of others? :) Anything built on top of JavaScript will still be JavaScript.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
I was reading the article Where The Web Is Going In 2016[^] and it discusses how the
prototype.containsstandard method was renamed.includesin order to not break a bunch of sites using the old MooTools library. MooTools defines its owncontainsso changing this method's implementation would break 6.5% of the web. Evidently. To me this is a bad, bad case of painting yourself into a corner. If you're going to keep not defining new language constructs because a library de jour once used it then you're going to run out of names. Wouldn't it be more sensible to start by defining a pattern by which new language versions could be introduced into the web without breaking old sites? I dunno - something like what we actually already have:...
That way if you want to use new features you explicitly use them. If you don't name your poison then you get the default. It won't solve version issues, but it would allow a path forward and a reasonable path to deprecation.
cheers Chris Maunder
Off-topic. Hey, we are still waiting for the IOT competition announcement. Thought it was going to be today?
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
-
Off-topic. Hey, we are still waiting for the IOT competition announcement. Thought it was going to be today?
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
Nish Nishant wrote:
Hey, we are still waiting for the IOT competition announcement
Give it about another half hour ;)
cheers Chris Maunder
-
Nish Nishant wrote:
Hey, we are still waiting for the IOT competition announcement
Give it about another half hour ;)
cheers Chris Maunder
-
I was reading the article Where The Web Is Going In 2016[^] and it discusses how the
prototype.containsstandard method was renamed.includesin order to not break a bunch of sites using the old MooTools library. MooTools defines its owncontainsso changing this method's implementation would break 6.5% of the web. Evidently. To me this is a bad, bad case of painting yourself into a corner. If you're going to keep not defining new language constructs because a library de jour once used it then you're going to run out of names. Wouldn't it be more sensible to start by defining a pattern by which new language versions could be introduced into the web without breaking old sites? I dunno - something like what we actually already have:...
That way if you want to use new features you explicitly use them. If you don't name your poison then you get the default. It won't solve version issues, but it would allow a path forward and a reasonable path to deprecation.
cheers Chris Maunder
Apologies for the meta-observation: The one that pisses me off is, every standard defines a method for extending the standard to cover new situations. Over time, people realize that the extension method doesn't cover all the cases, so they define a new standard, with a new extension method. The process then recurses into its own navel.
Software Zen:
delete this; -
I was reading the article Where The Web Is Going In 2016[^] and it discusses how the
prototype.containsstandard method was renamed.includesin order to not break a bunch of sites using the old MooTools library. MooTools defines its owncontainsso changing this method's implementation would break 6.5% of the web. Evidently. To me this is a bad, bad case of painting yourself into a corner. If you're going to keep not defining new language constructs because a library de jour once used it then you're going to run out of names. Wouldn't it be more sensible to start by defining a pattern by which new language versions could be introduced into the web without breaking old sites? I dunno - something like what we actually already have:...
That way if you want to use new features you explicitly use them. If you don't name your poison then you get the default. It won't solve version issues, but it would allow a path forward and a reasonable path to deprecation.
cheers Chris Maunder
Perhaps they should think of something that actually works, i.e. not HTML/CSS and JavaScript :~
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I was reading the article Where The Web Is Going In 2016[^] and it discusses how the
prototype.containsstandard method was renamed.includesin order to not break a bunch of sites using the old MooTools library. MooTools defines its owncontainsso changing this method's implementation would break 6.5% of the web. Evidently. To me this is a bad, bad case of painting yourself into a corner. If you're going to keep not defining new language constructs because a library de jour once used it then you're going to run out of names. Wouldn't it be more sensible to start by defining a pattern by which new language versions could be introduced into the web without breaking old sites? I dunno - something like what we actually already have:...
That way if you want to use new features you explicitly use them. If you don't name your poison then you get the default. It won't solve version issues, but it would allow a path forward and a reasonable path to deprecation.
cheers Chris Maunder
I absolutely concur, semantic versioning (ala Rust) for language versions. Breaking changes necessitate a new language version. Minor, non-breaking changes are minor versions. Bug fixes and the like are revisions. Bought to you by Code Project 1.0.1
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
I was reading the article Where The Web Is Going In 2016[^] and it discusses how the
prototype.containsstandard method was renamed.includesin order to not break a bunch of sites using the old MooTools library. MooTools defines its owncontainsso changing this method's implementation would break 6.5% of the web. Evidently. To me this is a bad, bad case of painting yourself into a corner. If you're going to keep not defining new language constructs because a library de jour once used it then you're going to run out of names. Wouldn't it be more sensible to start by defining a pattern by which new language versions could be introduced into the web without breaking old sites? I dunno - something like what we actually already have:...
That way if you want to use new features you explicitly use them. If you don't name your poison then you get the default. It won't solve version issues, but it would allow a path forward and a reasonable path to deprecation.
cheers Chris Maunder
Chris Maunder wrote:
changing this method's implementation would break 6.5% of the web.
I was bored enough yesterday to drill down to the analytics dashboard where that 6.5% number came from. 6.5% was from when the original objections were raised a few years back. It's down to about 2% now. Journalism at its finest. :rolleyes:
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
I was reading the article Where The Web Is Going In 2016[^] and it discusses how the
prototype.containsstandard method was renamed.includesin order to not break a bunch of sites using the old MooTools library. MooTools defines its owncontainsso changing this method's implementation would break 6.5% of the web. Evidently. To me this is a bad, bad case of painting yourself into a corner. If you're going to keep not defining new language constructs because a library de jour once used it then you're going to run out of names. Wouldn't it be more sensible to start by defining a pattern by which new language versions could be introduced into the web without breaking old sites? I dunno - something like what we actually already have:...
That way if you want to use new features you explicitly use them. If you don't name your poison then you get the default. It won't solve version issues, but it would allow a path forward and a reasonable path to deprecation.
cheers Chris Maunder
There's a great read about idealism vs. pragmatism: http://www.joelonsoftware.com/items/2008/03/17.html
