the runtime environment for Android is written in C++ anyway, well the underlying libraries are. Most of the problems for Android seem to be a lack of a C++ development environment for people coming from Symbian and/or Linux who have existing code they want to port/re-use.
The reason we have so many different VMs is because of licensing. IIRC Sun's 'open' java licence doesn't apply to the one used in mobile devices. We do have a decent common 'VM'... its Linux. If you code for a linux implementation, you'll be able to run on whichever platform Linux is ported to. You won't necessarily get fancy user libraries like a GUI, but then you don't get those things anyway in all VMs (eg you'll still have to do work to port to other devices even if its just to handle different screen sizes)
I think the point is that there are no wrong answers with that kind of question. It does however illuminate their thought processes, which is exactly what you want to see in an interview.
Now, if you want to be naughty, after seeing their list, ask them how that list would apply to a project that their list would be totally inappropriate for. Assuming they didn't first say the list depended heavily on the project!
because Nvidia doesn't have the same API set, so any GPGPU processing has to be 'lowest common demoninator' for consumer-marketed software.
In other words, unless you have the luxury of specifying a particular make of graphics card, you won't write code to take advantage of these new APIs because you will immediately limit your target audience (and no doubt several people will criticise it for not running on their hardware and give it a bad reputation).
Now, if you could make it so it ran in hardware on your AMD card, but fall back to software emulation if you had a Nvidia card, that'd be different. Your software woudl then run, and you'd have a competitive advantage over Nvidia. People would start buying ATI cards... until Nvidia pulled the same trick.
Clippy: "Hi, it looks like you're writing a letter. Would you like some help with that... using free templates from MyResume.com that provides the best offerings of free CV and job related resumes to give you that edge in your job hunt".
get the idea why Google would want to compete on an online Office suite?
Not necessarily, the LSB can have a standard for every language under the sun, you don't have to use all of it. I know that sounds like 'why bother then', but it means that if you want to code java, then you will have java in/usr/bin/java and you can code with that in mind. When you then install java using a rpm/deb you know where it'll end up being installed to.
That's what makes the difference. Windows is partly successful because you can code for it, and know what you'll be getting. OK, sometimes you need to install an updated package but that's it, and once installed you're completely ready to go.
It not much of a difference from what we have today... except when I install an app on Centos it ends up in one directory, on Debian it ends up somewhere else. That's really not so good for development. As for minimum versions, that just means only certain releases of distros will end up supported, but that's no different from today anyway, if you get java 1.4 on Centos3 but the LSB mandates java 1.6, and Centos 5 supports it, then support for Centos3 will just fade away.
So the LSB is a sensible thing, that shouldn't cost anyone much at all.
erm.. remember that the low-level Android API is entirely written in C++. And the whole thing runs on Linux.
So your "cross platform" problems are immediately concerned with the APIs Android and Linux gives you, so your C++ apps will be as cross platform as Java. (ie its not the same as running a desktop app on Linux, Windows and Mac - here you're running solely on the Android platform).
Symbian is irrelevant, its the huge amounts of code those Symbian developers have that they want to reuse that matters. If they now have to write the same stuff all over again for Android, they're less likely to do so. Why would any of them bother to port to Android if they already have a huge market for Noika phones? If they could port easily (or semi-easily) then I'm sure they would - the market for Android suddenly increases dramatically. To rewrite in Java means they won't until they see a large market already, and that won't happen if they're not developing for it.
Don't forget that a Java implementation (on mobile) is not as cross platform as you'd think, and mobile phone development is never "it just runs" simply because of the different resources available like screen sizes.
See the link here where he describes one mobile java developer who had to make 100 versions of his java app to make it run on lots of phone models.
I think Android on Linux is a good idea, a common platform and a common API means all the hard porting work is done by the manufacturer. Putting Java on just doesn't make sense when you've got that niceness; and you have a large developer base waiting to port their apps and suddenly finding they can't.
PS. the java used on Android isn't really JavaME, due to Sun licensing. I suppose its a possibility that Google could develop a c++ compiler that turns c++ code into dalvik bytecode, or perhaps (more likely) a C# or VB.NET one. Wouldn't that be fun?.....
generally considered that the problem is not the linux base of Android, but the java base for its API. There's a lot of Symbian c++ developers out there with a ton of code they're ready to reuse... except they cannot in Android. A lot of them are also complaining about performance of low-level coding they've had to use previously. They don't want to write image processing routines in java for example.
Considering Android's built on Linux, and the difficulty in using an API is the features and documentation of that API (and that Google's done a good job there), and the Android low-level stuff is written in C++ anyway, then a C/C++ API would probably have been a better choice for it.
Now I ask you: It's an ATM machine. What was gained by the transition?..... Really the only benefit of the new machines was the ability to show color ads during the transaction
yeh, trouble is you'd only need a saucer section with a 27km circumference and hope that you got the first hit in, which as you know is impossible because you've always got to let the bad guys blast you so you can stagger from side to side while sparks fly out a console.
lol, no I think you were right... ignore the marketing message and stick to WCF as webservice only and you'll be fine. (until they deprecate it too in favour or XML serialised Biztalk connector objects:-) )
I think it was supposed to be a replacement for all the other comms tech, from years and years ago, but I guess someone started work on it and then realised just how much effort it would be to repackage everything up (or figured out that they got a better "value-return-proposition" by just slapping a.NET wrapper on top, pretty much like the rest of.NET)
Its supposed to be a complete communications framework for all kinds of IPC. I see from your post that you've only seen/used the webservice stuff, but there is more in the whole package. I think WCF is positioned as the main communications system for everything in.NET
All my info comes from Juval Lowy's book (though probably with more stuff picked up here and there)
I know, but do the Office guys use it? I recall when the Ribbon toolbar control came out (developed by the Office team) and it was for MFC only. There was a little outcry from the C# community at the time.
So it seems to me Office still uses MFC, I doubt they'll be quick to rewrite it in.NET, and Office is the number 1 important division at MS. So I'd love to know more about how things are panning out in Redmond regarding this.
WCF.. apart from my pet peeve with it: its sockets implementation is 'specially optimised for great ECF to WCF performance', ie it doesn't provide any interoperable tcp/ip socket, its a layer on layer on layer technology.
WCF runs on top of COM+, which was pretty poor for performance, which is layered on top of DCOM, on top of TCP/IP. Its queue connectivity - on top of MSMQ.
I think there's the potential for it to be good, and its webservices is better than running ASP.NET webservices (but not as good as gsoap:) ).
I'd prefer a nice, easy to use socket library with data transfer helpers, I think WCF will find its niche as a webservice provider, but no more than that.
on the other hand the C# stuff moves sofastyoucan'tkeepup. LINQ to SQL is already a dead technology, MS is killing it off in favour of entity framework. C# was modified specially to have lambdas, and now dynamic typing and extension methods. What's going to come next to screw with the original 'nice design'? You know that its going to go wrong sooner or later - just think of the projects you've worked on where the customer or tech lead insisted on adding all kinds of stuff in knee-jerk reactions to the latest problem. MS is doing just the same here.
C/C++ being slow is a good thing compared to the alternative. When you consider something like "c++ unstable" (ie boost) then you get the best solution you're likely to ever get in the real world.
whilst you can get a decent performance from querying a DB because its designed to be used like that, applying the same principles to an in-memory collection is not always going to be the best choice, in fact is probably always going to be a really bad choice.
Its like choosing a list structure for your random access needs, so just be aware that what is easy for you to code up doesn't mean its the best solution for your users.
generally the real reason its less complicated on.NET is because of Visual Studio. I had the pleasure of maintaining some VB.NET code very recently, and even with my very limited VB.NET skills (this was my first vb.net app!) it was kinda easy.. mainly because the IDE filled everything out for me.
If I had to do it in notepad, I'd have been screwed. I'm not saying it is a good language as there was plenty of 'issues' in the class libraries I used, and it was a real PITA to remember to just forget about objects and let the GC work for me, but with the IDEs extreme help, it was pretty easy.
Slashdot Mirror
the runtime environment for Android is written in C++ anyway, well the underlying libraries are. Most of the problems for Android seem to be a lack of a C++ development environment for people coming from Symbian and/or Linux who have existing code they want to port/re-use.
The reason we have so many different VMs is because of licensing. IIRC Sun's 'open' java licence doesn't apply to the one used in mobile devices. We do have a decent common 'VM' ... its Linux. If you code for a linux implementation, you'll be able to run on whichever platform Linux is ported to. You won't necessarily get fancy user libraries like a GUI, but then you don't get those things anyway in all VMs (eg you'll still have to do work to port to other devices even if its just to handle different screen sizes)
don't worry, as soon as it's popular, they'll create a half-assed version called IronFlex.
I think the point is that there are no wrong answers with that kind of question. It does however illuminate their thought processes, which is exactly what you want to see in an interview.
Now, if you want to be naughty, after seeing their list, ask them how that list would apply to a project that their list would be totally inappropriate for. Assuming they didn't first say the list depended heavily on the project!
you mean like:
"Adobe, your flash crashed my boxen, you sux0r. Give me teh codez so I can work l33t skillz on it and fix it 'cos you are so n00bs". :-)
Dear MS. I have a foolproof way of enhancing and improving upon your algorithms to determine the exploitability index.
if it comes up heads, its exploitable. Tails its gonna be ok.
I estimate you will increase your predictive capabilities by a whole 10% using this method.
because Nvidia doesn't have the same API set, so any GPGPU processing has to be 'lowest common demoninator' for consumer-marketed software.
In other words, unless you have the luxury of specifying a particular make of graphics card, you won't write code to take advantage of these new APIs because you will immediately limit your target audience (and no doubt several people will criticise it for not running on their hardware and give it a bad reputation).
Now, if you could make it so it ran in hardware on your AMD card, but fall back to software emulation if you had a Nvidia card, that'd be different. Your software woudl then run, and you'd have a competitive advantage over Nvidia. People would start buying ATI cards... until Nvidia pulled the same trick.
Clippy: "Hi, it looks like you're writing a letter. Would you like some help with that... using free templates from MyResume.com that provides the best offerings of free CV and job related resumes to give you that edge in your job hunt".
get the idea why Google would want to compete on an online Office suite?
yeah, if you're complaining about the performance and resource usage of your favourite IDE, you need to run Visual Studio 2008. oh wait a minute....
Not necessarily, the LSB can have a standard for every language under the sun, you don't have to use all of it. I know that sounds like 'why bother then', but it means that if you want to code java, then you will have java in /usr/bin/java and you can code with that in mind. When you then install java using a rpm/deb you know where it'll end up being installed to.
That's what makes the difference. Windows is partly successful because you can code for it, and know what you'll be getting. OK, sometimes you need to install an updated package but that's it, and once installed you're completely ready to go.
It not much of a difference from what we have today... except when I install an app on Centos it ends up in one directory, on Debian it ends up somewhere else. That's really not so good for development. As for minimum versions, that just means only certain releases of distros will end up supported, but that's no different from today anyway, if you get java 1.4 on Centos3 but the LSB mandates java 1.6, and Centos 5 supports it, then support for Centos3 will just fade away.
So the LSB is a sensible thing, that shouldn't cost anyone much at all.
I think we've both been relegated to the carehome of 'old languages' by those upstart brothers C# and VB.NET and their backward cousin Mono.
Now get off my lawn, I have some programming to do using only the mouse and the '.' key :)
except that I think we can guess what some of Microsoft's money is being spent on here.....
erm.. remember that the low-level Android API is entirely written in C++. And the whole thing runs on Linux.
So your "cross platform" problems are immediately concerned with the APIs Android and Linux gives you, so your C++ apps will be as cross platform as Java. (ie its not the same as running a desktop app on Linux, Windows and Mac - here you're running solely on the Android platform).
Symbian is irrelevant, its the huge amounts of code those Symbian developers have that they want to reuse that matters. If they now have to write the same stuff all over again for Android, they're less likely to do so. Why would any of them bother to port to Android if they already have a huge market for Noika phones? If they could port easily (or semi-easily) then I'm sure they would - the market for Android suddenly increases dramatically. To rewrite in Java means they won't until they see a large market already, and that won't happen if they're not developing for it.
Don't forget that a Java implementation (on mobile) is not as cross platform as you'd think, and mobile phone development is never "it just runs" simply because of the different resources available like screen sizes.
See the link here where he describes one mobile java developer who had to make 100 versions of his java app to make it run on lots of phone models.
I think Android on Linux is a good idea, a common platform and a common API means all the hard porting work is done by the manufacturer. Putting Java on just doesn't make sense when you've got that niceness; and you have a large developer base waiting to port their apps and suddenly finding they can't.
PS. the java used on Android isn't really JavaME, due to Sun licensing. I suppose its a possibility that Google could develop a c++ compiler that turns c++ code into dalvik bytecode, or perhaps (more likely) a C# or VB.NET one. Wouldn't that be fun?.....
generally considered that the problem is not the linux base of Android, but the java base for its API. There's a lot of Symbian c++ developers out there with a ton of code they're ready to reuse... except they cannot in Android. A lot of them are also complaining about performance of low-level coding they've had to use previously. They don't want to write image processing routines in java for example.
Considering Android's built on Linux, and the difficulty in using an API is the features and documentation of that API (and that Google's done a good job there), and the Android low-level stuff is written in C++ anyway, then a C/C++ API would probably have been a better choice for it.
Now I ask you: It's an ATM machine. What was gained by the transition? ..... Really the only benefit of the new machines was the ability to show color ads during the transaction
I think you answered your own question.....
can you please refrain from mentioning Goatsees when discussing a 27km-round ring.
yeh, trouble is you'd only need a saucer section with a 27km circumference and hope that you got the first hit in, which as you know is impossible because you've always got to let the bad guys blast you so you can stagger from side to side while sparks fly out a console.
lol, no I think you were right... ignore the marketing message and stick to WCF as webservice only and you'll be fine. (until they deprecate it too in favour or XML serialised Biztalk connector objects :-) )
I think it was supposed to be a replacement for all the other comms tech, from years and years ago, but I guess someone started work on it and then realised just how much effort it would be to repackage everything up (or figured out that they got a better "value-return-proposition" by just slapping a .NET wrapper on top, pretty much like the rest of .NET)
with Microsoft wanting the graphics in the kernel for performance
I doubt it, NT 3.51 has userspace graphics. It was NT4 with its Win95-like GUI that moved the graphics subsystem into the kernel.
Well, and what else is it supposed to be?
Its supposed to be a complete communications framework for all kinds of IPC. I see from your post that you've only seen/used the webservice stuff, but there is more in the whole package. I think WCF is positioned as the main communications system for everything in .NET
All my info comes from Juval Lowy's book (though probably with more stuff picked up here and there)
I know, but do the Office guys use it? I recall when the Ribbon toolbar control came out (developed by the Office team) and it was for MFC only. There was a little outcry from the C# community at the time.
So it seems to me Office still uses MFC, I doubt they'll be quick to rewrite it in .NET, and Office is the number 1 important division at MS. So I'd love to know more about how things are panning out in Redmond regarding this.
WCF.. apart from my pet peeve with it: its sockets implementation is 'specially optimised for great ECF to WCF performance', ie it doesn't provide any interoperable tcp/ip socket, its a layer on layer on layer technology.
WCF runs on top of COM+, which was pretty poor for performance, which is layered on top of DCOM, on top of TCP/IP. Its queue connectivity - on top of MSMQ.
I think there's the potential for it to be good, and its webservices is better than running ASP.NET webservices (but not as good as gsoap :) ).
I'd prefer a nice, easy to use socket library with data transfer helpers, I think WCF will find its niche as a webservice provider, but no more than that.
on the other hand the C# stuff moves sofastyoucan'tkeepup. LINQ to SQL is already a dead technology, MS is killing it off in favour of entity framework. C# was modified specially to have lambdas, and now dynamic typing and extension methods. What's going to come next to screw with the original 'nice design'? You know that its going to go wrong sooner or later - just think of the projects you've worked on where the customer or tech lead insisted on adding all kinds of stuff in knee-jerk reactions to the latest problem. MS is doing just the same here.
C/C++ being slow is a good thing compared to the alternative. When you consider something like "c++ unstable" (ie boost) then you get the best solution you're likely to ever get in the real world.
indexing.
whilst you can get a decent performance from querying a DB because its designed to be used like that, applying the same principles to an in-memory collection is not always going to be the best choice, in fact is probably always going to be a really bad choice.
Its like choosing a list structure for your random access needs, so just be aware that what is easy for you to code up doesn't mean its the best solution for your users.
yeah, but it works shit with Oracle, DB2, MySQL and PostgreSql.
Way to go to lock yourself in to a single DB provider. Oh hang on a moment....
generally the real reason its less complicated on .NET is because of Visual Studio. I had the pleasure of maintaining some VB.NET code very recently, and even with my very limited VB.NET skills (this was my first vb.net app!) it was kinda easy.. mainly because the IDE filled everything out for me.
If I had to do it in notepad, I'd have been screwed. I'm not saying it is a good language as there was plenty of 'issues' in the class libraries I used, and it was a real PITA to remember to just forget about objects and let the GC work for me, but with the IDEs extreme help, it was pretty easy.