As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
if Apple announce their own gaming console as they did in past and i'm sure they will not support C++/C# games. so my question is that Is Objective-C is such fast and powerful to write efficient game Engine ?
Cocos2D is a very effective Objective-C Graphics engine, along with Box2D Physics Engine and a CocosDenshion Audio engine you can make some very nice games.
Objective-C is a fast, small-footprint language. Seeing as how it runs on the most successful Embedded mass-market platform - the iPhone. I'm not sure what justification you give that C++/C# is a better choice for games? As noted here, cached message sends are faster than C++ Virtual Method calls.
Most games on Apple devices are written in C/C++ with perhaps a thin facade of Objective-C. So you are pointing out a non-issue.
Also Objective-C is very fast since it's just a superset of C.
I'm sure that C++ would be always supported by Apple. It's really not possible to write optimized game like, for example Infinity Blade using only Objective C.
The reason of this is the huge flexibility of the language (while in most cases it's a big advantage but not in game development): it is achieved using runtime messaging, which uses a lot of implicit function calls (search in cache, search in methods, search in superclass cache and so on).
So almost everything is resolved at runtime in ObjC and it takes much time for processing.
26 years ago my using of C++ instead of C was laughed. Now almost game developers are using C++.
Likewise, the trends will change into objective-c in my opinion!
Use of C inside objective-c for better performance is not giving up objective-c but should be called performance tuning!
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am going to develop an application for OS X and I need some scripting engine for it.
The purpose of the scripts is to receive a text on their input (HTML file in most cases), parse it in some way and return the data to my app. These scripts should be easily editable by the users, therefore they should have some common used syntax like C or pascal.
Can you suggest some lightweight solution for this?
Thanks!
PS. I am new to OS X development, trying to switch from Windows...
Two suggestions:
Javascript, try the V8 engine. http://code.google.com/p/v8/ Very popular, likely familiar syntax to many.
Lua. http://www.lua.org Extremely lightweight and simple to connect. If your script editors write scripts for World of Warcraft, for example, they will know Lua.
In general AppleScript/Automator actions are easy for the end user to work with since the technology includes a GUI for building scripts without much programming knowledge. For experienced developers used to other languages, they can be a bit too friendly/loose and have a somewhat different syntax (more like plain English). The good thing is that they can also call other languages as needed, so a developer familiar with Perl or whatever could incorporate that into an AppleScript or Automator action.
Since you're talking about parsing text, Perl itself would be a good solution - again there's some difference in syntax, but the scripts can be rather compact and the basics of parsing aren't too difficult to learn. I haven't personally incorporated Perl into an OS X app, I've just used it on the command line, so I don't know if there are any pitfalls to that approach.
One additional advantage to AppleScript is that you can make your application itself scriptable so that users could automate the functions of your application into a larger workflow.
I would suggest downloading the free TextWrangler application by Bare Bones Software, or a similar developer's text editor, to see how they incorporate scripting into the application. This may give you additional insight into your approach.
LUA seems to be a good choice.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In the past few months, while doing iOS development, I got really comfortable with using the so called Grand Central Dispatch technology provided by default with ObjectiveC. With just a couple of simple calls, it allows me to do awesome things like:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{
// Do stuff on the lowest priority queue here
dispatch_async(dispatch_get_main_queue(), ^{
// Do stuff with the above results here back in main thread/queue
});
});
I can basically fork off tasks on other threads of custom priority whenever I feel like it, and I can use the result in any way I want without having to put much effort into passing objects between threads, terminating threads, joining on then etc. According to Wikipedia, a more general name of that approach is the "thread pool pattern".
I feel like, as far as achieving parallelism is concerned, this is easier than a lot of other solutions I have used in the past (I'm thinking pthreads, but there's something analogous in most languages). I guess that a big part of the "ease of use" comes from the fact that iOS apps (OSX too? never wrote one myself) use run-loops and task queues for each thread, thus making work separable into discrete units, not something you generally start with in a blank program skeleton in most languages.
The question thus is, is there anything like GCD in other languages, or is it not a model popular outside of the Apple universe? I'm specifically interested in Clojure/JVM, since it does add a bunch of parallelization abstraction that might perhaps be analogous, but I'd love to know the same about other languages as well.
Grand Central Dispatch is at its heart a thread pool. Most languages have something similar, though GCD is nicer than most IMO. The most popular equivalent Java library is Fork/Join. Clojure also includes a number of concurrency functions for handling specific tasks, but for more general concurrency you'll want Fork/Join.
the dispatch API is in C and open source. so it isnt part of the objC runtime (though the runtime uses the dispatch api!)
something similiar.. mhm .... maybe the Parallel Task Lib Under Windows 8
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I wrote a simple genetic algorithm to evolve the string "helloworld". I wrote it twice. The first time was written using classes. And the second time was written using just functions where the entire state of the genetic world is passed from one function to the next...to mimic the data flow paradigm. Surprisingly, the code worked well for both the implementations. However, I managed to get it working only after painstakingly removing each and every bug, which was quite a laborious process.
And I asked myself.. there has got to be a better way. Write the code using classes was comparatively difficult than writing the same code using simple functions and I believe writing the same code visually, using something like labview for example would be a lot more easier than writing it only using simple functions.
To that extent, I read about data flow programming and visual programming and quite frankly it seems like it is more natural and intuitive to program in a visual, data oriented manner than in a statement-wise manner, which is what most programming languages enable us to do today. My question is.. if this is the case, why hasn't data flow, visual programming like "labview" become the standard?
I do not believe that data-flow / "Visual Programming" has nearly the performance of well-designed code.
Text-based code can express far more complex and subtle data structures and flows than anything graphical. It gives programmers detailed control over what gets copied, what gets accessed, and precise control over sequences of steps. I have a hard time seeing how data-flow could be that expressive.
Ultimately, data-flow /visual programming can only describe things that are already known. Text-programming (for lack of a better term) actually lets you express more. Programmers can create entirely new data structures and algorithms that simply haven't been represented visually yet.
It is dangerous to use a single problem as the basis for how programming languages should be designed. I'm not sure how the data-flow paradigm would improve GUI framework design, for instance.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have been working on an application from past 4 months and it's very much depends on Google Maps on iOS platform. Recently one of my friends raised a concern that what if Apple Inc. decides to use a different Map provider?
It turns out after few searching on internet that Apple is going to replace Google Maps with some new advance 3D maps build by company called C3. (One of the researched resource). Well now I am worried of my already written code,
Should I delay my development work until this new technology gets in? or just wait until Apple announces officially.
Thanks
This is a common dilemma in programming, and there's a common solution too. Develop your own primitives - whether you need to display overlays, show landmarks, draw polygons and lines, do everything through stubs in your own code. If the underlying platform has to change, you then have a few well-known places to update to the new API.
Be very strict about not accessing the underlying API anywhere that isn't in your wrapper layer, and it should be straight-forward to change to a different later. Not free, of course, but so long as it's possible to implement the primitives you need in the new layer, you just need to change those, and can leave the rest of your project untouched.
It's not worth losing months' of having a finished project to avoid this situation.
Edit: This approach has another benefit - if you end up writing multiple primitive layers for different APIs, you may be able to let the user pick between them: you may have a (more expensive) higher-quality map layer which you charge for, and a cheap/free one which you don't - allowing people free access to a lower-quality version, and letting them buy an upgrade to the better maps. Or ... there are lots of possibilities. It's the same pattern some applications take with data-persistence layers, letting people run the same application on top of differing data platforms. There are lots of examples of this patterm.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Why Objective-C is chosen as language for cocoa or cocoa touch, why not other? What are main usages in Objective-C that are not in other languages.
How I can Convince the interviewer about this.
The main reason is that Cocoa is descended from NeXTStep, which was written in Objective-C back before C++ had the STL (IIRC it didn't even have useful templates back then; I recall g++ having big warnings in its template implementation into the early 90s). Also, I gather Jobs & co. preferred the Smalltalk-like OO of Objective C.
Cocoa is it self implemented in Object-C. By using that language a developer can more easily leverage the features of the hose system. While C/C++ are valid languages ( because of Objective-C background in them ) the interface between C/C++ and Cocoa ( because it's Objective-C ) is harder than if you were to just stick with Objective-C.
See more on this from Apple.
First, I think any language with GC is far more productive than any language without. Especially when programming in the large across many different teams, developers and frameworks, other techniques like reference counting are flawed and lead to code bloat. Many years ago there was a formal study that showed that the theoretical best performance of Generational Garbage Collection was about 4% of cpu usage. The theoretical best using reference counting was just under 10%.
The second thing to look at is how confining the language chosen is and how easy it is to blend with other C / C++ code. Many languages, such as Java, pretty much limit you to a single paradigm. Objective C is set of OO extensions on top of C. It has a great deal of flexibility as a result. In Objective C 2.0 and later, new features such as properties and blocks have also been added.
All the above said there are things I don't like about Objective C. It is more verbose than I like in a programming language and does not provide sufficient capabilities to do much meta-programming. I really am not happy that it still does not have namespaces. I know some of the reasons used to explain this lack but I do not find them at all sufficient. A flat class and method/selector namespace is not excusable in the 21st century.
What I really want is for MacRuby to take off and be implemented very very efficiently. A return of Dylan would also be very greatly appreciated. :)