It's a shame this dude was running late for the presentation.
at least I assume he was, he's got his electric shaver with him.
Windows developers have suffered multiple changes of direction in recent years. There is Win32, WPF (Windows Presentation Foundation), Silverlight, and now WinRT (Windows Runtime), the platform formerly known as Metro. Can they be confident in the longevity of the new thing, or might it be swept away in favour of some other new …
at least I assume he was, he's got his electric shaver with him.
Clearly not a shaver or that ghastly 'tache would have been gone.
Incidentally, don't you just hate those boy-beards the hipsters are currently sporting.
Thanks for the heads-up. I'll give WinRT three years max before is it 'All Change Please' once again.
seems like proper commitment, this time.
Are variadic templates "critical" other than for producing even more unreadable and unintelligable code than can be managed by normal templates? I avoid templates like the plague unless there's a really good reason or I have to use them ( eg STL). Seems to me C++ is just turning into a language geeks wish list rather than a clear and sensibly designed programming language for developers who simply use it as a means to an end. (And yes, I am a C++ developer).
Variadic templates simplify things like std::tuple and std::function and forwarding functions (think of things like std::bind1st, std::bind2nd and boost::bind). The way Boost and VC2012 implement them is to explicitly generate N versions of those classes/functions (1 template arg, 2, ..., N). For example:
template<typename T1> struct tuple;
template<typename T1, typename T2> struct tuple;
template<typename T1, typename T2, ..., typename Tn> struct tuple;
With variadic templates, this simplifies to:
template<typename T1...> struct tuple;
This is not only less code (easier to maintain), but the compiler performance is orders of magnitude better at compiling them (memory and speed). The gcc version goes from exponential time with the number of template parameters to a second. [See http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html].
You see, this is why I never became a software programmer, you lost me at.... Re: thx for asking about
I wish I could, I really do but my brain laughs at me anytime I try.
"think of things like std::bind1st, std::bind2nd and boost::bind"
I'd rather not thanks, I've just had lunch. C++ was supposed to make programming easier compared to C. Its actually done the opposite by creating a syntax so vast and obtuse with some much potential for implicit code execution, its close to vying with Perl as a write only language. Thats a big fail IMO, however I don't expect many people to share it.
It's not that bad, You don't have to rushing to write the cleverest template code you can.
Write simple code and C++ is a lovely language to work in provided you follow the rule.
Finally you have both typedef and a macro pre-processor, you really don't have any excuse for code that's hard to read.
Boost and the STL contain some very clever code (a bit hard to read, I grant you) but there are quite a few open source frameworks which are rather easy on the eye, try looking at http://www.webtoolkit.eu/wt for an example of clean easy readable C++ write on top of Boost no less.
Good you asked.
Yes, variadic templates (and templates in general) are important. Rember "printf"? Remember what happens when you use wrong type in format string? Templates in general help to avoid these problems. Since you do *use* templates (in standard containers) you probably did notice that they are not actually difficult to use. They are sometimes difficult to write, but that is slightly different from *using* them (slightly, because in both cases you have to learn to understand compiler errors thrown at you).
Back to "printf" - variadic templates enable someone (not necessarily you) to write a function taking unbound number of parameters (like printf does) and process these parameters during compilation time, thus enabling type safety (which variadic macros do not provide). In practice this means allowing one to write functions with interface similar to "printf", where compiler actually knows types of all parameters supplied when you call it. You don't have to write such a function - but as explained above, writing is not the same as using.
And frankly, if you are too dumb to learn how to use templates (or exceptions, destructors etc.), perhaps C++ isn't for you. There is plenty of less demanging languages to choose from.
If you still want to learn programming, start with the right language. These days I'd suggest Python. Anyway, definitely a scripting language (interpreted), so you can type bits of code at the computer and immediately see what they do. As a side-bonus, you won't need to pay a penny for a compiler or a developer environment (even if you are determined to stick with Windows).
If you get to the point where you are a competent programmer and are being frustrated by the slowness of code written in your script language of choice, you might then consider learning a compiled language. (But do first make sure someone hasn't already written what you need!)
hah, just noticed my slip of the tongue.
demanging - damaging if your skillset is not up to level demanded by the tool.
Can anyone strip all the marketing jargon and handwaving out of that and work out what, if anything, he's actually saying? There seems to be a lot of vague promises and assurances, but that's about all.
Microsoft have a history of messing about with programming interfaces - look at all the different database access methods they went through.
Here's my take on what was said - Microsoft is committed to all the technologies in Win8 for the life of Win8. i.e they make no promises they will survive in Win9.
In fairness though, while Microsoft may have went through many database access methods (to use your example), all of them continue to work in Win7.
I had thought aManFromMars had broke loose and now was doing the interview. Actually, where is our favourite martian, to suss this all out?
Reading carefully, and passing the text through my special MS manadjmuntspeak tranzlator, it looks to me like he said 'MS is totally TeH Win. I love you. Apart from that, whatevs babe.'
Anyone who thinks Win RT is going to be any kind of standard should be sentenced to a lashing by the Cat o' Nine iOS Fails.
Another bunch of marketing bla bla from Soma.
The messaging hasn't been very good, when they first announced WinRT, it sounded like .Net was dead.
They talk up Xaml a lot, but it seems like each platform has a distinct and not very compatible version. Silverlight is a lot like WPF, but its different enough to be a real pain.
I would have thought more like playing Russian Roulette!
Either way, it confirms that Windows 8 is a true gaming platform...
I think you meant "a true gamble" not a true gaming platform ....
Masters of double speak. Sounds just like another bunch of marketing hype over something that is probably destined to fail. The end of microsoft can't come soon enough for me!
Microsoft has its faults, for certain, but there are a lot of us totally reliant on the MS legacy for our livelihoods. I looked into linux as an alternative a long while ago, and to be honest the opportunities for earning money just couldn't match up, and they still don't (unless you're really at the top of your game - and by definition not everybody can be!).
Funny you should say that... I look at my income over the 2011—2012 financial year... and maybe 1% of my earnings had anything to do with Windows.
Namely, fixing up a problem with a web page that wasn't loading right in IE8. (the web application is the front-end of an energy management system.) Everything else for me revolved around Linux.
All you need is 40GB Visual Studio
Here's a quid, so you can get the extra space required...
...So programming on Win 8 is a big gamble...he said it, not me!
There is no gamble at all.
They have removed a few of the balls so there is no way your going to win.
basically Windows said "jump" and the Visual Studio team said "how high"
after a brief rebellion where they tried to create .Net, WPF and Silverlight as attempts to stay relevant the Windows team has reminded them that developers hate this "new shiny objet" churn and put them back to writing tools for languages that work and have a future.
an example... while Microsoft thrashed about taking Classic ASP and bolting on about 4 releases of .Net to make it monolithic and complex PHP and Python continued to evolve as small agile solutions... the impact seems to be that IIS and .Net lost the traction asp had got as developers voted with their IDEs. Android, iOS, OSX ... they all have one predominant way of doing things and you know it's got a decade or more of life... on Windows (x86, RT or Phone) you're lucky if the landscape stays recognizable for 18 months.
PH - egh, yuck. sorry I think a house fly flew into my mouth - P
Developers don't determine what platform consumers buy.
Honestly, does anyone actually care that the new interface is no longer called "Metro"? Yes they had to change it for legal reasons and of course they don't really want to admit that, but does it actually matter? I for one couldn't really care less what they call it.
It's more how they call it- the APIs aren't consistent...
Don't really care what they call it, as long as they call it *something*. At the moment, they haven't got a name for it, just a bunch of descriptions. "Modern apps", "Windows 8 apps", "Windows store apps", etc. Those aren't names. Call it "Squareo" or "Touchblox" or whatever you like, we'll get used to it as long as they don't keep changing it.
Soma seems to be doing an impression of a flounder. Is this to suggest Microsoft are floundering?
Darn, I'm hungry now
Mine is the one with Rick Stein's "Seafood" in the pocket (OK, in the backpack).
I saw the writing on the wall a long time ago, when MS ditched OS/2 APIs (pretty nice for their time) in favor of Win32 (pretty awful any time). The change was just so radical, and broke so much of our code more or less permanently, I determined that they either did not understand what was under all that or they had some strategic reason for creating the havoc. To be honest, even though I keep a tin-foil hat near me at all times, I am still not sure if we are facing incompetence, malice or some combination.
What I advised back then, have continued to advise and essentially advise now is to abstract your own core business function so it does not care about the underlying APIs or metal and spend as little as possible on that. Concentrate instead on *data*, which, despite decades of thrashing about is still a very weak point in the entirety of the fortune 500 and government.
As part of the data piece, I have, since the early 1990s advised to pay special attention to security. In my opinion, it is essentially impossible to secure most of the perimeter and hence it makes good sense to concentrate on 'core' stuff and protect that by having huge redundancy, integrity checks, and at all times 'proximal' (a few simple transforms away) human-readable representations. Humans can still spot 'blemishes' and tampering much better than any machine. Let the machine do exhaustive comparisons, but let people examine 'canvases' of data to spot problematic anomalies.
Although I have kept abreast of things I have only coded against stuff like .NET or SOAP when specified by third parties and otherwise done vanilla code against thin abstraction layers using largely immutable stuff like ANSI-C. I have, admittedly, had more latitude than most, but nearly every working programmer has been presented (numerous times) with embracing the flavor of the week/month/year or taking a more conservative line. The conservative ones, in my opinion, have won hands down. If you are a programmer and you look under the covers you will see a *ton* of C/C++ code between whatever you are working with and the metal. It is not because other ways have not been tried. They have been tried and they have ultimately failed.
At some level, you are obliged to embrace some third-party abstractions and protocols. Here, FWIW are some of the ones I have embraced:
HTTP(S)/(S)FTP and similar long lived protocols
[Binding SQL programmatically is an ongoing problem. I reluctantly use vendor stuff (MS, Oracle, etc) or other language bindings]
.gz, .tar, .zip
SAMBA & Co.
Will MS change this again? Bet on it. I am.
There may be a number of different tools, but thats becuase there are a number of different jobs (and some of the tools are older than others)
- Win32 / GDI is the original API that has been around since the dawn of Windows. Its stable, reliable, its here to stay until the end of time (for backwards compatability reasons) and its also a pain in the ass to use because the API was designed before OOP became prominant (and also for backwards compatability reasons)
- Windows Forms is essentially just a wrapper around the WIn32 API / GDI. Its stable, reliable, infinitely easier to use than the Win32 API, and again here to stay until the end of time.
- WPF is for developers creating "rich" (i.e. flashy) user interfaces for desktop PCs. Windows forms is still built on top of GDI, a system originally designed at the time of 16-bit operating systems and so its not really geared around flashy interfaces. WPF aimed to make things easier by starting from the groud up with a new layout engine. Its future may not be as assured as Win32 or Windows Forms, but I'd say that its still a fairly safe bet that WPF will be around for a while.
- Silverlight is a WEB technology, don't confuse Silverlight with WPF just because it uses XAML. There probably could have been more consistency with WPF, however in a lot of places the inconsistency is there because its a WEB technology and just can't do everything WPF can (e.g. for security reasons).
- WinRT is a technology for building mobile (i.e. phone and tablet applications). Like Silverlight, don't confuse WinRT with WPF & the .Net framework just because it uses XAML, and again like Silverlight its inconsistent in places because you can't do everything that you can do on a desktop on a tablet. You woulnd't choose WinRT to build desktop applications, you choose WinRT to build mobile applications - the fact that they work on desktop PCs too is just a bonus.
Maybe they could have been more consistent in places, but I don't really see the "change in direction" - Each of these technologies has its purpose (even if that purpose is allowing me to keep developing my legacy applications).
Time to find the old disc of VB6 then.
With Windows 9 Microsoft will enable “Modern UI” to be Windowed, re-sized and docked on a desktop computers and big-screen panels. The task-bar will be replaced with a Start bar that are active tiles instead of icons.. many will call it a return to Win7, but MS will describe it as WinPhone experience for large displays, and those without MS keyboards (that replace function-keys with a touch panel). There will be no return to the “start” button, but there will be a “Home” app that is more like a WinRT version of Win3 Program-Manager intended as a launch-pad for Windows-Store-Azure-Apps. Windowed WinRT apps will look pretty indistinguishable to WPF apps (which will gain traction after Microsoft open-sources .NET).
We’d wonder what all the fuss was about, but will be told it was all needed because the Windows-8 touch interface didn’t fit with Windows-9’s gesture interface & kinetic keyboards.
As for programming… even MFC will still be supported!
Its the one thing thats consistent with Windows - the chant that it will all be fixed in the next version - yeah right.
Ohh, it'll be "fixed", but for every problem that is fixed, there are at least several things broken in the process.
“But go back to Windows 32. That’s a platform that came out 15 or 20 years ago. That platform has stood the test of time. Take .NET for example. That has stood the test of time. Take WPF [Windows Presentation Foundation] for example. We absolutely continue to support WPF for desktop applications. Visual Studio uses WPF for its own application, because it makes sense in that scenario."
He missed out Win64. This is sufficiently different from Win32 that most apps for the latter platform have not yet been ported. Perhaps he's drunk too much cool-aid and doesn't know this.
Win32 is indeed still here, unless you are talking about their 64-bit Server platform, in which case it is an option. MS would rather you targetted Win64.
.NET is not. (It's absence is the main reason why Win8 manages a smaller footprint than Win7.) It is true that there's some logic to automatically download it from the web if you try to install a .NET application, but the writing on the wall is clear -- MS would rather you didn't use this anymore. There was also (at least during the beta program) a nice bug whereby it would download the wrong language if you (say) bought a machine with US English pre-installed but immediately changed it to your local tongue. Apparently this was by design.
Visual Studio uses just about everything (not just WPF) because it needs to let you develop for just about everything. Apart from the demo-ware aspect, you can't write a decent IDE without incorporating a little bit of "invasive" code to let you debug a given target. If he can't find a better example than VS then we can assume that WPF is moribund.
.NET is not. (It's absence is the main reason why Win8 manages a smaller footprint than Win7.)
Uh, what? Yes it is. .NET4 is installed by default, .NET3.5 (which is cumulative and contains .NET1, .NET1.1, .NET2.0, .NET3.0 and .NET3.5 itself) is an option install, like IIS.
Where is all this ".NET IS DED O NOEZ WE IZ ALL DUMED" bullshit coming from? It can't be from .NET developers, who already know better.
So what's the source? Ignorant people with big mouths or deliberate FUD? Gotta be one or the other.
Oh, and @Ken Hagen -
WPF is a Presentation Framework (hence the name). It can't do anything except draw shit on the screen (along with some stuff like bidirectional binding, which is nifty but exists for the purposes of, er, drawing shit on the screen).
Nobody with any clue as to what they were talking would claim that VS2012 is written wholly in WPF because that would be impossible. Thus, I find your attack on the speaker either a) ignorant or b)... disingenuous.
None of the things you call dead are dead.
Why are you lying?
Well, dead, or persistent vegatative state. What's the practical difference?
The only thing you can say that about is Silverlight.
I don't know why the Reg keeps on running this same bullshit story day after day but as a dev/tech architect who is actively using and developing for Win8 right now, here's how it is.
The .NET framework is a means of addresses core APIs via managed code. It also includes a lot of handy functionality and utility APIs. .NET 4.0 is bundled with Win8. You can't even disable it during the install - it is there whatever you do. It's regarded as a core part of the OS.
In the past, .NET addressed the Win32 API. Then it was expanded to include the Win64 API. Now they've added the WinRT API to the functionality which .NET can address. Does WinRT have all the power of Win32? No. Does .NET address it? Yes.
You can still write .NET code in VB, C#, (Managed) C++, F# and IronPython. You pick the platform you're targeting, you just have more choices than "Win32/Win64/Mixed".
.NET 4.5 is now released and contains some pretty wow functionality in terms of the Web API and MVC4.
The article is just more of this outright falsehood. How in the hell is this being reported as fact?
Edit button please - you can also say that about XNA, which, although it still works and can be used to develop desktop and XBox games, is not being updated and can't write Metro games. Like Silverlight which will be supported but not updated.
But that's seriously it. Neither of those two addressed the full .NET framework anyway.
Why does the Reg keep telling us .NET is dead when it clearly, to anyone who bothered who to even look for 5 seconds, isn't?
Biting the hand that feeds IT © 1998–2017