This is inherently the opposite of what you are saying. The goal of the language services is to provide the same functionality to all ides vs every ide implementing their own solution per language. This also allows for the language owner to be in charge of the quality of the services in the ide.
I do the same. We have a private repo that proxies (and stores) all copies of everything we use so that we won't lose access to them. It's kind of a bear, but on the Maven side, it acts as a network proxy for our entire dev team, though the overall benefits aren't that high.
As a server side language, I'm extremely torn. I've actually been using Typescript pretty heavily lately (and decorators), and it makes the code I write not too far off from the Spring/Java code I would generally write. My biggest concern with NodeJS is the maturity of the ecosystem, and how it plays with enterprise software development. One of my goto examples is LDAP support. There were a handful of libraries (circa 2014) that sort of worked, but had gaps, and ultimately required doing some odd trickery to work. The analog to Java would have been one or two libraries that are mature and just work.
I personally find NodeJS is generally a fine experience, but the ecosystem (which is what the story is about) is just lacking structure that other languages have. It will mature, but may be a lot of pain along the way. The other day I had to choose between Python and NodeJS for a utility I was writing, and I went with Python because batteries were included, and I was afraid of trying to figure out how to include dependencies on the remote host in a consistent and manner.
From a runtime environment, I agree there are lots of "quirks", and the DOM is one of the worst cross-platform interfaces of all time. Less of a contract and more of wishes and hopes. ES2015 really does focus on syntax (e.g. "use strict" is default when using modules and not required). "this" has always been a gotcha, but that is part of a language where the function is the unit context. I actually like that about Javascript (though I realize not everyone does). For that reason "let" was also introduced to provide more normal behavior for scoping per what others expect coming from other languages.
I don't think it will ever be a "Java" or "C#" but it isn't necessarily a bad thing as lot of people seem to be happy with it's design and how it works.
Javascript has some terribly bad parts (as does perl and php) and I would concur that languages like Python/Ruby seemed to be planned in entirety a bit more. I would recommend looking at ES2015+, the next revision of the Javascript. It does a lot to curb those issues (JS actually has a "strict" mode that handles some of the gotchas), and ES2015 adds proper module support, as well as a standard class syntax.
These features have been in use for years by transpilers (to cover the gap between agreement on a new language feature and the time before it is adopted by the runtimes). Typescript is an even more powerful extension of ES2015 that adds compile-time type analysis/verification but generates nearly perfect idiomatic ES2015 code.
I'm not sure how JavaScript would be that different than any other scripting language (Perl/Ruby/Python/PHP/Groovy), and those seem to have viable web ecosystems Not 100% sure where the hate for JS is coming from. Unless it's a disdain for scripting languages in general. That would generally leave you with C#/Java and Java, historically, has been the only cross platform solution, and the language has stagnated heavily over the last decade (though 1.8 and 1.9 are showing signs of life).
Maven has the same problem in the SNAPSHOT dependencies, as they are free to be updated in the standard cycles. You also have to consider that the Maven plugins run in the same space as the user (and are pulled from the same dependency repositories). This makes maven just as susceptible with one major caveat. There are multiple federated repositories and publishing to one of those repositories requires reputation, and hosting your own repository (without reputation) is like downloading untrusted APKs on Android.
Almost identically history, AppleBASIC in elementary, onto GW then QBasic in middle school. On to Visual Basic for a few apps in early high school and then into C++ with AP Computer Science. The only difference was that I was the last year of C++ before the transition to Java.
Pretty certain the tools for actionscript3 and actionscript3 itself (the language the flash runtime uses) is far more sophisticated and robust than javascript. AS3 is more comparable to Java and.NET, and would be a wonderful toolset for building web applications. It was everything Java attempted to be (in the browser).
Exactly. T-Mobile is already in a position that is friendly to unsubsidized phones. There is a reason Google and T-Mobile have worked together often. I know that Deutsche Telekom was looking to sell off T-Mobile as well. I guarantee that a T-Mobile infused Google would be near unstoppable.
This is assuming they aren't doing their redirect with DNS records that are hosted outside of their infrastructure. Assuming they don't run their own DNS, wikipedia should be able to do this with almost no bandwidth costs.
Isn't that the point of using Google's copy of jQuery for your sight, in lieu of hosting it yourself. You can share the cache with any other site that is pulling the jQuery lib from a trusted 3rd party. After looking at the link you posted, that code may be simpler with respect to size, but in terms of maintenance or having a novice manage it (without introducing cross platform issues), it seems like it may be a nightmare.
What would be nice, and Adobe has done this for flash, is to have a separate cache for trusted libraries. It would be nice if I could query to see if jQuery were available in a browser lib cache, and use it from there if available.
The flash runtime has experienced the same problems as it was a developing platform. Flash 8,9 and 10 are all still in use today and have different feature sets and programming models. I realize the analog is slightly different as android is an OS and not a runtime, but the fact remains that progress requires this. We as geeks bemoan long development cycles and slow progress. Well the way to get around slow progress is quick iterations, and that gets to you to fragmentation. Adobe has realized this and their rate of development has slowed as they have stabilized on where they want the platform to go. Give android a year or so, and once Google realizes where it wants android to go, the iterations should slow down dramatically, and fragmentation will be a thing of the past.
Looking at the source code, it only uses jQuery for an on page load handler. The library itself doesn't have any references to jQuery or to the '$' context that jQuery uses. He probably could have used a body onload tag to achieve the same thing, but then when pushing new web standards and using methodologies from the early 90's, this was probably the safer path.
As a GMU graduate ('06) in the Computer Science department, and also as someone who went through their honors in general education, I can honestly say that I have an extremely well rounded education. My general education courses were extremely broad and deep. I had taken AP/IB courses in high school, as had most of my fellow honors students, and these courses were generally challenging for everyone. Also most of my CS courses were also very broad and deep at the beginning, but grew to be more focused as the years progressed. Now my educational path through Mason may not be what the normal person at Mason would go through, but it should be an example of what the school is about and what it is capable of. Though I will also say, that I am a firm believer that you will get out of an education what you put in to it. I have friends who have gone to top engineering schools, and my skills/abilities/job opportunities are on par with where they are at as well.
I have to agree with the GP 100%. Labeling the GP as flamebait is just unfounded and dumb. Flash has it's entire class hierarchy/toolset/API that is used internally in building the flash animations. If you look at the documentation for AS3 and AS2 and look at all the functionality that is currently available to Flash developers, you'll see the extra bloat that will need to make it into the export. Now I wouldn't necessarily call it bloat, but it is above what a normal person would expect for something done by hand. And as the GP also said, every SWF is a compressed archive. Gzip is great, but unless you have 100% control of your hosting (big companies will), it's not always feasible. It really is a trade off for the hosting company of CPU and load vs. bandwidth, and I'm assuming bandwidth is cheaper for them on normal hosting package.
Slashdot Mirror
And apparently I spoke too soon. It just took a good while for it to start up.
The second link doesn't run and asks to enable flash...
This is inherently the opposite of what you are saying. The goal of the language services is to provide the same functionality to all ides vs every ide implementing their own solution per language. This also allows for the language owner to be in charge of the quality of the services in the ide.
I do the same. We have a private repo that proxies (and stores) all copies of everything we use so that we won't lose access to them. It's kind of a bear, but on the Maven side, it acts as a network proxy for our entire dev team, though the overall benefits aren't that high.
As a server side language, I'm extremely torn. I've actually been using Typescript pretty heavily lately (and decorators), and it makes the code I write not too far off from the Spring/Java code I would generally write. My biggest concern with NodeJS is the maturity of the ecosystem, and how it plays with enterprise software development. One of my goto examples is LDAP support. There were a handful of libraries (circa 2014) that sort of worked, but had gaps, and ultimately required doing some odd trickery to work. The analog to Java would have been one or two libraries that are mature and just work.
I personally find NodeJS is generally a fine experience, but the ecosystem (which is what the story is about) is just lacking structure that other languages have. It will mature, but may be a lot of pain along the way. The other day I had to choose between Python and NodeJS for a utility I was writing, and I went with Python because batteries were included, and I was afraid of trying to figure out how to include dependencies on the remote host in a consistent and manner.
From a runtime environment, I agree there are lots of "quirks", and the DOM is one of the worst cross-platform interfaces of all time. Less of a contract and more of wishes and hopes. ES2015 really does focus on syntax (e.g. "use strict" is default when using modules and not required). "this" has always been a gotcha, but that is part of a language where the function is the unit context. I actually like that about Javascript (though I realize not everyone does). For that reason "let" was also introduced to provide more normal behavior for scoping per what others expect coming from other languages.
I don't think it will ever be a "Java" or "C#" but it isn't necessarily a bad thing as lot of people seem to be happy with it's design and how it works.
Javascript has some terribly bad parts (as does perl and php) and I would concur that languages like Python/Ruby seemed to be planned in entirety a bit more. I would recommend looking at ES2015+, the next revision of the Javascript. It does a lot to curb those issues (JS actually has a "strict" mode that handles some of the gotchas), and ES2015 adds proper module support, as well as a standard class syntax.
These features have been in use for years by transpilers (to cover the gap between agreement on a new language feature and the time before it is adopted by the runtimes). Typescript is an even more powerful extension of ES2015 that adds compile-time type analysis/verification but generates nearly perfect idiomatic ES2015 code.
I'm not sure how JavaScript would be that different than any other scripting language (Perl/Ruby/Python/PHP/Groovy), and those seem to have viable web ecosystems Not 100% sure where the hate for JS is coming from. Unless it's a disdain for scripting languages in general. That would generally leave you with C#/Java and Java, historically, has been the only cross platform solution, and the language has stagnated heavily over the last decade (though 1.8 and 1.9 are showing signs of life).
Maven has the same problem in the SNAPSHOT dependencies, as they are free to be updated in the standard cycles. You also have to consider that the Maven plugins run in the same space as the user (and are pulled from the same dependency repositories). This makes maven just as susceptible with one major caveat. There are multiple federated repositories and publishing to one of those repositories requires reputation, and hosting your own repository (without reputation) is like downloading untrusted APKs on Android.
Though honestly, you could only sheer a sheep once. It just wouldn't be pretty. :-)
Accidentally modded redundant. Commenting to undo.
Almost identically history, AppleBASIC in elementary, onto GW then QBasic in middle school. On to Visual Basic for a few apps in early high school and then into C++ with AP Computer Science. The only difference was that I was the last year of C++ before the transition to Java.
Pretty certain the tools for actionscript3 and actionscript3 itself (the language the flash runtime uses) is far more sophisticated and robust than javascript. AS3 is more comparable to Java and .NET, and would be a wonderful toolset for building web applications. It was everything Java attempted to be (in the browser).
2 tbsp = 1 ounce
1/4 cup = 2 ounces
Seems pretty straightforward to me.
Exactly. T-Mobile is already in a position that is friendly to unsubsidized phones. There is a reason Google and T-Mobile have worked together often. I know that Deutsche Telekom was looking to sell off T-Mobile as well. I guarantee that a T-Mobile infused Google would be near unstoppable.
If you are using KDE, Quanta Plus might be an option: http://en.wikipedia.org/wiki/Quanta_Plus
This is assuming they aren't doing their redirect with DNS records that are hosted outside of their infrastructure. Assuming they don't run their own DNS, wikipedia should be able to do this with almost no bandwidth costs.
Isn't that the point of using Google's copy of jQuery for your sight, in lieu of hosting it yourself. You can share the cache with any other site that is pulling the jQuery lib from a trusted 3rd party. After looking at the link you posted, that code may be simpler with respect to size, but in terms of maintenance or having a novice manage it (without introducing cross platform issues), it seems like it may be a nightmare. What would be nice, and Adobe has done this for flash, is to have a separate cache for trusted libraries. It would be nice if I could query to see if jQuery were available in a browser lib cache, and use it from there if available.
The flash runtime has experienced the same problems as it was a developing platform. Flash 8,9 and 10 are all still in use today and have different feature sets and programming models. I realize the analog is slightly different as android is an OS and not a runtime, but the fact remains that progress requires this. We as geeks bemoan long development cycles and slow progress. Well the way to get around slow progress is quick iterations, and that gets to you to fragmentation. Adobe has realized this and their rate of development has slowed as they have stabilized on where they want the platform to go. Give android a year or so, and once Google realizes where it wants android to go, the iterations should slow down dramatically, and fragmentation will be a thing of the past.
The source is not for you to read, but for bandwidth to be saved. You'd probably hate it more if the page took a lot longer to load as well.
Looking at the source code, it only uses jQuery for an on page load handler. The library itself doesn't have any references to jQuery or to the '$' context that jQuery uses. He probably could have used a body onload tag to achieve the same thing, but then when pushing new web standards and using methodologies from the early 90's, this was probably the safer path.
As a GMU graduate ('06) in the Computer Science department, and also as someone who went through their honors in general education, I can honestly say that I have an extremely well rounded education. My general education courses were extremely broad and deep. I had taken AP/IB courses in high school, as had most of my fellow honors students, and these courses were generally challenging for everyone. Also most of my CS courses were also very broad and deep at the beginning, but grew to be more focused as the years progressed. Now my educational path through Mason may not be what the normal person at Mason would go through, but it should be an example of what the school is about and what it is capable of. Though I will also say, that I am a firm believer that you will get out of an education what you put in to it. I have friends who have gone to top engineering schools, and my skills/abilities/job opportunities are on par with where they are at as well.
I have to agree with the GP 100%. Labeling the GP as flamebait is just unfounded and dumb. Flash has it's entire class hierarchy/toolset/API that is used internally in building the flash animations. If you look at the documentation for AS3 and AS2 and look at all the functionality that is currently available to Flash developers, you'll see the extra bloat that will need to make it into the export. Now I wouldn't necessarily call it bloat, but it is above what a normal person would expect for something done by hand. And as the GP also said, every SWF is a compressed archive. Gzip is great, but unless you have 100% control of your hosting (big companies will), it's not always feasible. It really is a trade off for the hosting company of CPU and load vs. bandwidth, and I'm assuming bandwidth is cheaper for them on normal hosting package.
Be careful to make sure that your predecessor quit, and didn't die. While possibly funny, that may not go over so well...
Yeah and roads too. Imagine if they couldn't drive anywhere to bring lawsuits...