Android SDK - first impression



  • Came across this one today:

    A quick Google led me to this Stack Overflow post:

    So...
    This is a blatantly obvious bug that would have been detected if the person who built the installer actually tested it. Yay quality control.
    The Stack Overflow question was opened 9 months ago but the bug still hasn't been fixed. Yay for listening to user feedback.

    Google are sure doing a great job making new Android devs (i.e. me) feel confident about investing in their platform.



  • @The_Assimilator said:

    Came across this one today:

    A quick Google led me to this Stack Overflow post:

    So...
    This is a blatantly obvious bug that would have been detected if the person who built the installer actually tested it. Yay quality control.
    The Stack Overflow question was opened 9 months ago but the bug still hasn't been fixed. Yay for listening to user feedback.

    Google are sure doing a great job making new Android devs (i.e. me) feel confident about investing in their platform.

     

    At least investing in the Android platform takes no actual investment.

     



  • @Master Chief said:

    At least investing in the Android platform takes no actual investment.
    Wow, your time is free?  Must be nice to have so much of it that you can throw it around.  :)



  • @The_Assimilator said:

    The Stack Overflow question was opened 9 months ago but the bug still hasn't been fixed. Yay for listening to user feedback.

    I feel compelled to point out that SO is not by any means a user feedback channel for Google products...

     



  • It can also be found in several places at code.google.com, like here:


    That one is from December last year.



  • @Mason Wheeler said:

    I feel compelled to point out that SO is not by any means a user feedback channel for Google products...

    And yet I can spend all day there arguing with the folks who wrote Microsoft's C# compiler... and I have, by the way.



  • @The_Assimilator said:

    Came across this one today:

    A quick Google led me to this Stack Overflow post:

    I just hit the same problem the other day. I was so shocked by the solution to the problem that I completely forgot to post it here.

    Here's another WTF problem you're likely to encounter, if you're using Eclipse to launch the android emulator on Windows:

    [url]http://stackoverflow.com/questions/6603194/starting-the-android-emulator-in-sdk-tools-revision-12[/url]

    It bombs if the install path has a space in the name, such as the default location of C:\Program Files.

     



  • @hoodaticus said:

    @Mason Wheeler said:

    I feel compelled to point out that SO is not by any means a user feedback channel for Google products...

    And yet I can spend all day there arguing with the folks who wrote Microsoft's C# compiler... and I have, by the way.

    Over the internet? Using the same nick?



  • @serguey123 said:

    @hoodaticus said:

    @Mason Wheeler said:

    I feel compelled to point out that SO is not by any means a user feedback channel for Google products...

    And yet I can spend all day there arguing with the folks who wrote Microsoft's C# compiler... and I have, by the way.

    Over the internet? Using the same nick?

    Wouldn't surprise me.  Eric Lippert is all over that site.  So is Jon Skeet, but I don't know what he actually works on.  (Eric is C# compiler)


  • @Sutherlands said:

    @serguey123 said:

    @hoodaticus said:

    @Mason Wheeler said:

    I feel compelled to point out that SO is not by any means a user feedback channel for Google products...

    And yet I can spend all day there arguing with the folks who wrote Microsoft's C# compiler... and I have, by the way.

    Over the internet? Using the same nick?

    Wouldn't surprise me.  Eric Lippert is all over that site.  So is Jon Skeet, but I don't know what he actually works on.  (Eric is C# compiler)

    Hmmm, that was not.... nevermind... not an issue anymore



  • @cconroy said:

    @The_Assimilator said:

    Came across this one today:

    A quick Google led me to this Stack Overflow post:

    I just hit the same problem the other day. I was so shocked by the solution to the problem that I completely forgot to post it here.

    Here's another WTF problem you're likely to encounter, if you're using Eclipse to launch the android emulator on Windows:

    It bombs if the install path has a space in the name, such as the default location of C:\Program Files.

     

    Indeed, having to tell a program (especially a Java program) to use the MS-DOS name after 2001 is a major WTF. I experienced both of these btw.



  • @C-Octothorpe said:

    Wow, your time is free?  Must be nice to have so much of it that you can throw it around.  :)

     

    You're getting paid to download software and try to install it?  Shit, I want that job.

     



  • @Master Chief said:

    You're getting paid to download software and try to install it?  Shit, I want that job.

    If it's part of developing for the platform, [i]yes[/i]. Otherwise feel free to, I dunno, use XVI32 to bang in Java bytecode or something.



  • @nexekho said:

    @Master Chief said:
    You're getting paid to download software and try to install it?  Shit, I want that job.
    If it's part of developing for the platform, yes. Otherwise feel free to, I dunno, use XVI32 to bang in Java bytecode or something.
     

    I would certainly hope if I were hired to develop for Android (or, anything for that matter) my employer wouldn't need me to install my own SDK.



  • Because it's impossible to be self-employed or be working in a small team?



  • @nexekho said:

    Because it's impossible to be self-employed or be working in a small team?
     

    I would still hope someone made sure the SDK worked before I was hired.  All I'm saying.  If you're self employed as an Android developer and don't have an Android SDK installed, well, then you have more problems then missing an SDK.



  • @Master Chief said:

    @nexekho said:

    Because it's impossible to be self-employed or be working in a small team?
     

    I would still hope someone made sure the SDK worked before I was hired.  All I'm saying.  If you're self employed as an Android developer and don't have an Android SDK installed, well, then you have more problems then missing an SDK.

    Back when I was hired three years ago, this company didn't have any android projects. Now we do. We also have a rather horrible track record with setting up environments for customer projects; it's not uncommon for it to take a month of back-and-forth emailing and phone calls with the customer before everything builds and works correctly on the target device. Hardware-specific drivers are especially problematic, as they are almost always development versions with plenty of bugs.



  • @tdb said:

    @Master Chief said:

    @nexekho said:

    Because it's impossible to be self-employed or be working in a small team?
     

    I would still hope someone made sure the SDK worked before I was hired.  All I'm saying.  If you're self employed as an Android developer and don't have an Android SDK installed, well, then you have more problems then missing an SDK.

    Back when I was hired three years ago, this company didn't have any android projects. Now we do. We also have a rather horrible track record with setting up environments for customer projects; it's not uncommon for it to take a month of back-and-forth emailing and phone calls with the customer before everything builds and works correctly on the target device. Hardware-specific drivers are especially problematic, as they are almost always development versions with plenty of bugs.

    The Android thing is a directive from our client. They have a shitty Silverlight app running on a Windows 7 tablet and want to port it to Android tablets because the costs are lower - never mind the fact that the development costs will outweigh any savings on hardware, and regardless of the fact that:

    1. company I work for has never done dev for any sort of mobile device before
    2. client has already purchased a few dozen of the Windows tablets, so they're essentially a sunk cost, and will be wasted money if they get replaced with Android tablets
    3. app has to communicate with a very specific USB device - on Windows this is easy, but Android only supports USB from 3.1 up, less than 1% of all Android devices run 3.x, and the client hasn't even decided what 3.1 tablet they want yet
    4. Android emulator doesn't support USB devices so I have no way of knowing if the code I'm currently writing will work on an actual Android device
    5. client doesn't want us rooting their tablets, so if Android USB support turns out to be the crapshoot it's looking like and we can't get it to work, the project is dead in the water

    It's all Microsoft's fucking fault. All they needed to do at //BUILD was say that Silverlight is the bomb, but no - now the suits think it's a dead technology and want us to investigate shitty alternatives. Why did Google have to decide to use Java for their tablet platform? If they'd gone with Mono instead of being open-source hippies, .NET would have a viable presence on every platform and Java would be wonderfully dead (and that goes for Eclipse as well).



  • @The_Assimilator said:

    It's all Microsoft's fucking fault. All they needed to do at //BUILD was say that Silverlight is the bomb, but no - now the suits think it's a dead technology and want us to investigate shitty alternatives. Why did Google have to decide to use Java for their tablet platform? If they'd gone with Mono instead of being open-source hippies, .NET would have a viable presence on every platform and Java would be wonderfully dead (and that goes for Eclipse as well).


    Because .NET is not platform-independent? And likely never will be?



  • @Xyro said:

    @The_Assimilator said:

    It's all Microsoft's fucking fault. All they needed to do at //BUILD was say that Silverlight is the bomb, but no - now the suits think it's a dead technology and want us to investigate shitty alternatives. Why did Google have to decide to use Java for their tablet platform? If they'd gone with Mono instead of being open-source hippies, .NET would have a viable presence on every platform and Java would be wonderfully dead (and that goes for Eclipse as well).

    Because .NET is not platform-independent? And likely never will be?
    Define platform-independent.  Then tell how .Net doesn't fit, but first define platform-independent.


  • @Sutherlands said:

    @Xyro said:

    Because .NET is not platform-independent? And likely never will be?
    Define platform-independent.  Then tell how .Net doesn't fit, but first define platform-independent.

    @HHGG said:

    A Platform-Independent Model (PIM) in software engineering is a model of a software system or business system, that is independent of the specific technological platform used to implement it. The term platform-independent model is most frequently used in the context of the model-driven architecture approach.

    Or, by my own pet definition, "full support on platforms other than Windows and XBox". Although I think I'll have to tweak my definition to include Windows Phone now. And yes, we all know Mono exists, but yes, we also know [url=http://www.mono-project.com/Compatibility]Mono coverage isn't 100%[/url]. This is not Mono's fault.

    Also, excuse my terminology if it's not accurate. Whether or not .Net equals CLR or CLS or whatever, I am not here to debate. I only mean to say that if you develop C# code via Microsoft-approved means, it may or may not work on platforms outside of Windows. That to me doesn't sound too platform-independent.

    Here's an old(ish) debate: [url]http://forums.thedailywtf.com/forums/p/24292/252201.aspx#252201[/url]. Feel free to interject or flame or whatever. I don't really care as much as I used to, because I'm learning C# / the BLC now. :P



  • Well, I'd say that C# is different than the technology used to implement it, due to MIL.  This is the same as Java, except that Java already has interpreters for multiple platforms.  Just because Apple isn't writing a .Net interpreter doesn't mean it's not platform-independent.  As for Mono, I see one thing that doesn't map to Linux.  Other than that, how is it "not Mono's fault"?  It's an incomplete implementation. 

    What's the BLC?



  • @Sutherlands said:

    This is the same as Java, except that Java already has interpreters for multiple platforms.  Just because Apple isn't writing a .Net interpreter doesn't mean it's not platform-independent.

    That's kind of important though.

    @Sutherlands said:

    Other than that, how is it "not Mono's fault"? It's an incomplete implementation. 

    Because Microsoft isn't exactly making easy for them. Sun's own JVM runs on ton of platforms, such as several versions of Windows and Linux and the BSDs and Solaris and HP-UX and various small devices etc, and there are a ton of other JVMs out there, too, for more specialized platforms like Android. Microsoft's .Net framework runs on a couple versions of Windows and XBox. That's a pretty substantial difference. Why should this be? Because that's how Microsoft wants it.

    @Sutherlands said:

    What's the BLC?

    Among the thick fog of acronyms that accompany the waft of .Net, BLC stands for Base C... aw crap, I mixed up the letters. Sorry, that should read BCL, the [url=http://en.wikipedia.org/wiki/Base_Class_Library]Base Class Library[/url]. I mention it because the real point of a new language isn't the syntax, but the class library environment / utilities. My inner pedantic dickweed wouldn't let me just write "I'm learning C#", because that would be not quite correct. C# is easy. Learning the environment that backs it up just takes some time.

    One thing that intrigues me about the BCL is how many important classes are specific to the Microsoft implementation of .Net and outside the implementation spec. Microsoft embraced and extended themselves!



  • @Sutherlands said:

    Just because Apple isn't writing a .Net interpreter doesn't mean it's not platform-independent.
     

    It means it's platform-independent in name only.

    In other words, it's not platform-independent.



  • @dhromed said:

    It means it's platform-independent in name only.

    In other words, it's not platform-independent.

    It's exactly as platform-independent as all of W3C's shit. It's not Microsoft's fault that more implementations don't exist, and it's not Microsoft's fault that Mono is incomplete.



  • @blakeyrat said:

    it's not Microsoft's fault that Mono is incomplete.

    It just goes to show that Microsoft doesn't care about platform independence.

    If they did, they'd make, ya know, platform independent runtimes.

    Ya know, like Sun did.



  • @Xyro said:

    Because Microsoft isn't exactly making easy for them. [. . .] Because that's how Microsoft wants it.
    [Citation needed]

     



  • @Sutherlands said:

    @Xyro said:

    Because Microsoft isn't exactly making easy for them. [. . .] Because that's how Microsoft wants it.
    [Citation needed]

     

    [url=http://forums.thedailywtf.com/forums/p/24997/267478.aspx#267478]Citation right here for you.[/url]

    Also, do [url=http://stackoverflow.com/questions/3656721/is-net-platform-independent]these[/url] [url=http://social.msdn.microsoft.com/Forums/en-CA/netfxsetup/thread/23a7e257-4bae-4601-a49c-bf5ba781070e]discussions[/url] [url=http://programmers.stackexchange.com/questions/20275/mono-is-frequently-used-to-say-yes-net-is-cross-platform-how-valid-is-that-c]count[/url]? I don't think I could give you a whitepaper on it, just the state of platform independence as it stands today as evidence.

    It's difficult to argue that Microsoft wants .Net to be cross-platform when it basically isn't. The only thing that comes close to being able to say that .Net is platform-independent is Mono, and that's not a Microsoft project. So... Does Microsoft want .Net to be platform-independent or not? If it does, why doesn't it, ya know, do something about it?

    (Same apologies for the terminology. The terminological distinction between .Net and the CLI/CLR and the official Microsoft implementation versus a Mono implementation is not clear to me. What's the whole shebang called? As in, "the Java platform", except for .Net?)



  • @Xyro said:

    @Sutherlands said:

    @Xyro said:

    Because Microsoft isn't exactly making easy for them. [. . .] Because that's how Microsoft wants it.
    [Citation needed]

     

    Citation right here for you.

    Also, do these discussions count? I don't think I could give you a whitepaper on it, just the state of platform independence as it stands today as evidence.

    It's difficult to argue that Microsoft wants .Net to be cross-platform when it basically isn't. The only thing that comes close to being able to say that .Net is platform-independent is Mono, and that's not a Microsoft project. So... Does Microsoft want .Net to be platform-independent or not? If it does, why doesn't it, ya know, do something about it?

    WTF do you think those links say?  They say "it's cross-platform in the same way java is", "Mono is available to run it on other systems", and "it's cross-platform, but you should use the API for whatever your target device is (smartphone, desktop, etc)."  Are we having a terminology difference here, or something?  How are you saying that it's not cross platform and quoting those links?  And how does any of that back of the claim that Microsoft wants it that way or is making it difficult?  Your argument comes back to "it's not cross-platform because Microsoft hasn't developed other things themselves"?...


  • @Sutherlands said:

    @Xyro said:

    Citation right here for you.

    Also, do these discussions count? I don't think I could give you a whitepaper on it, just the state of platform independence as it stands today as evidence.

    It's difficult to argue that Microsoft wants .Net to be cross-platform when it basically isn't. The only thing that comes close to being able to say that .Net is platform-independent is Mono, and that's not a Microsoft project. So... Does Microsoft want .Net to be platform-independent or not? If it does, why doesn't it, ya know, do something about it?

    WTF do you think those links say?  They say "it's cross-platform in the same way java is", "Mono is available to run it on other systems", and "it's cross-platform, but you should use the API for whatever your target device is (smartphone, desktop, etc)."  Are we having a terminology difference here, or something?  How are you saying that it's not cross platform and quoting those links?  And how does any of that back of the claim that Microsoft wants it that way or is making it difficult?  Your argument comes back to "it's not cross-platform because Microsoft hasn't developed other things themselves"?...

    A technically cross-platform language isn't very useful if you have to use platform-specific libraries to do useful things with it. C and C++ are both platform-independent languages but it's possible to program in them in a very platform-dependent way. Java at least tries to be platform-independent in a useful way, although JNI offers a regrettable backdoor to introduce platform-dependent code. From what I've gathered Microsoft encourages using Windows-specific APIs on .NET, effectively hampering the portability of .NET programs. I'm also under the impression that Microsoft has not made specs available for all parts of .NET, nor have they released their testing tools to the public to enable other implementations to verify their correctness.



  • @tdb said:

    Java at least tries to be platform-independent in a useful way,

    It might try, but boy does it fail.

    @tdb said:

    From what I've gathered Microsoft encourages using Windows-specific APIs on .NET,

    Which ones? Gathered where? Any facts here?



  • @Master Chief said:

    I would still hope someone made sure the SDK worked before I was hired.  All I'm saying.  If you're self employed as an Android developer and aren't able to install an Android SDK yourself, well, then you have more problems then missing an SDK.

    FTFY.




  • Just be glad you don't have to work with a language that's the disfigured child of a Java lover and someone who likes VB, complete with mix-and-match curly brace and word syntax and a parser that's as stable as a house of cards in a metreon cascade. What's that? A space after the closing bracket of a for loop? COMPILER DEATH. A space between class and equals? COMPILER DEATH.



  • @tdb said:

    C and C++ are both platform-independent languages but it's possible to program in them in a very platform-dependent way.
    Wha?



  • @tdb said:

    A technically cross-platform language isn't very useful if you have to use platform-specific libraries to do useful things with it.

    The vast majority of C# and Java apps use no native code excplicitly, and surprisingly enough they are generally useful. Funny that.

    @tdb said:

    Java at least tries to be platform-independent in a useful way, although JNI offers a regrettable backdoor to introduce platform-dependent code.

    What does "platform-independent in a useful way" even mean?

    @tdb said:

    From what I've gathered Microsoft encourages using Windows-specific APIs on .NET, effectively hampering the portability of .NET programs.

    Unlike Sun, Microsoft understands that there are valid scenarios when you need to invoke native code, and hence they don't force you to make the equivalent of a blood sacrifice when you need to do this. That's not encouragement, it's realism.

    @tdb said:

    I'm also under the impression that Microsoft has not made specs available for all parts of .NET

    C# is an ECMA-standardised language. Every installation of Visual Studio includes a copy of that ECMA standard, or you can just download it.

    @tdb said:

    nor have they released their testing tools to the public to enable other implementations to verify their correctness.

    Because other implementors can test against the ECMA spec. If their code does what the spec says, their implementation is correct.

    Seriously, you Microsoft haters should at least get the facts before you start frothing at the mouth. It would at least allow you to present credible arguments.



  • @The_Assimilator said:

    What does "platform-independent in a useful way" even mean?
     

    Copy the .jar from your Windows 7 box to your Ubuntu box and then it works.

    I haven't done any Java so I don't know if that's A) the ideal; or B) only true for simple java programs. In any case, java software (not a simple program) such as Minecraft requires that you download the platform-specific executable, but I guess the jar files it generates/downloads are completely generic.

    So I guess that it's "kinda" "platform-independent in a useful way"?



  • @Sutherlands said:

    @Xyro said:

    Also, do these discussions count? I don't think I could give you a whitepaper on it, just the state of platform independence as it stands today as evidence.


    WTF do you think those links say?  They say "it's cross-platform in the same way java is", "Mono is available to run it on other systems", and "it's cross-platform, but you should use the API for whatever your target device is (smartphone, desktop, etc)."  Are we having a terminology difference here, or something?

    these: .Net is independent in as so far as the CLR is portable. But unlike the JVM, all we've got is the official MS implementation and Mono, which is not 100% compatible nor as available as the JVM.

    discussions: Microsoft poster is providing as a convenience to us a link to Mono (which is not 100% compatible nor as available as the JVM).

    count: Holy cow, look at that matrix of compatibilities!!! I guess one could argue that it's sane and sensible that certain platforms/profiles should include or exclude certain APIs, but wow look at that.

    If you consider that platform independent, then yes, we do have a terminology gap.

    @dhromed said:

    @The_Assimilator said:

    What does "platform-independent in a useful way" even mean?
     

    Copy the .jar from your Windows 7 box to your Ubuntu box and then it works.

    I haven't done any Java so I don't know if that's A) the ideal; or B) only true for simple java programs. In any case, java software (not a simple program) such as Minecraft requires that you download the platform-specific executable, but I guess the jar files it generates/downloads are completely generic.

    So I guess that it's "kinda" "platform-independent in a useful way"?


    Yeah, like that. Unless that Java program has JNI dependencies, which is very uncommon (Minecraft: probably due to OpenGL libraries or similar?), copying over the .jar files is enough to switch (hardware/OS) platforms. Nothing more needed. I develop, compile, and test complex Java programs on my company-supplied Windows computers, then deploy them to HP-UX (and occasionally Solaris) servers as-is. THAT is platform independence.



  • @Xyro said:

    Yeah, like that. Unless that Java program has JNI dependencies, which is very uncommon (Minecraft: probably due to OpenGL libraries or similar?), copying over the .jar files is enough to switch (hardware/OS) platforms. Nothing more needed. I develop, compile, and test complex Java programs on my company-supplied Windows computers, then deploy them to HP-UX (and occasionally Solaris) servers as-is. THAT is platform independence.
     

    If there's an Android JVM, does the .jar work there as well?

    Otherwise it's platform-independence for desktop platforms only.

    If I build a merry programme in VS, and simply copy the resultant .dll to any random Mac, does it work, assuming the Mac has Mono installed?



  • @The_Assimilator said:

    @tdb said:
    I'm also under the impression that Microsoft has not made specs available for all parts of .NET

    C# is an ECMA-standardised language. Every installation of Visual Studio includes a copy of that ECMA standard, or you can just download it.

    @tdb said:

    nor have they released their testing tools to the public to enable other implementations to verify their correctness.

    Because other implementors can test against the ECMA spec. If their code does what the spec says, their implementation is correct.

    Seriously, you Microsoft haters should at least get the facts before you start frothing at the mouth. It would at least allow you to present credible arguments.

     

    It is perhaps worth noting that the ECMA spec doesn't cover the most recent version of C#, or the one before that. It's not really true to say that C# is an ECMA-standardised language: you should say that C# 2.0 is an ECMA-standardised language.



  • @dhromed said:

    If there's an Android JVM, does the .jar work there as well?

    Otherwise it's platform-independence for desktop platforms only.


    In order to call itself a JVM, the answer is yes. If it doesn't, then it's in violation of the official spec test suite thing and then lawyers can start making growling sounds.

    However, I am not certain if Android has a real spec-test-passing JVM or not... I remember a year or two ago there was some clamor about Google using parts of Java but not implementing the full Java platform, and that got some folks upset. Was that before Sun got Oracled? I don't remember any of the details nor know the current state of things. Anyone want to fill me in? I don't feel like a full Google hunt right now, and all I'm finding are old (2007-2009ish) articles about it, so I'm not sure...



  • @dhromed said:

    @The_Assimilator said:
    What does "platform-independent in a useful way" even mean?
    Copy the .jar from your Windows 7 box to your Ubuntu box and then it works.

    Not if there's a GUI. The funny thing about Java is that you can't create a working GUI even if you never cross platforms.



  • @Xyro said:

    However, I am not certain if Android has a real spec-test-passing JVM or not... I remember a year or two ago there was some clamor about Google using parts of Java but not implementing the full Java platform, and that got some folks upset. Was that before Sun got Oracled? I don't remember any of the details nor know the current state of things. Anyone want to fill me in? I don't feel like a full Google hunt right now, and all I'm finding are old (2007-2009ish) articles about it, so I'm not sure...
     

    Android compiles Java to a custom bytecode for a VM called Dalvik. Whether there's a JVM as well, I'm not sure.

     @blakeyrat said:

    Not if there's a GUI. The funny thing about Java is that you can't create a working GUI even if you never cross platforms.
     

    I can, but then unlike you I don't hate Java so much that I couldn't be bothered to learn how to use it. FWIW, vanilla Swing has far better layout managers than vanilla System.Windows.Forms.



  • @pjt33 said:

    I can, but then unlike you I don't hate Java so much that I couldn't be bothered to learn how to use it.

    If you have to "learn" how to use a Java GUI separately from how to use a Windows, or OS X, or whatever UI... then it's already failed. And failed hard.

    I hate Java because Java products have shitty UIs. My hatred doesn't cause the shittiness, it's the result of it.

    @pjt33 said:

    FWIW, vanilla Swing has far better layout managers than vanilla System.Windows.Forms.

    And yet the result is always shit. So maybe a better layout manager isn't the solution to this particular problem, eh?



  • @blakeyrat said:

    @pjt33 said:
    I can, but then unlike you I don't hate Java so much that I couldn't be bothered to learn how to use it.

    If you have to "learn" how to use a Java GUI separately from how to use a Windows, or OS X, or whatever UI... then it's already failed. And failed hard.

     

    Misparsed: "learn how to use Java" was the meaning.

     



  •  Hey, I like Minecraft's UI.



  • @Zylon said:

    Hey, I like Minecraft's UI.

    BUT IT DOESN'T USE NATIVE WIDGETS!!!! >:O >:O >:O



  • @Sutherlands said:

    @tdb said:

    C and C++ are both platform-independent languages but it's possible to program in them in a very platform-dependent way.
    Wha?

    Nearly every platform out there has support for programs written in the C language, and basic programs using only the standard library will work on every one of them (albeit some platforms, such as microcontrollers, may lack input/output facilities). The standard is even intentionally written in a way that makes it possible to make a conforming implementation on very unconventional and obscure platforms. Yet every platform also tends to have its own set of APIs for that same language that don't exist on any other platforms. WinAPI in is available only on Windows, and every flavour of *nix kernel has a set of system calls not available in any other flavour. Thus: platform-independent language, platform-dependent APIs.



  • @The_Assimilator said:

    @tdb said:
    A technically cross-platform language isn't very useful if you have to use platform-specific libraries to do useful things with it.

    The vast majority of C# and Java apps use no native code excplicitly, and surprisingly enough they are generally useful. Funny that.

    Even if the application itself doesn't contain any native code, how can you know the libraries it uses do not?

    @The_Assimilator said:

    @tdb said:
    Java at least tries to be platform-independent in a useful way, although JNI offers a regrettable backdoor to introduce platform-dependent code.

    What does "platform-independent in a useful way" even mean?

    That it isn't a wrapper around a platform-specific API for one thing. It also helps to provide open specs for all parts of the environment and not just the core (see below).

    @The_Assimilator said:

    @tdb said:
    I'm also under the impression that Microsoft has not made specs available for all parts of .NET

    C# is an ECMA-standardised language. Every installation of Visual Studio includes a copy of that ECMA standard, or you can just download it.

    Which of these ECMA standardized namespaces allows me to write GUI code in C#? Or do anything with audio/video files without having to write my own codecs?

    @The_Assimilator said:

    @tdb said:
    nor have they released their testing tools to the public to enable other implementations to verify their correctness.

    Because other implementors can test against the ECMA spec. If their code does what the spec says, their implementation is correct.

    That's unfortunately not possible for the non-standard parts. It seems that I was thinking of Silverlight/Moonlight with the testing tools.



  • @blakeyrat said:

    @pjt33 said:
    FWIW, vanilla Swing has far better layout managers than vanilla System.Windows.Forms.

    And yet the result is always shit. So maybe a better layout manager isn't the solution to this particular problem, eh?


    Are you sure you're not just a victim of Spurgeon's law? (And note that I said Swing has better layout managers. I've no idea whether the people who wrote the apps you've encountered used them).

    @tdb said:

    Nearly every platform out there has support for programs written in the C language, and basic programs using only the standard library will work on every one of them (albeit some platforms, such as microcontrollers, may lack input/output facilities).

    Only with suitable platform-specific #ifdefs to get integer types which are guaranteed to be the width you want, surely?



  • @pjt33 said:

    @tdb said:
    Nearly every platform out there has support for programs written in the C language, and basic programs using only the standard library will work on every one of them (albeit some platforms, such as microcontrollers, may lack input/output facilities).

    Only with suitable platform-specific #ifdefs to get integer types which are guaranteed to be the width you want, surely?

    Those are only needed if you constrain yourself to C89. C99 has stdint.h which provides fixed-size integer types. Unfortunately Microsoft's compiler doesn't support C99 (and I recall hearing it never will), but there are several alternative compilers for Windows.

    AFAIK the standard also specifies certain minimum sizes for integer types, so if you don't care about the exact size, you can get types that are large enough (but may be larger) even in C89.


Log in to reply