Originally Posted by SpamSandwich
Amazing. No one expected this.
Nobody expects the unexpected. Time will tell, but usually new programming languages are met with extremely hostile developers at first, and lack of cross-platform viability (eg to Windows or Android) will ultimately prevent a language from muscling out whatever is dominant, no matter how crappy the dominant language is (eg Java and C++ are crappy for reasons owing to their unnecessary complexity and inflexibility between runtimes using the same language. This is why all third party libraries use C bindings and not something else.)
Originally Posted by Tallest Skil
I was turned onto a video by GatorGuy a few years (years?) ago. Can’t find the link. Maybe he can. I have the video downloaded, but uploading it again would be unnecessary.EDIT:
This guy’s giving a talk about software development and the power that could be afforded to developers if the coding software gave them realtime feedback. It blew me away, because that’s exactly what is needed! Being able to see where elements on the screen are going, changing them on the fly, building the world based on the realtime feedback, scrubbing through the execution, etc.And Swift+Xcode is much exactly that.
I am absolutely thrilled by this. Can’t wait to see it in action.This
is what Apple has over Windows and Android. The mentally inadequate scream that features are being “copied” (ignoring that they’re not), while refusing to acknowledge that they don’t even have anything remotely like what Apple has on the back end.
From the icon, I expected the language to be called Peregrine
. Swift works, too.
Originally Posted by Ezhik
Oooh, very exciting, can't wait to try this. I tried to get into iOS development, but just couldn't wrap my head around Obj-C
This is what you see happen whenever you see the word "Framework" or "Factory" with C++ or OBJC. To give an example, when someone needs to load an image, they will most likely use a library for anything more complicated than BMP/TGA. But the latest thing to do for GPU efficiency is to design a sprite/texture atlas. This is because it's a lot easier to change the texture coordinates than it is to unload and load new textures for animated sequences. So if you decide to use a framework's version of this, you are now stuck using that framework for everything (because few libraries and frameworks talk to each other, they assume you are using only itself) involving images otherwise you will duplicate code (I've seen one game have three different JPEG saving libraries because their video capture codec was MJPG, their still capture was JPEG's jpeg library, and their internet leaderboard library had yet another JPEG library because it resized images) that wastes memory and processing time.
Before one gets invested in a library or framework, do your own research to see if the complexity of what you want to do necessitates the library in the first place.Edited by Misa - 6/2/14 at 1:15pm