Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am CS student relatively new to Cocoa/CocoaTouch and I am trying to understand the nature of OS X/iOS dev. I understand the difference between dynamic and static languages.
Static languages have all variables bound to a type etc. Variables are bound during execution for dynamic etc.
However, when I am developing OS X apps I struggle to see the examples where dynamic functionality would change things? Can someone explain what someone explain what Obj-C can support that Swift fundamentally cannot when developing apps?
I have come across many cases where the lack of flexibility has forced me to refactor my code, but that's not what I am talking about, or am I confused?
Can someone explain what someone explain what Obj-C can support that Swift fundamentally cannot when developing apps
What I used to take advantage of in Objective-C was not so much dynamic typing as dynamic messaging. The whole messaging apparatus can be rejiggered at runtime, from simple key-value coding or performSelector to dynamic injection of methods into a class at runtime, method swizzling, and key-value observing.
You can do all those things in Swift, but only provided you are talking to Objective-C (i.e. this is an NSObject). That's because all of those things are actually done in Objective-C. You could not, for example, implement even the most basic key-value coding in pure Swift, in the absence of Foundation, as Swift has neither dynamic messaging nor true introspection.
From the point of view of practical app programming, however, I don't miss any of that. For one thing, I am always talking to Objective-C, because Cocoa is in Objective-C. For another thing, it turns out that most of these tricks weren't really necessary, and I've mostly found other ways to accomplish my practical goals. I do still use some key-value coding (especially to do tricks like store an arbitrary value inside a CALayer), but on the whole I've cut way back on my use of such stuff, mostly thanks to the fact that functions are first-class citizens in Swift.
As for dynamic typing, I don't miss it for an instant; changing to Swift has actually saved me from mistakes that I was making without even realizing it because of dynamic typing imposed on me by the APIs (e.g. the fact that objectAtIndex: returned an id — though, to be sure, this is less likely to trouble you today thanks to "lightweight generics").
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Almost all conventional languages today represent programmers intention as text source, which is then (lets say for sake of simplicity) translated to some bytecode/machine code and interpreted/executed by a VM/CPU.
There was another technique, which, for some reason, isn't that popular theese days: "freeze" the run-time of your VM and dump/serialize the environment (symbol bindings, state, code (whatever that is)) into an image, which you can then transfer, load and execute.
Consequentially, you do not "write" your code in a usual way, but you modify the environment with new symbols, while in "run-time".
I see great advantages to this technique:
Power-boosted REPL: you can introspect your code as you write it, partially evaluate it, test it directly and see the effects of your changes. Then roll back if you've messed up and do it again, or commit it to the environment finally. No need for long compile-run-debug cycle;
Some of the usual problems about dynamic languages (that they cannot be compiled, as compiler cannot reason about environments statically) are obliviated: the interpreter knows where what is located and can subsitute symbol references with static offsets and do other optimizations;
It's easier on programmer's brain: you "offload" different contextual information about the code from your head, i.e. you don't need to keep track about what your code has already done to some variable/data structure or which variable holds what: you see it directly in front of your eyes! In the usual way (writing source), programmers add new abstractions or comments to the code to clarify intents, but this can (and will) get messy.
The question is: what are disadvantages of this approach? Is there any serious critical disadvantage that I am not seeing? I know, there are some problems with it, i.e.:
try building a module system with it, that will not result in dependancy hell or serious linkage problems
security issues
try to version-control such images and enable concurrent development
But these are, IMHO, solvable with a good design.
EDIT1: concerning status "closed,primarily opinion-based". I've described two existent approaches and it is clear and obvious that one is preferred over another. Whether the reasons for that are purely "opinion-based" or there is a reasearch to back this up, is unknown to me, but even if they are opinion-based, if someone would list these reasons for such an opinion to develop, it should, actually, answer my question.
As a daily user of smalltalk, I've to say I haven't found any fundamental disadvantages and have to agree that there are lots of advantages.
It makes metaprogramming, reasoning about your program easy, and much better supports refactoring and code rewriting.
It requires/develops a different way of looking at your code, though. Smalltalk has little to offer to developers who are not interested in abstraction
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Whereas I'm fully aware of Scala and Akka actors, and other, non-stdlib concurrency packages for Scala, having gotten used to Gevent (it's a green threading + non-blocking IO framework/library for Python, that has not been getting the attention I think it deserves compared to stuff like NodeJS and all sorts of Actor frameworks) and how easy it is to write concurrent code with it—just write code as if with "real" threads but no actual OS threads are used, so you can have thousands of them, like Erlang processes, and all existing code Just Works—I have to say I'm not currently too much in love with the rather limited (and somewhat hard to compose with "normal code") way in which concurrent code needs to be written when Akka-style actors are used.
Now, there is Kilim, which appears to be doing what Gevent is doing (except it's using a CPS transform not runtime stack manipulation); also, Scala is known to be able to fully interoperate with Java. However, does this interoperability fully extend to the level at which Kilim operates? If yes, what are the key things to keep in mind when a combination of Scala and Kilim is implemented? I've found some resources (e.g. https://github.com/lllazu/kilim-scala) on this by googling but nothing clear or substantial.
Note: I'd also be interested in aspects such as:
why this is a typically discouraged approach to start with (i.e. I should be using Akka);
that I'm wrong and Akka-style actor code isn't limiting, or is not limiting enough to have any considerable effect on the (high level) style of code;
Feel free to have a comment on anything related
In C/C++ the most generic and least invasive approach to asynchronous execution seems to be the callbacks and I prefer to stay with the callbacks in order to be able to reuse the most libraries out there. With a bit of coroutine magick any callback-oriented library can be used imperatively, that is, for any method foo (callback (bar)) I can make a wrapper bar = foo (cbcoro) which can be used withing a normal imperative control flow (while doing context switching behind the scene).
I'm starting another project in Scala now and going to try to use the delimeted continuations in a similar way.
P.S. Bytecode instrumentation which works fine with the Java bytecode code can still fail with the Scala bytecode, I've seen this happen with db4o and DataNucleus, therefore you need a good support (or a very good knowledge of the tools in question) if you're going that way.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I really want to use PGM for an application that I'm working on for one my companies. That application will never be distributed, it's for internal use only. There is an implementation called OpenPGM and a (I believe) derivative work javapgm that implements the protocol. Both are licensed under the LGPL.
My question is if I read the source code for these libraries and use that knowledge to help create an Erlang PGM implementation, would that be considered a derived work? I would prefer to release my implementation under the BSD license, so I'm not trying to take something for nothing, but I want to play fair.
In short then:
Would / should my version be released under the LGPL?
If my company is using it internally only, would there be any restrictions on how it could use that library? (it would never be distributed outside the company).
Is it in the spirit of the LGPL license to do what I want to do?
Thanks in advance! :)
I don't think it would be a derived work unless there is a 1:1 correlation between lines of code in your thing and the open source code. We're not talking about a patent here, where the concept of the invention is important.
If it is only used internally then it doesn't have to be.
You could never be certain that it doesn't accidentally leak out or get shared or included in another project.
You should try to work with OpenPGM to make the Erlang interface that you need; then it is open source, other people may help maintain it for you, you get a free code review
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Now that Apple relaxed the restrictions on developer tools/programs, I wonder what tempts developers to other languages than Apple offers by default, Objective-C, which is quite fun to program with. What missing feautures makes you not to program with it but something else?
Lack of Objective-C expertise or a large/complex code base in another language would be among common reasons.
Cross-platform coding might well be another.
I haven't done any iPhone development yet, but generally speaking, here's a few reasons:
Cross-platform development
The other language suits your coding style better
The other language is a better tool for the job
You are comfortable in the other language and don't have the time / budget / motivation to learn Objective-C
Existing libraries / codebase
Specific tools you might want to use
Testing some concepts in Objective-C can sometimes be kind of tedious to set up. Sometimes you just want to see how a single method works or play around with an object's functionality to see how it works.
Setting up a new project is somewhat tedious, and it's not always feasible to incorporate the test code in to a new project.
In this case, I do one of two things:
Keep an empty project around specifically for testing things
Drop down to the Terminal and use irb (or PyObjC) to play with the objects in Ruby or Python.
In a nutshell, the thing that's missing is the ability to use Objective-C in an interpreted manner. You have to use another language (like Ruby or Python) to do this.
I recently wrote some networking code in Python, then had to translate it into Objective-C for use on the iPad. A typical line of clear Python would become five or ten lines of busy-work C. I just work faster in higher-level lanugages; the language puts up less resistance, requires fewer forms to be filled out.
I have ported a couple of tiny language interpreters (for my own use, not for App store distribution) to the iPhone. This allows me to write short snippets of code on the road, without having to carry my Mac, and run them locally. I don't know of any small Objective C interpreters, and the language is not really designed for interactive use.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Does code like this (potentially) violate the iPhone Developer License Agreement?
Class clazz = NSClassFromString(#"WNEntity");
id entity = [clazz entityWithImage:#"Icon.png"];
SEL setPositionSelector = NSSelectorFromString(#"setPosition:");
objc_msgSend(entity, setPositionSelector, CGPointMake(200, 100));
I'm working on code that dynamically allocates classes from XML and calls methods on them via objc_msgSend. It's just very convenient constructing my objects that way but it worries me because i have no idea whether this is ok or violates the License by dynamically executing code or maybe even calling private (?) API functions. They wouldn't be documented if they were private, right?
Can someone shed some light on this? Have you had an App approved or rejected using code similar to the above?
I'm pretty sure that this is ok but i wan't to hear it from someone else! :)
If the method you're calling is documented, you're not violating the agreement. There's nothing wrong with using objc_msgSend(), because these "reflection" functions are fully documented.
You need to use a similar structure in order to support different versions of iOS (or a "universal" app that works on iPhone and iPad) so it should be fine.
One point, though: I'm not sure that you need to directly use objc_msgSend. Could you not use performSelector:withObject:afterDelay: or one of the other, similar methods of NSObject?