Comment Re:Android is not Linux ... (Score 1) 321
Well, and how does it change the nature of Android that you can write apps entirely in C without a single line of Java anywhere? Google even ships demos that do just that.
Well, and how does it change the nature of Android that you can write apps entirely in C without a single line of Java anywhere? Google even ships demos that do just that.
Very few apps use it? Everything that is ported from other platforms is using the NDK, Or do you think that apps like Firefox, Chrome or Opera have been rewritten in Java? And then there's all the cross-platform games.
You are wrong. Android has a C interface that is very POSIX conformant. It is there for applications to use. Google offers all the tools you need to make use of that.
You should read Ken Thompson's "Reflections on Trusting Trust" and the thesis that shows how to detect that attack (forgot the name of the author - Bruce Schneier has written a good summary of it, though). This will tell you why you want multiple compilers for some things.
Very short summary (probably wrong - it's confusing): You want to compile your production compiler with two different compilers to check if the binaries these resulting production compiler binaries produces are the same (e.g. you let the production compiler compile itself again using the two different binaries). Your alternate compiler does not strictly have to be up to date or fully featured for that. It must only be able to compile the compiler that was used for creating the actual product under scrutiny.
There are many things that you can argue about, but only few that you should argue about as a professional. For example, it is OK to argue about the best way to go about something. Done right, everybody leaves a bit wiser. But it is usually not OK to argue on a personal level in a tech job.
I think you are overestimating the difficulty in slipping unwanted hidden functionality into code. Take a look at the underhanded C code contest for some ideas. The number of entries in each contest suggests that it's easier than it looks to come up with that kind of thing if you really want to.
Well, at Unity you are in the cozy position of not having to work much on actual games. Game studios have a lot of shit going down because of the creative and economic aspects of games. Game engines are sort of decoupled from that. Consider yourself lucky in that regard!
Also, you guys at Unity are doing great work.
Although I'm in danger of talking out of my ass here I'll say it anyway: wayland has a lot of the typical OSS project flaws that make running a Linux box a nightmare. It is designed to be reimplementable (open and extendable interface, yada yada) which means that there will be incompatible , incomplete and buggy implementations out there. Essential parts of GUI environments (standard DND and copy/paste protocols, for example) were omitted last time I looked due to the focus on graphical IO. The result will be incompatible protocol extensions or 3rd party daemons to handle that. Naturally, they will be incompatible and some of them might eventually learn to work together, but that will only work properly when the phase of the moon is correct and the stars align in the proper way.
I would really love to see an OpenGL based (not ES based) graphics/GUI stack for Linux that is designed monolithically enough to provide a dependable and clean base for 3rd party apps to depend on without being full of nasty surprises. I really fear that wayland will botch that.
Not likely going to happen since f****** Oracle forbade redistribution of Java. Distributions now can only provide OpenJDK without making the user go through manual download procedures. And OpenJDK doesn't quite have the same quality and stability in my experience.
Java is amazing technology and it is sad to see Oracle hellbent on killing it off.
A key that is only used for communication and never for storage does not need to be recoverable, does it?
Still, it's asymptotic. Have fun!
Obviously it will be PHP
Using ints makes this kind of optimisation very easy. Usually, the types you use overloading for are more complex and the operators that are called will likely be inlined, but not combined in a meaningful way.
Clearly you have not yet had a chance to write code that does real maths with real mathematical types like vectors or matrices. This is wheree operator overloading really shines. You don't want to implement complex formulas with tons of explicit function calls. With overloaded operators you can basically transfer the formulas you calculated on paper into machine code almost exactly. Without them, it's a sad mess of nested function calls, long lines, superfluous temporary variables and almost inevitable mistakes in code that nobody wants to read.
Of course there are times when operator overloading is exactly the wrong thing to do. But if it is used the right way, it is an amazing feature.
The real shame is that some CS students only learn Java at University and when they encounter C or C++ for the first time, they immediately screw up royally because they never learned anything about basic things like memory addresses and pointers. They have problems grasping the basics of those. I find it a shame that you can graduate not knowing what a pointer is.
The biggest difference between time and space is that you can't reuse time. -- Merrick Furst