Interesting you know about odd, unpopular languages like Haskell but don't even know about GCJ, which would address your issue (6). The Oracle JVM is not the only JVM in existence. Plus, apart from start-up time (inconsequential on servers) the JIT generally produces faster code than AOT since superior optimisation information is available to a JIT instead of a AOT compiler. Even on the desktop these days were the JVM is pre-loaded by the OS the start-up time is not that long, and becomes increasingly insignificant as you move away from small programs to large programs (hell, MS Word takes forever to load on a clean reboot and that it written in C++).
As for (2). You don't need to have a generic instance of a primitive type. The JVM is smart enough to 'autobox' this for you (a nice feature Java stole from C#) with the resulting effect that you essentially get the generic class using primitive type and the resulting performance gain. Nice to have such things happen under the hood.
Strange you also would like to use goto. Even in 1968 Dijkstra considered this harmful in a famous paper - so generally anyone wanting to use this is considered slightly deranged, there are alternatives that are much more maintanable. So railing against Java for a construct that the consensus considers bad form could also be seen as bad form (or an unawareness of just how bad designs that need goto are).
Also, Java does provide labeled statements, and goto is reserved but not used. You can use the label to continue in a loop with a similar effect to goto - although as a said before, this is not encouraged by the consensus since usually the use of such a construct is considered 'harmful' to good development practices.
It's kinda amusing that you cherry pick the best features from a slew of languages and indicate that Java can't hold it's own against half-a-dozen languages at once, yet each of those languages blow when compared to Java one-on-one. That's pretty typical for the kind of academic language snobbery you get around here. When you start building *huge* systems you realise that the 'toy' languages you mention aren't really that good for developing in the large - plus they are good for specific problems and aren't really that well suited as a general purpose solutions that you are going to invest significant financial and developmental resources into (that is, build a business with many collaborating people that simply can't chose a new language du jour for their clients). The strengths of those alternative languages (and they have some for sure) become their weaknesses when solving the problems of scale and development continuity in the real world (that is, some of the nifty languages features actual hinder *getting real things done* - which is what really matters).
Actually, re-using objects is an excellent strategy if you are using JavaBeans (where you have symmetric getters and setters). Unfortunately, so many programmers hide setters away from you, supposedly to protect you from yourself, but it makes it impossible to re-use objects even where it would otherwise not only be perfectly possible and valid but also very efficient as well. In short, use JavaBeans when you need complex (non-intrinsic) value-objects and make the setters symmetric with the getters, *always*. You don't generally need to work pools of objects if you can re-use a JavaBean directly. Immutable objects have their uses, but they are very expensive in many performance-critical situations. If an object doesn't have to be immutable, don't make it so (keep it a Plain Old Java Object [POJO] where you can).
Although if you do need pooling (and you do from time to time) then Apache Commons Pool has done all the work for you. Real-life example, I worked on an Internet-scale project where the cost of obtaining a java.util.Calendar was too expensive (since it internally gets a timezone) and affected a critical part of very heavily used code. Pooling instances was very helpful in keeping high performance.
As always with performance you ought to be profiling your code before optimizing. Fortunately the Java SDKs come with JVisualVM which is absolutely fantastic - you don't need to compile a special profiling version of your program (like C or C++) you can simply attach to *any* running Java process and see what it is up to. You can even do this to remote processes (although you get slightly less information than if you hook up to a local process). This is an unbelievably good feature that allows you to optimize your Java sensibly - which should result in code at least as fast as C if you know what you are doing.
Once you have done your profiling with JVisualVM you can figure out what you need to do next:
Am I doing a lot of string concatenation (eg. text or XML processing)? then changing one or two Strings to StringBuffers can often give you a factor of 10 speedup in critical code (I've done this myself)
If you are creating a lot of objects then having a fully mutable JavaBean can help (I've done this with a Matrix class - which saved re-initialising the identity matrix a lot).
If you are CPU bound then how about splitting your working into multiple threads? Much easier than doing multithreading in C or C++
Still don't have enough CPU power? cool, you're in Java so move your application from a little Windows box onto a Linux/Unix huge blade server.
are you multi-threaded but lock contention for shared resources holding you back? then get rid of that fancy shared singleton and use non-shared POJO objects in each thread to hold what would otherwise be shared state.
Running out of memory and is the GC thrashing? simple, just give your application more memory with the -Xmx JVM parameter.
Doing a lot of iteration over lists or arrays to find things? then create a java.util.Map to cache lookup data.
These are all simple fixes that can make Java very fast. JVisualVM will help you make the decision about where to start.
Of course, the classic paper discussing how fast the JVM had got even 4 years ago from the French supercomputing research arm of INRIA: https://blogs.oracle.com/jag/entry/current_state_of_java_for
If anyone still thinks the JVM is slow then they are out-of-date. As long as your developers are competent you can make Java applications very fast.
Bugger. I had modded a bunch of posts on this thread and now have to chuck them away just to counter your ignorance (lest your incorrect assumption spread to others). It's cool you are taking a stab at why Java might limit memory, but unfortunately that guess is not correct - so I hope to set yourself (and any other readers) straight on why Java has this feature (if you don't understand the feature you'll see it as a limitation, when in fact it is very important for security).
The limit Java imposes on memory is to ensure that critical resources (memory) is preserved for the system - and gives the Java user a way to limit what any application can do. This is a very important protection if you followed Java's internet model where Applets (or these days, WebStart applications) and allow remote applications to run. System administrators can also partition what any application can do, in case one is rogue (they can't trust those damn application developers, like me) and uses up all the system memory shared between many applications when running on Big Iron. I don't know whether any remote running.NET applications have this protection and would be interested to hear if they do - if they don't then that means any.NET application could in theory bring your server (and all the other important services you have running on it) to a crawl (as it swaps memory) or possibly even crash through memory exhaustion.
> The problem is though many - I'm certain the vast majority of business actually just use Windows systems and in this circumstance it becomes harder to justify Java
Businesses certainly use Windows on the desktop. However, very few of them develop Windows applications anymore (they used to, but that has decreased somewhat). Most (by number of projects) *new* development is targeted for the Web - at least for the government departments and multi-nationals I get to develop for. There are a few exceptions to this for specialized applications, but these are hardly ever for Windows only (some hardware controlling embedded systems, some multi-platform apps). In this case the servers may or may not be Windows (the largest outfits have all kinds of hardware, with the larger server farms generally being non-Windows since the economics is against it when you have a lot of servers).
So while I understand the things in C# that make you like it out in the real world it is the Web that is taking over. In this case the Google Web Toolkit is pretty much best of breed at the moment (Microsoft's Project Volta seems to be stalled) - yep, doing raw Javascript (even with JQuery) or PHP is an insane way to develop, I completely agree with you there. For mobile apps Android (which is Java on Linux) is making inroads - although contract work for that is still reasonably rare. Enjoy the C#, but make sure you also get a lot of experience in Java too. Like I said, the world is moving to being more heterogenous rather than less and getting pigeonholed gives you less power to negotiate your contract rate.
> The OS isn't the revenue generating part of Android.
The OS isn't the *direct* revenue part of Android. People don't think they are paying for the OS. However, without the OS you would have hardware with nothing running on it. Just because they don't charge for the Linux or Java (customized versions of which compromise the marketing name, "Android") doesn't mean they don't have value to Google. The OS is very valuable to Google, without an OS they would not make money on this product. Please don't confuse not charging for something directly with not generating revenue from it.
Thanks for your post. I'll take your points on board.
C# certainly is a nice language and has its merits for sure. However, my apparent fanboyism comes from me repeatedly trying to point out what the pro.NET crowd apparently fail to grok. My apologies if this irritates you personally, that was certainly not my intention.
What I do try an point out that many of the supposed tactical advantages of C# over Java are not actually advantages once you take a strategic perspective. Just as the power of C is that fact they kept the language simple and put the power in the libraries, the same is true of Java. For example, LINQ is nice, but IMHO JPA is better and simpler in some regards. Also in this case rather than pollute 'Java the language' with constructs ala LINQ instead a nice standardized library has been provided instead (known as JPA, which has an implementation called Hibernate EntitieManager). By not putting database constructs in the Java language itself it means that if you are developing tiny embedded systems (as I have done) you can compile Java down to virtually nothing (using something like GCJ). Using standardized libraries to extend itself, not additional language constructs, makes more sense as a general solution, IMHO. In addition, you can (and I have) use Java on a huge *heterogenous* network of however many thousand machines you have available. This would be useful for your mathematical work (just as it was useful when I was doing astrophysics research). This is something that.NET cannot match (work flawlessly in a heterogenous environment). Yet the best argument I hear for C# is that some feature makes up for these strategic shortcomings of the.NET platform (please don't mention Mono, I've taken a hard look at it and its library coverage has severe shortcomings). I have also done enough.NET development to know that it is excellent if you are (only) developing Windows desktop applications or webapps hosted by Windows. However, if you choose Java not only can you do a good job developing for the platforms.NET covers (with the deliberate exception of the XBox - 'thanks' Ballmer) you also have the strategic flexibility to move your code (which is an investment in time and money) elsewhere as the computing universe changes (and hasn't it been changing *a lot* lately?). Therefore, I try to point out these issues in this forum - unfortunately given the semi-anonymous nature of the forums it means the same crap gets repeated both ways.
I can see definite advantages in the C# language - I don't deny it has some. What I do try to point out is that some of these advantages are actually illusory when you are designing (aka 'architecting' - although is a non-word) for the very big, very small or even medium scale systems. IMHO if you are only looking at language/keyword advantages then you are unfortunately not looking at the both the big picture and the future (that is, the things that actually matter) - which is all too common among developers unfortunataly. That'll put you well past the "2%" of developers. So when I hear someone think that because I like simplicity over more complexity and therefore I must be an unskilled developer I have a chuckle - to me it means the person talking to me is not thoroughly considering a great deal of factors that are outside the actual keystrokes used to build a system with a particular technology (I'm sure this sounds arrogant, it is not meant to be, it is just meant to be an observation from past dealings). Oh, and one more thing, in some ways C# does produce smaller and cleaner code than Java (but IMHO that is kinda countered by non-standard project.NET structures where stuff is squirreled all over the place; what seems like a straightjacket in Java is actually the only way to keep a multi-thousand class project sane) but how I've actually seen it used in practice they are both on-par in how ordinary devs produce awful code.
That works for 'coarse' level stuff. Where documentation is *essential* is when you are trying to write correct and robust software.
In that case you need to consult the documentation to determine what a method's preconditions are, what it'll throw if they're not met (documentation is much better for describing runtime exception than an exception qualifier on the method signature, especially as this doesn't force you to cope with the exception, but the documentation says what gets thrown and more importantly, why). You cannot be a good developer if you are not always thinking about what can go wrong with the software you are using or writing. Not documenting it for your maintainers (including yourself in a few years) is not the mark of a professional (although many devs that consider themselves "pros" haven't yet grokked just how important writing quality docs is - and with things like JavaDoc is is easy to keep consistent as you code).
You also need to consult documentation when you need to consider different units of measure. Is your time in milliseconds? seconds? years? is it UTC? local time? NTP time? what about your masses? lengths? currency units? I know that it never enters the heads of most developers to think about the units they are using, and they also never think that it is worth documenting. But if you want reliable software you need to document it (if you don't want to start using horrible classes that carry around units with them - although that is possible it is very inconvenient for most cases). Units matter, you'll lose your Mars probe if you screw it up (Google it), or calculate the wrong interest amount, or place objects on the wrong place on the map, or schedule a meeting after it has happened, etc.
Documentation (and units!) matter. Unfortunately, as I said, many people think they are excellent coders but they can't be bother to write, read, or maintain useful in-code documentation. I hate using their code and are never surprised when it fails (since they haven't said how to use it correctly or what can kill it).
So if the helmets don't actually stop such trauma (which your statement asserts implicitly) then the logical conclusion is that perhaps the bikes should be banned? The parent poster was alluding to how ridiculous the defensive culture is becoming, and which you apparently subscribe too (based on your statement). If you accept that injuries will always happen yet the trend for protection is starting to outweigh the pleasure of the activity and the *actual* observed risk of injury then perhaps his levity doesn't require such a defensive retort.
Ask not only for his information, but for all the personal information for his wife and children - including the ones from outside his marriage. Then ask whether he still thinks it is a good idea.
Yes, it is nice to work with interfaces. No, you shouldn't care whether you are dealing with an interface or a concrete class. Hence, prepending "I" to interfaces is a bad idea. For example, the Java equivalent for writing (internationalized) text streams is "Writer", you don't care if it is a "FileWriter", "StringWriter", "OutputStreamWriter" etc. Note that it is called "Writer" (a word that makes perfect sense) and not "IWriter" (made up computer jargon). So my argument was not against using interfaces, it was against naming those interfaces in an artificial, and these days unnecessary, manner.
Yes, and soon C# will be as "easy" as C++:) I'm not saying progress is bad, but it has to be weighed against complexity. Personally I'd rather write a few more lines of blindingly clear explicit code that less skilled developers can easily follow than using more fewer lines of implicit code. Just because we're smart enough to deal with complex code doesn't mean everyone is - on large projects you just can't get enough devs that are as skilled as you and I. Anyone can write few lines of "obfuscated C", the wise realise that it is not the number of lines that matter, it is complexity, implicitness and in-obviousness that makes maintenance hard. To repeat a famous mis-quote of Einstein, things should be "as simple as possible, but no simpler". Java has this goal in mind, it is pretty clear that C# does not.
I think you miss the point. The point is that prepending a class or variable name is no longer necessary. You're just so used to it that you can't see how hideous prepending interfaces with "I" is. One day you'll move away from the habit and laugh at how silly a style it all was (just as you probably laugh now at C-type Hungarian Notation).
This is an old-style way of looking at it. I also used to think they would be helpful but now consider them obscuring, you are still thinking in the solution domain rather than trying to get to the problem domain (so that the code reads more like natural language). These days your IDE can tell you the type without you having to pollute your code with these 'warts'. This is why many languages have moved away from such styles. The reason C# has it is that the developers are unable to shake the legacy modes of thought. It turns out that rather than use these artificial constructs to make it easier for following developers it is generally better to aim to make your language simpler. For example, Java is often panned by.NET developers for not having certain constructs but it is a deliberate decision by the Java architects to *keep* the language simple. As a result there are far fewer deprecated constructs and styles in the language. This has a far greater impact on improving code readability for people joining or maintaining a project than using kinda crufty old-style constructs to do this. But yes, I agree with you that consistency is important.
Yeah, the "understated" UIs look great but are actually poorly designed from a usability perspective.
Example: Last week I bought an iPhone 4S and couldn't figure out how to make a call. I went to "Phone" where I had contacts and was presented with buttons for doing Face Time, sending messages, sharing contacts, and adding a contact to favorites, but there was no button to make a call. I mean, given that choosing the Phone app means you will want to make a call on a selected contact about 95% of the time you would think there would be a massive "Call" icon, since that is the most common thing you'd like to do. It turns out you have to tap on the phone number to make the call - even though there is absolutely nothing to indicate that tapping the number would make a call (my expectation was that tapping the number would edit it). Now that I know that all the interface elements are clickable "buttons" *even if they don't look like the buttons shown elsewhere* things are much easier (and this is coming from a long-time user of Macs). While many of the UI features of Apple are excellent I consider their minimalist approach has gone so far as to present too little information. My point here is that while we are decrying Microsoft for their UI designs we can also do the same for Apple. Mostly less is more, but sometimes less really is less. One of my hats is a trained technical writer and from that point-of-view I consider some elements of Apple's style to be very, very bad - but that is not a particularly fashionable point of view at the moment.
The C# standard library uses the prefix "I" for interface classes. This is something you don't see in Java (despite C# being derived directly from Java via the intermediate research language "Cool"). So yeah, a stake has not yet been put through the heart of Hungarian Notation yet.
That may be a good reason. The real reason for the rise of Hungarian Notation is that the Microsoft C compiler didn't do type checking for some time after other C compilers had it. If you wanted to have a clue what type you were using you adopted Charles Simonyi's notation (which was used by FORTRAN devs at the time). The problem is, that awful practice of using 'warts' as a prefix stuck around. It even lingers in C# where interfaces are traditionally prefixed with "I". Fortunately this is something that Java conventions avoid - and if you decide to change an interface into a concrete class during development you don't have to go around and rename everything (plus, such prefixes are unnecessary in the modern age, the compiler helps you when you mistake an interface for a concrete class, so the 'wart' has no upside while having the refactoring downside).
Yeah. When going through officer school of our Air Force we were taught our military law and there was a charge "Conduct prejudicial to service discipline" that could be used to apply to anything. You'd be pretty hard pressed to defend against this.
The problem is that most humans expect someone else to give them a purpose. Only a few folks figure out that they can set their own purpose and move to it. Some of the English are particularly good at this - deciding they want to collect butterflies, or stamps, or walk all the lanes in the country. Americans don't seem to be as good at this (deriving purpose from simple pleasures) from what I have seen - but of course I'm generalizing here. My point is that the billions of idle hands are trouble only because people can't set their own purpose - but if they could then the world would be an excellent place for the most part. Golovachev has an interesting, if myopic view.
Christianity also had many reform figures, most of who were dispatched as heretics just as in the Muslim world. What made "Martin Luther" special is that he was *accepted* by a majority in a large area. To my knowledge there has been no reformer that has been as widely accepted in the Muslim world as Luther was in the Christendom. This is why there has been no-one accepted as "Luther", despite all the Muslim reformers there have been. One interesting thing is that Luther's views are actually more fundamentalist, but the fundamentals of Christ's teachings emphasize tolerance and forgiveness over the strict interpretation of the Mosaic Law. My understanding of the Islam has the emphasis the other way around. Islam does preach tolerance etc but my understanding is this is secondary to upholding the laws.
In from New Zealand. I hope we would have taken him (probably would have too). He should have passed through Singapore instead (they have no love for Malaysia). Typical modern journalist, not checking his facts. lol.
> But with all the international uproar about this case probably Saudis will get a slap on the wrist. Interpol cannot allow itself to be dragged into religious wars.
By passing the warrant on that is precisely what they did. They did not have to pass the warrant on if it contravened their charter - but they did (probably because they were too lazy to figure out the ramifications - most cops are useless in that regard). Hopefully Interpol will learn from this scandal - otherwise they are aiding and abetting actions that go against their own charter.
Yes. Malaysia used to have famously tolerant Muslims. Unfortunately Saudi has been exporting Wahhabi clerics (in addition to the oil) that have a unique tribal interpretation of things - it is this mostly sect that is dangerously radicalizing Muslims today, including in Malaysia.
Slashdot Mirror
Please elaborate how this affects the "Write once run anywhere". I'm afraid I don't quite get what you mean. Thanks.
Interesting you know about odd, unpopular languages like Haskell but don't even know about GCJ, which would address your issue (6). The Oracle JVM is not the only JVM in existence. Plus, apart from start-up time (inconsequential on servers) the JIT generally produces faster code than AOT since superior optimisation information is available to a JIT instead of a AOT compiler. Even on the desktop these days were the JVM is pre-loaded by the OS the start-up time is not that long, and becomes increasingly insignificant as you move away from small programs to large programs (hell, MS Word takes forever to load on a clean reboot and that it written in C++).
As for (2). You don't need to have a generic instance of a primitive type. The JVM is smart enough to 'autobox' this for you (a nice feature Java stole from C#) with the resulting effect that you essentially get the generic class using primitive type and the resulting performance gain. Nice to have such things happen under the hood.
Strange you also would like to use goto. Even in 1968 Dijkstra considered this harmful in a famous paper - so generally anyone wanting to use this is considered slightly deranged, there are alternatives that are much more maintanable. So railing against Java for a construct that the consensus considers bad form could also be seen as bad form (or an unawareness of just how bad designs that need goto are).
Also, Java does provide labeled statements, and goto is reserved but not used. You can use the label to continue in a loop with a similar effect to goto - although as a said before, this is not encouraged by the consensus since usually the use of such a construct is considered 'harmful' to good development practices.
It's kinda amusing that you cherry pick the best features from a slew of languages and indicate that Java can't hold it's own against half-a-dozen languages at once, yet each of those languages blow when compared to Java one-on-one. That's pretty typical for the kind of academic language snobbery you get around here. When you start building *huge* systems you realise that the 'toy' languages you mention aren't really that good for developing in the large - plus they are good for specific problems and aren't really that well suited as a general purpose solutions that you are going to invest significant financial and developmental resources into (that is, build a business with many collaborating people that simply can't chose a new language du jour for their clients). The strengths of those alternative languages (and they have some for sure) become their weaknesses when solving the problems of scale and development continuity in the real world (that is, some of the nifty languages features actual hinder *getting real things done* - which is what really matters).
Actually, re-using objects is an excellent strategy if you are using JavaBeans (where you have symmetric getters and setters). Unfortunately, so many programmers hide setters away from you, supposedly to protect you from yourself, but it makes it impossible to re-use objects even where it would otherwise not only be perfectly possible and valid but also very efficient as well. In short, use JavaBeans when you need complex (non-intrinsic) value-objects and make the setters symmetric with the getters, *always*. You don't generally need to work pools of objects if you can re-use a JavaBean directly. Immutable objects have their uses, but they are very expensive in many performance-critical situations. If an object doesn't have to be immutable, don't make it so (keep it a Plain Old Java Object [POJO] where you can).
Although if you do need pooling (and you do from time to time) then Apache Commons Pool has done all the work for you. Real-life example, I worked on an Internet-scale project where the cost of obtaining a java.util.Calendar was too expensive (since it internally gets a timezone) and affected a critical part of very heavily used code. Pooling instances was very helpful in keeping high performance.
As always with performance you ought to be profiling your code before optimizing. Fortunately the Java SDKs come with JVisualVM which is absolutely fantastic - you don't need to compile a special profiling version of your program (like C or C++) you can simply attach to *any* running Java process and see what it is up to. You can even do this to remote processes (although you get slightly less information than if you hook up to a local process). This is an unbelievably good feature that allows you to optimize your Java sensibly - which should result in code at least as fast as C if you know what you are doing.
Once you have done your profiling with JVisualVM you can figure out what you need to do next:
Am I doing a lot of string concatenation (eg. text or XML processing)? then changing one or two Strings to StringBuffers can often give you a factor of 10 speedup in critical code (I've done this myself)
If you are creating a lot of objects then having a fully mutable JavaBean can help (I've done this with a Matrix class - which saved re-initialising the identity matrix a lot).
If you are CPU bound then how about splitting your working into multiple threads? Much easier than doing multithreading in C or C++
Still don't have enough CPU power? cool, you're in Java so move your application from a little Windows box onto a Linux/Unix huge blade server.
are you multi-threaded but lock contention for shared resources holding you back? then get rid of that fancy shared singleton and use non-shared POJO objects in each thread to hold what would otherwise be shared state.
Running out of memory and is the GC thrashing? simple, just give your application more memory with the -Xmx JVM parameter.
Doing a lot of iteration over lists or arrays to find things? then create a java.util.Map to cache lookup data.
These are all simple fixes that can make Java very fast. JVisualVM will help you make the decision about where to start.
Of course, the classic paper discussing how fast the JVM had got even 4 years ago from the French supercomputing research arm of INRIA:
https://blogs.oracle.com/jag/entry/current_state_of_java_for
If anyone still thinks the JVM is slow then they are out-of-date. As long as your developers are competent you can make Java applications very fast.
Bugger. I had modded a bunch of posts on this thread and now have to chuck them away just to counter your ignorance (lest your incorrect assumption spread to others). It's cool you are taking a stab at why Java might limit memory, but unfortunately that guess is not correct - so I hope to set yourself (and any other readers) straight on why Java has this feature (if you don't understand the feature you'll see it as a limitation, when in fact it is very important for security).
The limit Java imposes on memory is to ensure that critical resources (memory) is preserved for the system - and gives the Java user a way to limit what any application can do. This is a very important protection if you followed Java's internet model where Applets (or these days, WebStart applications) and allow remote applications to run. System administrators can also partition what any application can do, in case one is rogue (they can't trust those damn application developers, like me) and uses up all the system memory shared between many applications when running on Big Iron. I don't know whether any remote running .NET applications have this protection and would be interested to hear if they do - if they don't then that means any .NET application could in theory bring your server (and all the other important services you have running on it) to a crawl (as it swaps memory) or possibly even crash through memory exhaustion.
Businesses certainly use Windows on the desktop. However, very few of them develop Windows applications anymore (they used to, but that has decreased somewhat). Most (by number of projects) *new* development is targeted for the Web - at least for the government departments and multi-nationals I get to develop for. There are a few exceptions to this for specialized applications, but these are hardly ever for Windows only (some hardware controlling embedded systems, some multi-platform apps). In this case the servers may or may not be Windows (the largest outfits have all kinds of hardware, with the larger server farms generally being non-Windows since the economics is against it when you have a lot of servers).
So while I understand the things in C# that make you like it out in the real world it is the Web that is taking over. In this case the Google Web Toolkit is pretty much best of breed at the moment (Microsoft's Project Volta seems to be stalled) - yep, doing raw Javascript (even with JQuery) or PHP is an insane way to develop, I completely agree with you there. For mobile apps Android (which is Java on Linux) is making inroads - although contract work for that is still reasonably rare. Enjoy the C#, but make sure you also get a lot of experience in Java too. Like I said, the world is moving to being more heterogenous rather than less and getting pigeonholed gives you less power to negotiate your contract rate.
> The OS isn't the revenue generating part of Android.
The OS isn't the *direct* revenue part of Android. People don't think they are paying for the OS. However, without the OS you would have hardware with nothing running on it. Just because they don't charge for the Linux or Java (customized versions of which compromise the marketing name, "Android") doesn't mean they don't have value to Google. The OS is very valuable to Google, without an OS they would not make money on this product. Please don't confuse not charging for something directly with not generating revenue from it.
Thanks for your post. I'll take your points on board.
C# certainly is a nice language and has its merits for sure. However, my apparent fanboyism comes from me repeatedly trying to point out what the pro.NET crowd apparently fail to grok. My apologies if this irritates you personally, that was certainly not my intention.
What I do try an point out that many of the supposed tactical advantages of C# over Java are not actually advantages once you take a strategic perspective. Just as the power of C is that fact they kept the language simple and put the power in the libraries, the same is true of Java. For example, LINQ is nice, but IMHO JPA is better and simpler in some regards. Also in this case rather than pollute 'Java the language' with constructs ala LINQ instead a nice standardized library has been provided instead (known as JPA, which has an implementation called Hibernate EntitieManager). By not putting database constructs in the Java language itself it means that if you are developing tiny embedded systems (as I have done) you can compile Java down to virtually nothing (using something like GCJ). Using standardized libraries to extend itself, not additional language constructs, makes more sense as a general solution, IMHO. In addition, you can (and I have) use Java on a huge *heterogenous* network of however many thousand machines you have available. This would be useful for your mathematical work (just as it was useful when I was doing astrophysics research). This is something that .NET cannot match (work flawlessly in a heterogenous environment). Yet the best argument I hear for C# is that some feature makes up for these strategic shortcomings of the .NET platform (please don't mention Mono, I've taken a hard look at it and its library coverage has severe shortcomings). I have also done enough .NET development to know that it is excellent if you are (only) developing Windows desktop applications or webapps hosted by Windows. However, if you choose Java not only can you do a good job developing for the platforms .NET covers (with the deliberate exception of the XBox - 'thanks' Ballmer) you also have the strategic flexibility to move your code (which is an investment in time and money) elsewhere as the computing universe changes (and hasn't it been changing *a lot* lately?). Therefore, I try to point out these issues in this forum - unfortunately given the semi-anonymous nature of the forums it means the same crap gets repeated both ways.
I can see definite advantages in the C# language - I don't deny it has some. What I do try to point out is that some of these advantages are actually illusory when you are designing (aka 'architecting' - although is a non-word) for the very big, very small or even medium scale systems. IMHO if you are only looking at language/keyword advantages then you are unfortunately not looking at the both the big picture and the future (that is, the things that actually matter) - which is all too common among developers unfortunataly. That'll put you well past the "2%" of developers. So when I hear someone think that because I like simplicity over more complexity and therefore I must be an unskilled developer I have a chuckle - to me it means the person talking to me is not thoroughly considering a great deal of factors that are outside the actual keystrokes used to build a system with a particular technology (I'm sure this sounds arrogant, it is not meant to be, it is just meant to be an observation from past dealings). Oh, and one more thing, in some ways C# does produce smaller and cleaner code than Java (but IMHO that is kinda countered by non-standard project .NET structures where stuff is squirreled all over the place; what seems like a straightjacket in Java is actually the only way to keep a multi-thousand class project sane) but how I've actually seen it used in practice they are both on-par in how ordinary devs produce awful code.
I'd be very interested to
That works for 'coarse' level stuff. Where documentation is *essential* is when you are trying to write correct and robust software.
In that case you need to consult the documentation to determine what a method's preconditions are, what it'll throw if they're not met (documentation is much better for describing runtime exception than an exception qualifier on the method signature, especially as this doesn't force you to cope with the exception, but the documentation says what gets thrown and more importantly, why). You cannot be a good developer if you are not always thinking about what can go wrong with the software you are using or writing. Not documenting it for your maintainers (including yourself in a few years) is not the mark of a professional (although many devs that consider themselves "pros" haven't yet grokked just how important writing quality docs is - and with things like JavaDoc is is easy to keep consistent as you code).
You also need to consult documentation when you need to consider different units of measure. Is your time in milliseconds? seconds? years? is it UTC? local time? NTP time? what about your masses? lengths? currency units? I know that it never enters the heads of most developers to think about the units they are using, and they also never think that it is worth documenting. But if you want reliable software you need to document it (if you don't want to start using horrible classes that carry around units with them - although that is possible it is very inconvenient for most cases). Units matter, you'll lose your Mars probe if you screw it up (Google it), or calculate the wrong interest amount, or place objects on the wrong place on the map, or schedule a meeting after it has happened, etc.
Documentation (and units!) matter. Unfortunately, as I said, many people think they are excellent coders but they can't be bother to write, read, or maintain useful in-code documentation. I hate using their code and are never surprised when it fails (since they haven't said how to use it correctly or what can kill it).
So if the helmets don't actually stop such trauma (which your statement asserts implicitly) then the logical conclusion is that perhaps the bikes should be banned? The parent poster was alluding to how ridiculous the defensive culture is becoming, and which you apparently subscribe too (based on your statement). If you accept that injuries will always happen yet the trend for protection is starting to outweigh the pleasure of the activity and the *actual* observed risk of injury then perhaps his levity doesn't require such a defensive retort.
Ask not only for his information, but for all the personal information for his wife and children - including the ones from outside his marriage. Then ask whether he still thinks it is a good idea.
Yes, it is nice to work with interfaces. No, you shouldn't care whether you are dealing with an interface or a concrete class. Hence, prepending "I" to interfaces is a bad idea. For example, the Java equivalent for writing (internationalized) text streams is "Writer", you don't care if it is a "FileWriter", "StringWriter", "OutputStreamWriter" etc. Note that it is called "Writer" (a word that makes perfect sense) and not "IWriter" (made up computer jargon). So my argument was not against using interfaces, it was against naming those interfaces in an artificial, and these days unnecessary, manner.
If only Siri worked as advertised. It's not as reliable as you would think - often mangling requests (at least, with my kiwi accent).
Thanks for the clarification. Some folks forget that K&R C was around for a while before ANSI.
Yes, and soon C# will be as "easy" as C++ :) I'm not saying progress is bad, but it has to be weighed against complexity. Personally I'd rather write a few more lines of blindingly clear explicit code that less skilled developers can easily follow than using more fewer lines of implicit code. Just because we're smart enough to deal with complex code doesn't mean everyone is - on large projects you just can't get enough devs that are as skilled as you and I. Anyone can write few lines of "obfuscated C", the wise realise that it is not the number of lines that matter, it is complexity, implicitness and in-obviousness that makes maintenance hard. To repeat a famous mis-quote of Einstein, things should be "as simple as possible, but no simpler". Java has this goal in mind, it is pretty clear that C# does not.
I think you miss the point. The point is that prepending a class or variable name is no longer necessary. You're just so used to it that you can't see how hideous prepending interfaces with "I" is. One day you'll move away from the habit and laugh at how silly a style it all was (just as you probably laugh now at C-type Hungarian Notation).
This is an old-style way of looking at it. I also used to think they would be helpful but now consider them obscuring, you are still thinking in the solution domain rather than trying to get to the problem domain (so that the code reads more like natural language). These days your IDE can tell you the type without you having to pollute your code with these 'warts'. This is why many languages have moved away from such styles. The reason C# has it is that the developers are unable to shake the legacy modes of thought. It turns out that rather than use these artificial constructs to make it easier for following developers it is generally better to aim to make your language simpler. For example, Java is often panned by .NET developers for not having certain constructs but it is a deliberate decision by the Java architects to *keep* the language simple. As a result there are far fewer deprecated constructs and styles in the language. This has a far greater impact on improving code readability for people joining or maintaining a project than using kinda crufty old-style constructs to do this. But yes, I agree with you that consistency is important.
Yeah, the "understated" UIs look great but are actually poorly designed from a usability perspective.
Example: Last week I bought an iPhone 4S and couldn't figure out how to make a call. I went to "Phone" where I had contacts and was presented with buttons for doing Face Time, sending messages, sharing contacts, and adding a contact to favorites, but there was no button to make a call. I mean, given that choosing the Phone app means you will want to make a call on a selected contact about 95% of the time you would think there would be a massive "Call" icon, since that is the most common thing you'd like to do. It turns out you have to tap on the phone number to make the call - even though there is absolutely nothing to indicate that tapping the number would make a call (my expectation was that tapping the number would edit it). Now that I know that all the interface elements are clickable "buttons" *even if they don't look like the buttons shown elsewhere* things are much easier (and this is coming from a long-time user of Macs). While many of the UI features of Apple are excellent I consider their minimalist approach has gone so far as to present too little information. My point here is that while we are decrying Microsoft for their UI designs we can also do the same for Apple. Mostly less is more, but sometimes less really is less. One of my hats is a trained technical writer and from that point-of-view I consider some elements of Apple's style to be very, very bad - but that is not a particularly fashionable point of view at the moment.
The C# standard library uses the prefix "I" for interface classes. This is something you don't see in Java (despite C# being derived directly from Java via the intermediate research language "Cool"). So yeah, a stake has not yet been put through the heart of Hungarian Notation yet.
That may be a good reason. The real reason for the rise of Hungarian Notation is that the Microsoft C compiler didn't do type checking for some time after other C compilers had it. If you wanted to have a clue what type you were using you adopted Charles Simonyi's notation (which was used by FORTRAN devs at the time). The problem is, that awful practice of using 'warts' as a prefix stuck around. It even lingers in C# where interfaces are traditionally prefixed with "I". Fortunately this is something that Java conventions avoid - and if you decide to change an interface into a concrete class during development you don't have to go around and rename everything (plus, such prefixes are unnecessary in the modern age, the compiler helps you when you mistake an interface for a concrete class, so the 'wart' has no upside while having the refactoring downside).
Yeah. When going through officer school of our Air Force we were taught our military law and there was a charge "Conduct prejudicial to service discipline" that could be used to apply to anything. You'd be pretty hard pressed to defend against this.
The problem is that most humans expect someone else to give them a purpose. Only a few folks figure out that they can set their own purpose and move to it. Some of the English are particularly good at this - deciding they want to collect butterflies, or stamps, or walk all the lanes in the country. Americans don't seem to be as good at this (deriving purpose from simple pleasures) from what I have seen - but of course I'm generalizing here. My point is that the billions of idle hands are trouble only because people can't set their own purpose - but if they could then the world would be an excellent place for the most part. Golovachev has an interesting, if myopic view.
Christianity also had many reform figures, most of who were dispatched as heretics just as in the Muslim world. What made "Martin Luther" special is that he was *accepted* by a majority in a large area. To my knowledge there has been no reformer that has been as widely accepted in the Muslim world as Luther was in the Christendom. This is why there has been no-one accepted as "Luther", despite all the Muslim reformers there have been. One interesting thing is that Luther's views are actually more fundamentalist, but the fundamentals of Christ's teachings emphasize tolerance and forgiveness over the strict interpretation of the Mosaic Law. My understanding of the Islam has the emphasis the other way around. Islam does preach tolerance etc but my understanding is this is secondary to upholding the laws.
In from New Zealand. I hope we would have taken him (probably would have too). He should have passed through Singapore instead (they have no love for Malaysia). Typical modern journalist, not checking his facts. lol.
> But with all the international uproar about this case probably Saudis will get a slap on the wrist. Interpol cannot allow itself to be dragged into religious wars.
By passing the warrant on that is precisely what they did. They did not have to pass the warrant on if it contravened their charter - but they did (probably because they were too lazy to figure out the ramifications - most cops are useless in that regard). Hopefully Interpol will learn from this scandal - otherwise they are aiding and abetting actions that go against their own charter.
Yes. Malaysia used to have famously tolerant Muslims. Unfortunately Saudi has been exporting Wahhabi clerics (in addition to the oil) that have a unique tribal interpretation of things - it is this mostly sect that is dangerously radicalizing Muslims today, including in Malaysia.