Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Is it possible/feasible to use ObjC (not necessary the Apple flavor) to develop server-side web applications? Is GNU ObjC toolchain at all usable? Please share your thoughts and experiences.
Upd. I'd like to hear more answers with concrete practical experience, like "i tried/use .... and it is great/sucks, because...". 300 bounty!
Upd2. The rationale behind my question is that I'm about to develop an iOS app with a large web-based backend and thought it would be nice to use the same toolchain/IDE for both parts. But, alas, the answers so far show that this is not going to be feasible. Thanks everybody for taking time.
The answer that the market has pretty definitely settled on is that yes, it's possible, and no, it's not feasible to try to push such a thing on the market. Apple's WebObjects (what the Apple Online Store uses) used to be Objective-C and even they moved it to Java.
As for the GNU Objective-C toolchain, I wouldn't be hugely optimistic about its future, either. Since they moved to GPLv3, Apple has dumped them and built their own Objective-C compilers around LLVM, so those code paths are probably getting a little rusty on the GNU side. GNU "supports" everything under the sun, but the more something gets used the more its implementation gets vetted.
As for the "I've used" bit, yes, I used the Objective-C variant of WebObjects back in the day. It was pretty good for its time, but Objective-C's relatively low-level memory allocation needs and its non-C syntax made it a little awkward. And its strong typing was great for core development but burdensome for the "scripting" aspects of web development.
In the end if a language is Turing-complete you could theoretically do anything in one language you could do in another, but the lack of an ecosystem of libraries for parsers, scripting, database interactions, indexing, etc., means you'll be starting from a pretty deep valley compared to Java or a JVM-compatible language.
There is a javascript framework called Cappuccino that uses syntax very similar to Objective-C they call Objective-J. But as a long-time Cocoa developer, I prefer Sproutcore which doesn't copy Objective-C syntax, but it does borrow some ideas from Cocoa as it was created by former Apple engineers.
If you were thinking server-side development, I guess you could do it but it would probably take less effort to learn some popular server-side language than to get it all up and running with Objective-C
There is Frothkit. However, it hasn't been updated since 2010, primarily because of mature frameworks for other languages like Rails and Django.
Apple's WebObjects was originally an Objective-C platform before it was ported to Java. A sub-project of GNUStep, called GNUStepWeb, aims to be compatible with WebObjects 4.5---the last version to support Objective-C (released in 2000). I'm not sure how complete the implementation is, but there hasn't been much development in over a year.
Apple used to (and still partly does) build their web stuff using WebObjects, which ports the MVC structure and many design patterns of Cocoa apps to a Java-based web-server framework. I recently saw that someone is trying to create a server-side framework with Obj-J called Womble. Looks quite raw still, though. Either way, I'm not aware of a pure Obj-C web-framework implementation...
Related
Years ago wanting to write Mac software and having loads of experience with Java WebObjects I tried the java bridge but decided to bite the bullet and learn Objective-C (fortunately since I would have hated having my software deprecated with the bridge). Later I fooled around with RubyCocoa. I learnt Ruby (found it interesting indeed), but found out the hard way that the bridge was far from mature or stable and at the end I ended porting the code back to Objective-C.
Since years have passed, I'm wondering if it is worthwhile investing some time with MacRuby, or even learning Python to use PyObjC. As much as I like Objective-C, I recall being way more productive with the Ruby bridge when it didn't crash. I just would hate investing time to end up with crashy software again.
I would say MacRuby is the way to go if you want to try one of the bridges. It's being developed by Laurent Sansonetti, who's a Senior Software Engineer at Apple working on Ruby.
It's quite functional now, and integrates nicely with the native frameworks. Worth a look, particularly if you already have Ruby experience.
If you want to learn Cocoa programming, ignore the bridges. They will only make writing Cocoa applications more difficult and you will waste a bunch of time getting up to speed.
Specifically, you will need to learn Objective-C to be able to understand both the APIs and design patterns of the system frameworks. Furthermore, all of the documentation and tools are written specifically to support Objective-C.
The bulk of your time in learning Cocoa programming will be spent on said APIs and design patterns; the actual language part is relatively small, by comparison.
Note also that the bridges necessarily incur an impedance mismatch in an attempt to map not-quite-the-same functionality from one language to another.
Frankly, if you know Ruby, then Objective-C should be trivially easy; the object models are very similar.
My personal opinion is use ObjC for Mac native apps.
Use Ruby/Python where they supposed to work good natively without unreliable interfaces with questionable support.
Here is why it is NOT a waste of time. In some cases, Ruby and Python have awesome and well developed libraries that are not available in Objective-C and would not likely be.
That is one of the best use cases.
Example: you wouldn't want to reimplement Rails in Objective-C, (some people might) but you could easily use it, parts of it to power a Cocoa app with MacRuby.
Well MacRuby is dead. There is the commercial RubyMotion.
There is still PyObjc, RubyCocoa and mruby.
One of the other intriguing use-cases is to provide script ability that doesn't stink like AppleScript and OSA.
There are valid reasons.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I try to be very cautious with this question. There are at least three different web-development frameworks available in Smalltalk. The most prominent seems to be Seaside but there is also AIDA/Web and Iliad.
They seem to be very similiar, but this impresson may be wrong. I wonder who has tried the different tools and can share the pros/cons of the different packages.
A more concrete question would be, do yo know of let's say any software in the bookkeeing area which has choosen to use either of the three (or other) web development frameworks.
Here's one other question. What about maturity and compatiblity. Which framework can one judge as the "most" stable?
99% of my practical experience is with Iliad, so my comparison is primarily about how I got to choose Iliad instead of the others.
Seaside. Tried it first, it is the most known and the first you stumble in. I found it hard to understand (as always, no matter what you use, when it gets to real implementation you always run into issues that fit badly with the general theory), there was little documentation around and the community seemed to care little about telling n00bs how to grow up. I eventually dropped it to check Aida. You find them here: http://seaside.st/ and on IRC at #seaside
Aida. I really liked it, as Janko is extremely patient and supportive. It is large, though. I decided to use it, when I was to start implementation for our project and it was only by chance that I ran into Iliad a few days before starting. You find Aida here: http://www.aidaweb.si/ and on IRC at #Aida
Iliad. The main reason I chose it was that I had just dropped Squeak and switched to gnu-smalltalk. gst seemed to have a lot of ongoing activity on Iliad, so I reckoned I was probably going to get a better assistance with it. It is much smaller as a concept (though it does absolutely everything) and I had very little trouble in getting started and in tweaking it to what I needed for. It also proved to be well managed, as I went thru 3 releases without ever being in trouble with what I had already deployed. You get answers to questions usually in 12-24 hours max, which is fine for me. You find Iliad here: http://www.iliadproject.org/index on IRC issues are usually channeled on the #gnu-smalltalk channel
What we are doing is a GUI for a PostgreSQL database used to manage a large multimedia dictionary, that in turn produces content (among others, for KDE-edu). I have no notion of booking apps in general, so I cannot answer to your question properly.
Yet, speaking as an analyst, a booking app is mostly a DB with an online GUI, so I see no reason why you could not make it. Much will depend on how easily your db can translate into objects. You could use a RDBMS, as we did, and design tables to map objects, or use an OODBMS. Both solutions have pluses and minuses, none of them is going to have an impact on your choice of framework, I'd say.
My suggestion is that you take a month or so in making experiments and see what better fits you. I don't think there is a tool that fits everyone, we are all different and what is easy for me may be hell for someone else (and the other way round, obviously). So try your car before buying it ;)
I would not invest too much time in studying the general theory. Using a smalltalk framework is going to turn upside down the way you make a web app anyway, and your first contact is going to be full of "false friends" you inherit from previous mindsets. Your best asset is definitely going to be "how quick can I grasp what they tell me", and this is largely an individual thing, depending on you and on who you bump into. So I'd really suggest you get your hands dirty BEFORE reading too much theoretical stuff.
These frameworks are all quite different and have different goals. It would be interesting to collaboratively create some kind of comparison.
As an author of Seaside I can provide the key properties of Seaside only:
Seaside makes building web applications feel like composing traditional GUIs: components can be freely composed and reused. Sequences of components are defined using a sequence of Smalltalk statements.
Seaside has a layered architecture, providing you with high-level abstractions (components, control flow, callbacks, HTML generation, JavaScript generation, ...) over low-level concepts (HTTP, Request, Response, URLs, HTML, JavaScript). If you need to, Seaside gives you full access to low-level constructs too.
There are two Seaside books to help you get started: Dynamic Web Development with Seaside and Seaside Tutorial.
Seaside provides a tight integration into various state of the art web technologies: JavaScript (JQuery and JQueryUI), SVG, RSS, HTML5, Comet (Server-Push)
Seaside runs identically on most today's Smalltalk platforms: Pharo Smalltalk, Squeak, GNU Smalltalk, GemStone Smalltalk, VW Smalltalk, VA Smalltalk, and Dolphin Smalltalk. It is supported by all vendors of Smalltalk platforms.
Seaside provides industry proven open-source components for meta-modeling (Magritte) and content management (Pier).
Let me introduce some strengths of Aida/Web too, because as its author it would be hard to me to compare with other two frameworks. Aida strengths are:
RESTfull URLs
MVC support, every domain object can
have its own RESTfull URL, each domain class has its own web presentation class,
Integrated AJAX and Comet
support, you don't see any difference
between a traditional and Ajax
programming anymore,
Tree-like control flow for GUI-like
control flows, without need for
continuations
Building web pages programatically by
composing from components/elements
(no template based)
Scalable in complexity and performance
Integrated security with access
control and users/groups management
Ported to most Smalltalk dialects:
Squeak/Pharo, VisualWorks, Gemstone
GLASS, Dolphin, Smalltalk/X
Prime and most fresh example of Aida at work is this year Smalltalk Google Summer of
Code site.
This is the is a nice example because it was developed it in maybe a week in
total, together with a development of GSoC process in parallel and in
the same time managing that process as an admin. This site is actually
an extended Aida/Scribo CMS, with strong use of so called scriblets,
that is, dynamic web "includes" directly into the content of the site.
That way I was able to very quickly support the new ideas which come
during the evolving GSoC process.
Well, Suixo uses Seaside. Take a look at the GSoC projects we defined. Its more ERP than bookkeeping, and currently focused on healthcare.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have heard mention of Objective-C but I have never used it myself. I was curious what everyones opinion of it was in general and also in relation to C++. Are there any types of projects where it would be more useful or less useful?
Like many others I've just started looking at Obj-C due to iPhone. I've done a lot of C++ and C# and from what I can see Obj-C has a basically different approach to OO in that it adds Smalltalk-like messaging to C. Like C++ it's basically still C-compatible but the OO extensions let you send any message to any object. In that sense it's not statically typed like C++ and C# where the things an object can do are tied to the class it is. In Obj-C you can send a message to an object even if it doesn't support it. The object can then forward it if it doesn't know what to do with it.
The really cool thing is that you can add interfaces (protocols) at runtime and you can add your own handlers that intercept and hide message handlers for existing classes.
All in all there's a lot more flexibility when it comes to message handling, more like what you would do in Ruby or Smalltalk. Whether it's a good idea to have this type of OO grafted onto C or not I can't tell yet, in some ways the C++ approach meshes better with the original idea of C but on the other hand the Obj-C OO approach is more what OO purists like.
From "Some nice features of the Objective-C language":
Classes are objects
Dynamic typing and optional static typing
Categories
Message sending
Expressive message syntax
Introspection
Dynamic run-time
Automatic garbage collection
C inside
C++ fluent
Simplicity
Access to Apple technologies
I find objective-c's syntax a little cleaner than c++'s although I know I'm in the minority here
Objective C's OO features use dynamic typing instead of static (compile-time) typing. That's the major difference in the approaches of the two languages - whether it's an advantage or not depends on your opinion about static vs. dynamic typing.
My opinion is that the syntax of Objective-C is a little "weird" at first, particularly if you are coming from a C/C++ background (as I did). If you plan to write apps for the Mac or iPhone, Cocoa development is the way to go. I had an opportunity to do some development on the Mac for about a month this Spring and opted to write it in C++ using the Qt libraries since I was quite familiar with those and time was of the essence.
If you have a Mac, give it a shot! There is a LOT of info out there on it and there are some good tools for development.
Part of what makes Objective-C so great isn't the language (although that is a big part ot it), it's the Cocoa (or CocoaTouch) framework that goes along with it (at least for 99% of objc users ;-)
In practical terms, I used to be a C++ programmer back in the old "classic" Mac days. Switching to Objective-C, Cocoa and Mac OS X i found I became much more productive. Hard to say exactly how much more productive, but 50% to 100% feels right.
If you're running Linux you can install GNUStep which provides pretty good compatibility with Cocoa. This can get you started on Objective-C/Cocoa development without owning a Mac. The best resources for learning Objective-C [in my opinion] are with Apple.
http://developer.apple.com/referencelibrary/Cocoa/index.html
Well, If you are coding for the some platforms like the IPhone, Objective-C is required. Objective-C also uses dynamic(run-time) typing, which many people prefer over static(compile-time).
WebKit was originally a C++ project (khtml from KDE) that was later adapted by Apple to be more compatible with the Cocoa-environment and thereby got its Objective-C layer.
It is more dynamic than C++ and heavily influenced from Smalltalk. I don't find it "better" than C++ - on the contrary, but some people do.
For Mac and iPhone development, it is definitely better. The latest version has a GC, so if you like that, you'll probably like it better than C++.
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 3 years ago.
Improve this question
Do I really have to learn Objective-C to develop solid Mac Apps?
As Mac users tend to use only applications that have a nice (native) GUI, i don't think that Mono and GTK+ or any Java GUI (Swing) will fit their needs.
There are projects like Cocoa#, PyObjC and RubyCocoa, but are they ready for primetime?
So do I really have to learn Objective-C ?
I would prefer a dynamic language.
Objective-C is a dynamic language, as far as the Objective-C parts go. Here's a little summary article: http://www.macdevcenter.com/pub/a/mac/2003/04/28/objective-c.html
The syntax is scary at first, but it grows on you. I suggest biting the bullet and slogging through it.
If you want to work at a "real job" doing Mac programming with other people, you're going to need to know Objective-C (in my opinion, anyway).
I think the short answer is yes, you need to learn Objective-C.
The Python and Ruby "bridges" work, but it's not what Apple is pushing or using itself. A few years ago there was a Java bridge to Cocoa but that's now deprecated. Who knows what will happen to the non-ObjC languages?
In any case, Objective C is pretty dynamic. Not in the way that Ruby/Python are perhaps, but it's certainly not like C++.
Short answer: YES :)
Our first app was built in Python, using the PyObjC bridge. From experience I can tell you that to build an application with a bridge you need to learn:
The idiosyncrasies of the bridge
To read and write code in the bridge language (Python in my case)
To read code in Objective-C (All useful sample code is in Obj-C)
To write pseudo-code in Objective-C (if you ever want to ask questions on a mailing list or likewise)
Cocoa
Of all those things to learn, Cocoa is the biggy. It's where the really interesting stuff comes in and the thing you really need to wrap your brain around. After working on this PyObjC project, it's become pretty easy for me to code in Obj-C, even though I had no prior experience coding in C.
So my advice is: Focus on learning Cocoa, and use the language that's most suited as a tool to do that (Obj-C). If you ever find a particular reason to use a bridge, such as having a need for an ORM that can deal with networked SQL, etc. you can apply around 90% of what you learned writing your first Obj-C/Cocoa app(s) in the bridged project.
Finally: I don't really understand the resistance many people who're new to the platform have to learning Objective-C. Isn't it exciting and gratifying to learn new stuff and build the best possible things armed with this new knowledge?
You definitely need to learn Objective-C even if you choose to use one of the bridges. Apple has already shown by their treatment of Java that they're not really interested in providing huge amounts of support or backwards compatibility to the use of Cocoa through anything but Objective-C.
So use one of the bridges, if you like, but have a firm grasp of the Objective-C runtime and the bridges so that you can manage them yourself, if need be.
Do I really have to learn Objective-C to develop solid Mac Apps?
Currently, yes.
As Mac users tend to use only applications that have a nice (native) GUI, i don't think that Mono and GTK+ or any Java GUI (Swing) will fit their needs.
Correct.
There are projects like Cocoa#, PyObjC and RubyCocoa, but are they ready for primetime?
Cocoa#: I don't know, as I don't use C#.
PyObjC: Sort of, but Cocoa in Python is a bit of a hack, since Python isn't Smalltalky enough.
RubyCocoa: Maybe. I'm waiting for MacRuby to mature, though. See also:
Jens Alfke on MacRuby
Jesper on MacRuby
There are a small number of successful Cocoa apps written in bridged languages, so you don't necessarily need to use it that much, but you do need to learn it. People who try to learn to write Mac OS programs in bridged languages do themselves a huge disservice. The bridged languages are great tools, but they are the sort of things that allow someone with a knowledge of the bridged language and Objective C to become extra productive, not skip learning Objective C.
In order to use something like PyObjC or MacRuby effectively you need to really have a good understanding of how the native runtime works to deal with all the impedance mismatches that can occur between the bridged language and the Objective C runtime.
Short answer is yes, longer answer is "you can use Objective-C++." Either way you're going to have to learn at least some of Objective-C. Once you start digging into Cocoa (the framework for building Mac OS X apps), the Xcode tools, and the Apple Human Interface Design guidelines, you'll realize that Objective-C is the way to go.
Not only you have to know Objective-C (the easy part), you must be very comfortable with plain old C. That's in my opinion the biggest challenge for most people.
If you already know C, Objective-C is pretty easy to learn.
Ruby and Python are both viable for "real" Mac apps. ADC has a few articles on the topic. MacRuby looks like it will be replacing RubyCocoa.
I would still recommend learning Objective-C though. Most of the example code you find will be in Objective-C and the books tend to be Objective-C (though the Pragmatic Programmers have a RubyCocoa book in the works. Most Cocoa apps are written in Objective-C.
And Objective-C is dynamic. Take a closer look at it, it isn't nearly as intimidating as people think. It's Cocoa that tends to have the steeper learning (or unlearning) curve.
No you don't have to learn cocoa however it is worth looking at because it is an incredibly powerful api and very well documented, if you already know C then its very easy (honestly it is - i know it looks daunting syntactically).
The problem with the bridged approach on OS X is it seems to be very immature and only really designed for people who are prepared to read the documentation associated with the main cocoa api.
In all honesty if you know c you will pick up the basics of obj-c with a book, the one by Arron Hilligas (spelling?!?!) is superb.
If you try hard enough, you can go about producing software without using Objective-C that has the potential to be great except for the fact that at the end of the day it won't be very good. You will spend more time trying to harangue a language into doing something that it isn't the absolute best at. At WWDC I wore a shirt that said "Learn Objective-C or Retire" which didn't go over too well with some people who still held dearly onto the last threads of Pascal's life, but the point is altogether true - Objective C is where it's at on the Mac and to pretend otherwise is to do yourself a disservice.
Having said that, you should definitely not rule out the bridges on the platform for extending your application - Bill Bumgarner is quick to point out how much power the Twisted networking framework provides to Cocoa applications via the PyObjC bridge.
Not programming in a scripting language turns out to not be so bad when you're using XCode. The GDB integration is very good; I'm primarily a Perl guy, and I find the XCode debugger very nice and very easy to use.
The "fix" feature will really surprise you with how usable it is. Imagine finding a bug in your ObjC code, fixing it, and then telling the debugger to continue on. It actually works in a lot of cases.
Try ObjC. You may find you like it a lot better than you think you will.
"have to", well... technically, no.
Since most Mac app jobs are done thro ObjC (for a very good reason I might add), I wouldn't kid yourself and learn it.
Hell no. You can use a number of languages to make a nice GUI with. It just depends on what's the usual/easiest solution for the platform. In Mac OS X's case, Objective-C and AppKit are pretty easy to use choices. However, I use REALBasic sometimes, and that allows cross platform development (and, of course, a performance hit).
So really it depends on how much work you want to put into it. You should learn Objective-C if you want to really do serious Mac development. But you can get by without it....
No. While Apple is strongly pushing Cocoa, Carbon is still supported. It uses plain C instead. As for good-looking GUIs, just use Interface Builder.
However, I must say that Objective-C is a great language. It is really easy (it was my first language) and very powerful.
In general yes; but even if you (correctly IMHO) ruled out Mono, GTK and SWING because they don't fit well in the GUI, try Qt. it's REALLY respectful of Mac GUI standards (HIG: Human Interface Guidelines), and can be equally programmed on C++, Python and Java. the last version is cocoa-based and 64-bit capable.
the only thing missing from Qt that you'd get from Objective-C is those awful non-HIG-compliant modern Apple applications (yeah, Aperture and Final Cut, I'm looking at you!)
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
Has anyone here given the Fantom programming language a whirl? (pun intended).
My first impression:
I like the ability to have the code run on either the .NET or Java VM.
The syntax is nice and clean and does not try anything fancy.
I have a belief that "the library is the language" and the developers of Fan believe that their USP is their APIs:
But getting a language to run on both Java and .NET is the easy part - in fact there are many solutions to this problem. The hard part is getting portable APIs. Fan provides a set of APIs which abstract away the Java and .NET APIs. We actually consider this one of Fan's primary benefits, because it gives us a chance to develop a suite of system APIs that are elegant and easy to use compared to the Java and .NET counter parts.
Any other thoughts, first impressions, pros and cons?
It looks very inspired by Ruby. It says that it's RESTful but I don't see how exactly. Compare with boo, which is more mature yet similar in many ways (its syntax is Python inspired, though).
The design decisions to keep generics and namespaces very limited are questionable.
I think their explanation sums it up:
"The primary reason we created Fan is
to write software that can seamlessly
run on both the Java VM and the .NET
CLR. The reality is that many software
organizations are committed to one or
the other of these platforms."
It doesn't look better than all other non-JVM/.NET languages. In the absence of any information about them (their blog is just an error page), I see no reason why they would necessarily get this righter than others. Every language starts out fairly elegant for the set of things it was designed for (though I see some awkwardness in the little Fan code I looked at just now) -- the real question is how well it scales to completely new things, and we simply don't know that yet.
But if your organization has a rule that "everything must run on our VM", then it may be an acceptable compromise for you.
You're giving up an awful lot just for VM independence. For example, yours is the first Fan question here on SO -- a couple orders of magnitude fewer than Lisp.
For what problem is Fan the best solution? Python and Ruby can already run on both VMs (or neither), have big communities and big libraries, and seem to be about the same level of abstraction, but are far more mature.
I have never heard of Fan until a couple of weeks ago. From the web site, it is about one year old so still pretty young and unproven. There are a couple of interesting points however: First the language is tackling the problem of concurrency by providing an actor model (similar to erlang) and by supporting immutable objects. Second, the object follows the example of Scala with type inference. Type inference allows the programmer to omit type declarations but have it computed by the compiler providing the advantage of short and cleaner code as in a dynamically type language while preserving the efficiency of a statically type language. And last, it seems like a very fast language, nearly as fast as Java and really close or beating the second fastest language on the JM: scala. Benchmark showing the performance can be found at http://www.slideshare.net/michael.galpin/performance-comparisons-of-dynamic-languages-on-the-java-virtual-machine?type=powerpoint.
This is very interesting.
Java (or C#) was created in order to eliminate Platform dependency by creating a JVM (or CLR) that will compile the code into a specific machine code at run time.
Now , There is a languege which is Virtual Machine independent? umm .... what the hell?!?!
Again , this is a very interesting topic , That might be the future...:) going to one universal single languege
I think it looks like a great language feature-wise, but I'm not sure how useful it is. I don't think it is all that useful to target .NET and JVM. Java is already cross-platform, and .NET is too, with Mono. By targeting two VMs, you have to use only the APIs that are available on both. You can't use any of the great native APIs that are available for Java and .NET. I can't imagine that their API is anywhere near as complete as either Java's of .NET's.