Visual Studio Shell
-
I was trying to see what to download for the VS.NET 2010 Beta 1, and found that the Visual Studio 2010 Shell is also released.
- Visual Studio 2010 Shell (Integrated) Beta 1 Redistributable Package [^]: Download Size == 509.5 MB
- Visual Studio 2010 Shell (Isolated) Beta 1 Redistributable Package [^]: Download Size == 579.5 MB
MS still does not get it, ship over 500 MB to a user because I want to use VS.NET Shell? Best regards, Paul.
Jesus Christ is LOVE! Please tell somebody.
I don't mind it anymore. Initially I was turned off by that but now I realize that getting so much of VS stuff for free is well worth it.
-
Take it this way, no Xeon 5570 in this world will help any time soon either.. Ever since those PropertyGrids, dialogs and more moved to the JIT and .NET, you can visually see it taking time for everything to open up, render, close down, whatever; even on Cray. That is VS2003 to VS2008 and it is funny how it proves the Californian Law that the faster the hardware gets the slower the software becomes. Brilliant piece of engineering in carbon emissions. Advice from Redmond bloating central is to run it seperately, not to mix with existing VS2008 yet or run in VM. But you can risk it.. Put simply, you will now have a VS2008 XAML designer experience everywhere you go, future is bright, verbose, bloated, full of latency, cache pollution and buggy. Vista philosophy all over again. They will beat Eclipse in sluggish behaviour this time around. They just can't resist making things that scale like a common motorway *block*.. And before you know it, Google will have a JavaScript infrastructure that will be as usable in an interpreted bloody language, that's just silly.. Same can be said for SharpDevelop, LINQPad and more, they are dreadful hogs. Nice ideas but crap runtime behaviour.. tells something.
User of Users Group wrote:
usable in an interpreted bloody language, that's just silly
I'm not disagreeing, but I am very curious about your reasons for why it is silly?
-
I don't mind it anymore. Initially I was turned off by that but now I realize that getting so much of VS stuff for free is well worth it.
Rama Krishna Vavilala wrote:
Initially I was turned off by that but now I realize that getting so much of VS stuff for free is well worth it.
What happened to componentization of software? Best regards, Paul.
Jesus Christ is LOVE! Please tell somebody.
-
Rama Krishna Vavilala wrote:
Initially I was turned off by that but now I realize that getting so much of VS stuff for free is well worth it.
What happened to componentization of software? Best regards, Paul.
Jesus Christ is LOVE! Please tell somebody.
They're just really big components....
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Take it this way, no Xeon 5570 in this world will help any time soon either.. Ever since those PropertyGrids, dialogs and more moved to the JIT and .NET, you can visually see it taking time for everything to open up, render, close down, whatever; even on Cray. That is VS2003 to VS2008 and it is funny how it proves the Californian Law that the faster the hardware gets the slower the software becomes. Brilliant piece of engineering in carbon emissions. Advice from Redmond bloating central is to run it seperately, not to mix with existing VS2008 yet or run in VM. But you can risk it.. Put simply, you will now have a VS2008 XAML designer experience everywhere you go, future is bright, verbose, bloated, full of latency, cache pollution and buggy. Vista philosophy all over again. They will beat Eclipse in sluggish behaviour this time around. They just can't resist making things that scale like a common motorway *block*.. And before you know it, Google will have a JavaScript infrastructure that will be as usable in an interpreted bloody language, that's just silly.. Same can be said for SharpDevelop, LINQPad and more, they are dreadful hogs. Nice ideas but crap runtime behaviour.. tells something.
User of Users Group wrote:
Google will have a JavaScript infrastructure that will be as usable in an interpreted bloody language
In a modern web browser (think Safari 4, Chrome, FireFox 3.5), JavaScript is compiled to object code before execution, so your disgust at Eclipse and Visual Studio's bloaty performance can be turned down slightly. Only slightly though - I agree with you that they're appallingly slow. Why does it take so much effort to generate a project from the wizrd, FFS? All you're doing is instantiating a few templates - I can manage that with Python+Genshi (now theres a language that's definitely interpreted!) in a lot less time. When I think that I used to use VS5 and VS6 on a 700MHz Pentium 3 - and the performance was much the same (in my memory) as I get with VS2008 on a 2.4GHz Core2Duo...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
:laugh: :laugh: :laugh: Finally, vi/vim wins the debate, why didn't I realize this long ago? ;P
Jesus Christ is LOVE! Please tell somebody.
It so does not. :laugh:
-
:laugh: :laugh: :laugh: Finally, vi/vim wins the debate, why didn't I realize this long ago? ;P
Jesus Christ is LOVE! Please tell somebody.
Software Zen:
delete this;
Fold With Us![^] -
Software Zen:
delete this;
Fold With Us![^] -
They're just really big components....
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
User of Users Group wrote:
Google will have a JavaScript infrastructure that will be as usable in an interpreted bloody language
In a modern web browser (think Safari 4, Chrome, FireFox 3.5), JavaScript is compiled to object code before execution, so your disgust at Eclipse and Visual Studio's bloaty performance can be turned down slightly. Only slightly though - I agree with you that they're appallingly slow. Why does it take so much effort to generate a project from the wizrd, FFS? All you're doing is instantiating a few templates - I can manage that with Python+Genshi (now theres a language that's definitely interpreted!) in a lot less time. When I think that I used to use VS5 and VS6 on a 700MHz Pentium 3 - and the performance was much the same (in my memory) as I get with VS2008 on a 2.4GHz Core2Duo...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Perhaps I've phrased it wrong, but 'bloody' implies that intepreted is about to reach the performance of someting that is around 100,000 times larger, and supposedly 'cutting-edge'. Can someone say that is called good-scaling for CLR or anything Java? Man, I can recognise the managed app from the opposite corner of the floor by the nature the user is clicking on it (not to mention delays, hard-disk activity, jitting, erraticism/jitter, GC calling in when least required, GPU not utilised and: laughable RAM pressure effect it has on other components of the system ). The reason JavaScript is about to pave the floor is simple: instruction are free, cache is not. And CLR is one of the worst on instructions as well as cache memory out of anything made in the last, what, 40 years? JS's GC aside, something doesn't telly as all decent-size managed apps out there behave the same when given a medium load. ( Here come the brave souls defending their investements in blogs.msdn.com .. Here's a Haiku in response: LOB, LOB, productivity, my UI knob is uglier and feels no pitty :-)
modified on Saturday, May 23, 2009 12:59 PM
-
Perhaps I've phrased it wrong, but 'bloody' implies that intepreted is about to reach the performance of someting that is around 100,000 times larger, and supposedly 'cutting-edge'. Can someone say that is called good-scaling for CLR or anything Java? Man, I can recognise the managed app from the opposite corner of the floor by the nature the user is clicking on it (not to mention delays, hard-disk activity, jitting, erraticism/jitter, GC calling in when least required, GPU not utilised and: laughable RAM pressure effect it has on other components of the system ). The reason JavaScript is about to pave the floor is simple: instruction are free, cache is not. And CLR is one of the worst on instructions as well as cache memory out of anything made in the last, what, 40 years? JS's GC aside, something doesn't telly as all decent-size managed apps out there behave the same when given a medium load. ( Here come the brave souls defending their investements in blogs.msdn.com .. Here's a Haiku in response: LOB, LOB, productivity, my UI knob is uglier and feels no pitty :-)
modified on Saturday, May 23, 2009 12:59 PM
User of Users Group wrote:
haps I've phrased it wrong, but 'bloody' implies that intepreted is about to reach the performance of someting that is around 100,000 larger, and supposedly 'cutting-edge'
Ah - the way I read it was not that interpreted languages were coming up to the performance of compiled one, but that (byte-code) compiled languages were getting down to interpreted levels of performance :-)
User of Users Group wrote:
Man, I can recognise the managed app from the opposite corner of the floor by the nature the user is clicking on it (not to mention delays, hard-disk activity, jitting, erraticism/jitter, GC calling in when least required, GPU not utilised and: laughable RAM pressure effect it has on other components of the system ).
Where I work, 'I can recognise the managed app' usually implies 'I can recognise the Java app' (no .NET!) but the rest of the statement seems to ring true to me. The only interpreted language I've ever deployed is WIndows batch files :-)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Don't forget to throw in Resharper for VS2010 for extra super snappy performance. Pretty soon we'll have an HDTV overlay inside of visual studio so we can watch the riots at the next Microsoft developers conference while waiting for our WPF editor to render it's HDR rendered fonts. It wont be long before 80 character monochrome is back in vogue.
Todd Smith
LOL, that made my day.. so true. Throw in a virus scanner, 5 WPF apps running concurrently, 8 IE's with Silverlight eating around half the RAM (few hanging at 30% utilisation), 19592 services in the background, and you are about to see a proper OS reboot or *recover-in-memory* around 80 times by the time one can meaningfully react to a shiny ListBox or a button. Redmond at its best, Architects of future-DLR-bloat.com..
-
User of Users Group wrote:
haps I've phrased it wrong, but 'bloody' implies that intepreted is about to reach the performance of someting that is around 100,000 larger, and supposedly 'cutting-edge'
Ah - the way I read it was not that interpreted languages were coming up to the performance of compiled one, but that (byte-code) compiled languages were getting down to interpreted levels of performance :-)
User of Users Group wrote:
Man, I can recognise the managed app from the opposite corner of the floor by the nature the user is clicking on it (not to mention delays, hard-disk activity, jitting, erraticism/jitter, GC calling in when least required, GPU not utilised and: laughable RAM pressure effect it has on other components of the system ).
Where I work, 'I can recognise the managed app' usually implies 'I can recognise the Java app' (no .NET!) but the rest of the statement seems to ring true to me. The only interpreted language I've ever deployed is WIndows batch files :-)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
We're on the same page.. it just takes time to realise where its all going :) I still have vivid memories of VC on 200MHz Pentium pros.. 105% it is, was and always be snappier than a 50x times more powerful box (including half a teraflop of GPU or not) than VS2008. Not that these stats matter per se, but they tell a HUGE fact on what is going on in managed software and how to leverage the differential (and we will be forced to sooner rather than later). And Google is not wasting any time and leveraging open-source and open-tech to its best and in a very smart way. OpenGL and JavaScript engine with their service are here to stay, beat and wipe the floor of Live, Azures, Oslos, and other architectural-inventions-of-Java-style. No wonder they are crapping themselves and giving software/Sparks, dynamic typing, MVCs and other things a priority. Here is a usual lambda: MS => LOCK-IN-TILL-IT-HURTS-AND-THEN-SOME.
-
Perhaps I've phrased it wrong, but 'bloody' implies that intepreted is about to reach the performance of someting that is around 100,000 times larger, and supposedly 'cutting-edge'. Can someone say that is called good-scaling for CLR or anything Java? Man, I can recognise the managed app from the opposite corner of the floor by the nature the user is clicking on it (not to mention delays, hard-disk activity, jitting, erraticism/jitter, GC calling in when least required, GPU not utilised and: laughable RAM pressure effect it has on other components of the system ). The reason JavaScript is about to pave the floor is simple: instruction are free, cache is not. And CLR is one of the worst on instructions as well as cache memory out of anything made in the last, what, 40 years? JS's GC aside, something doesn't telly as all decent-size managed apps out there behave the same when given a medium load. ( Here come the brave souls defending their investements in blogs.msdn.com .. Here's a Haiku in response: LOB, LOB, productivity, my UI knob is uglier and feels no pitty :-)
modified on Saturday, May 23, 2009 12:59 PM
User of Users Group wrote:
Man, I can recognise the managed app from the opposite corner of the floor by the nature the user is clicking on it (not to mention delays, hard-disk activity, jitting, erraticism/jitter, GC calling in when least required, GPU not utilised and: laughable RAM pressure effect it has on other components of the system ).
You are dead right - and I see the same things all the time. I'm proud of the software I write, but more specifically what it does. What I'm not proud of is the way it jumps up and down shouting "Look at me, I'm a CLR application". The worst part is there is very little I can do about it.
User of Users Group wrote:
And CLR is one of the worst on instructions as well as cache memory out of anything made in the last, what, 40 years?
Is that just experience and instinct telling you that, or has there been some formal research done on it? It's a topic I find really interesting. And make sure you keep posting! We all need the reality check as often as possible!