Is there a version of Smalltalk that allows distributed message passing, much as Erlang has? Could Smalltalk be an ideal language if it has this distributed message passing, as Smalltalk also implements its own VM if I am not mistaken?
Everything in Smalltalk is done through message passing. Almost all of it is local of course.
Richard Durr hints at it in his answer, but Croquet have a library called Islands, which is modelled on E's Vats.
Have a look at Croquet. Maybe their technology is what you want.
http://en.wikipedia.org/wiki/Croquet_project
There is SqueakElib
http://www.squeaksource.com/squeakelib.html
wiki.squeak.org/squeak/6011
In Cincom VisualWorks there is a library called OpenTalk. The basic idea is the same -- replace remote object with local proxy. Good thing about OpenTalk is that in many cases it just works, and in other cases you can customize it by replacing its components (marshaller, policies, network transport, etc).
Basically, OpenTalk message passing is synchronous (contrary to Erlang as far as I know). But you can implement (and some users have implemented) any required semantics in a rather straightforward way.
OpenTalk is a part of standard VisualWorks library.
VisualWorks page at Cincom:
http://www.cincomsmalltalk.com/main/products/visualworks
Related
I've been using MYNetwork by the venerable Jens Alfke for an app of mine that allows devices to connect and share info over the network, it's actually a mission-critical part of the app. I tried writing my own wrapper for all of the C-level stuff you have to do for Bonjour, but it didn't work out so well, so I moved to MYNetwork.
It's been great so far, but the fact it's essentially opaque to me is causing trouble, as is that I want to move over to ARC once we can submit apps with it (there's a lot of Objective-C object references in structs, which ARC hates).
Can anyone recommend a similar wrapper, ideally that allows easy message passing between a client and a server over Bonjour as well as service discovery?
Just a thought- Would using ZeroMQ advertised and discovered by the stock NSNetService suffice? Separating the service pub/sub from the actual communication would allow you to use other bonjour libraries like Avahi on linux too. ZeroMQ is sufficiently simple to make wrapping trivial, yet powerful enough to cope with complex network topologies, fast.
I have experience with both technologies in isolation but not together although I see no reason why it wouldn't work. The only caveat right now is the limited body of collective experience of ZeroMQ use on iOS but I'd expect that to change over time.
You know you can disable ARC for specific files? So, you can just disable ARC for the library, and keep it on for your other files.
Disable Automatic Reference Counting for Some Files
Why doesn’t Objective-C have namespaces? It seems like a simple feature that would make some class names more readable (AVMutableVideoCompositionLayerInstruction anyone?) and axe the silly letter prefixes on class names. Is this mainly because of backwards compatibility? Is it harder to implement namespaces than it seems?
I don't know the answer but I suspect "it's harder than it looks" is probably it. You would have to introduce support in the compiler and linker in a way that doesn't break existing software. And while this is obviously possible (C++ has already done it) presumably the tool chain team have had higher priorities on their plate. e.g. in the recent past we have had garbage collection, GCD, blocks and Objective-C 2.0 appear so we can't say they have been doing nothing.
Namespace support is the one thing that I would dearly love to see introduced to Objective-C.
I don't know if you want to know if there is some official decision.
But namespace like many other feature are choice, choice made by the language contributor.
PHP only recently introduced Namespace, and for example Java use package that act like namespace or python use modules.
I think that there is an overhead in namespace implementation, mainly because Objective-c is dinamically typed so at runtime you have to make some check to resolve the namespace, to resolve default behaviour,etc.. and I can suppose that because Objective-c is also used in embedded enviroment (AKA iPhone) speed is very important.
You've to wrap everything I've said in a big IMHO ;D
Update:
I found this very interesting discussion http://clang-developers.42468.n3.nabble.com/Adding-namespaces-to-Objective-C-td1870848.html#a1872744 on the clang developer website explaining the reason why is definitely non-trivial to implement namespace in Obj-C.
I have trouble understanding XPCOM. How is it different from COM? What makes it cross platform?
Is it a framework with a set of libraries that you can use to do some jobs?
Also, does Component Object Model means every functionality is implemented in component so we can use it without knowing the detail implementation?
Can you someone help me understand this please?
Thanks,
Chan.
I have trouble understanding XPCOM.
How is it different from COM?
XPCOM is Mozilla's own, cross-platform (hence the XP bit) version of COM.
What makes it cross platform?
It is implemented in a library that has been ported to many platforms by contributors to the Mozilla open-source project. You can build it or download a binary for any platform that you wish and, in the extremely remote possibility that you want to use it on a platform that is not already supported, it should be straightforward to port it yourself.
Also, does Component Object Model
means every functionality is
implemented in component so we can use
it without knowing the detail
implementation?
Yes, spot on. The idea is for a language-independent framework that enables different components to communicate and interact, without requiring any special knowledge of the language that any particular component is implemented in. So javascript code can call C++ code, for instance.
This is achieved by components publishing well-defined interfaces, using a language called IDL (or, in XPCOM's case, XPIDL). These interfaces make use of well-defined types with mappings in each of the supporting languages. Every interface inherits from a common base interface, which provides standard methods for reference-counting and type-inference (called IUnknown in COM and nsISupports in XPCOM).
Can you someone help me understand
this please?
In terms of online resources, there are dedicated areas on both the MSDN (for COM) and the MDC (for XPCOM). If you want to really understand the motivation for COM and why it is the way it is, I recommend picking up Don Box's Essential COM. And of course, if you have any specific questions that need answering, you can always come here to ask them. :)
I'm working on an app in squeak that requires no graphics at all, its all just data manipulation. The problem is that I work in a fairly conservative environment and I dont think I'll be able to sell a squeak app to my managers (I feel like the bright colors, round interface and general "what-the-heck-is-that" feel of squeak will scare them off). So I'm considering running the app under GNU Smalltalk, as a more "traditional" command-line interface is less likely to scare off stakeholders.
So, can anyone either provide, or point me towards, a list or set of what features/classes are or are not compatible between Squeak and Gnu Smalltalk. In other words, how hard will it be to port an app from one to the other (again assuming that its non-graphical, so no need to worry about morphic)?
Thanks!
I agree 100% with igouy; in addition to that, the main difference will be the filesystem classes. GNU Smalltalk's are more similar to what you get with Squeak's Rio package.
You can convert your code from Squeak to GST with gst-convert which will also take care of some of the difference.
There is an ANSI Smalltalk Standard (http://www.smalltalk.org/versions/ANSIStandardSmalltalk.html). Gnu seems to be a full implementation of the standard (see Gnu Wiki) and Squeak seems to be fairly compliant (see Squeak Wiki). So stick to the standard and you should do well.
The GST implementation will give you a much better answer than we can - so just try it - file out your code, and see what fails with GST.
I don't know how up-to-date the Rosetta "Cross-Dialect Smalltalk Code Interchange Tool" is but it might help.
Here are some minor differences that were leveled out to make things easier on the benchmarks game - GNU Smalltalk :: Squeak
When you hit specific problems ask about them on the GNU Smalltalk Mailing List.
In addition to the other suggestions, make sure your SUnit test cases are up-to-date; it's much easier to find any missing methods in GNU Smalltalk that your application is using that way.
Pharo looks more professional, and might help. Or if you have less than 4GB of data, Gemstone. A Seaside user interface looks the same as a ASP.NET MVC or Rails one, and can be created easier.
What are the programming features that are missing in C++ and Java ?
For eg. You can't do recursive programming in QBasic ? You can't dynamically allocate memory in QBasic.
What would be the good to have features in C++, Java.
I think Lisp Programmers will be able to add a few.
I miss lambda expressions.
This answer deals only with C++
Things I miss from the syntax, or the standard library:
RegExp as part of the standard library
Threads as part of the standard library
Pointer to member methods (not objects!)
Properties would be nice (I have seen codes that emulate this via C++ preprocessor... note an nice looking code).
Some lower level networking API (sockets!), and higher level API (give me this file from this ftp, submit "this" to this site via POST).
This is the list of things I would like to see, but I assume other people will disagree with me.
Memory garbage collector is nice.
A n interface for a GUI toolkit - let MSVC map it to win32, and on Linux... (good question!)
A stable ABI. In C it's a standard - but on C++ we are still missing a few decades. I want also stable ABI between compilers - I want to compile one library in MinGW, the other with CL and all should work.
This is the list of things I want to see, but I know they will not get away:
Compatibility with C. Really, it's a myth right now. using namespace std killed it.
Include, headers. Most of the information is already available in the DLL/so/a/"library", do we really need to keep this bad decision from 30 years ago? If needed the compilers should keep information in the binaries.
The need for Makefiles - the compiler should be smart enough to know what to do with this code, from the code itself. Pascal is doing it quite good. I think also D.
(I might be wrong, please correct me) The official standard openly and freely available for viewing. Why should I pay for the official papers? Do I need to do it for HTTP? UTF8? Unicode?
I think this is a very subjective question. From a theoretical point of view there's nothing "missing" in Java because you can do everything you want to from the perspective of the outcome as an application.
As with QBasic - recursion may not be possible but that doesn't prevent you from changing your recursive algorithm to an iterative algorithm. Programming language theory tells us that you can do this with every recursive problem. So there's also nothing missing here.
I think what you mean are features that are "nice to have" - and here everyone has to decide for himself. I'd even say there are features in the language which would have been "nice not to have" such as static imports - but again this is my subjective opinion...