What do Mac Programmers Prefer?
Noble
and using Dos/Windows for over 25 years and thought that it was
finally time to give the Mac a try. I love it to say the least.
I have a question. I have bought and been using REALbasic for the Mac.
I have been using it for about 6 months now. Though its alright I was
wandering what most programmers prefer to use to write their Mac
software? Java? Objective-C?
Thanks for your help.
nb
silverdr
> I was
> wandering what most programmers prefer to use to write their Mac
> software? Java? Objective-C?
The term "most programmers" is probably a weak point here (who gathers
and statistically processes such data?) but judging by the number of
successful and appreciated applications being written in Obj-C, I'd vote
for Obj-C, even if it may not relate properly to what "most programmers
prefer".
Robert Welz
C/C++ aka the Carbon Framework, ObjectiveC for easyness, QT for platform
independance, wxWidgets for platform independant shareware.
Robert
--
Demütigungen und Absagen bei Bewerbungen bitte unterlassen. Wir ham
jetzt Geld wie Heu. (bildlich gesprochen: Wieso soll ich meinen Heuhafen
verlassen, für Schrott, der nichts taugt????????? )
Gregory Weston
Noble <Nobl...@gmail.com> wrote:
I thought this was going to be a soft drink poll. Early on, for example,
Mountain Dew was documented to be a popular choice. It was deemed to
follow the WYSIWYP ideology of the Mac. Never could stand it myself,
though. I was a Coca-Cola traditionalist until I gave up caffeine and
then sugar.
For serious software development, the overwhelming choice is a
combination of Carbon and Cocoa using C and/or C++ and Objective-C. The
mix varies by product and developer. It's difficult to write anything
substantial without using Carbon (which means some procedural code) but
for the things that Cocoa does provide, it's a big help.
This is not to say that serious development isn't or can't be done with
other tools; only about answering your question of what _is_ used. As
long as the tools are actually capable of producing the results you
want, there's a lot to be said for working with what you're comfortable
with. Learning new tools is a good idea because it gives you more
choices and frees you from the limitations of any single option.
Robert Welz
Hello!
Do you know someone with a job for an experienced Mac Programmer? My job
offer was cancelled. It was maybe that it was too expensive to get me to
Antwerpen? My normal rate is 35 tsd EUR, not 70000 EUR like the offer I
had, which was cancelled anyway. I have a top testemonial, certificates
but unfortunately I cannot find a job since 5 Jears.
My preferred languages are C/C++ and ObjectiveC.
But please, no tests, no psychological thinbums; instead I offer my
experience. I must be possible for me to find my income with Mac
Developing.
PS.: I've got some ServerCertificates in email and IT forensic as well
as a solid understanding of software engeneering.
I could imagine that an employer would be contempt if, I on my side
would offer 6 months "hire an fire" on a daily base (sorry english is
not my native language) if he/she can do without tests or the like.
I put this puposely on the web, maybe I find a job as pure Mac
Developer.
Thanks very much for the help on the list and Good Bye!
Robert
Robert Welz
Hello!
Do you know someone with a job for an experienced Mac Programmer? My job
offer was cancelled. It was maybe that it was too expensive to get me to
Antwerpen? My normal rate is 35 tsd EUR, not 70000 EUR like the offer I
had, which was cancelled anyway. I have a top testemonial, certificates
but unfortunately I cannot find a job since 5 Jears.
My preferred languages are C/C++ and ObjectiveC.
But please, no tests, no psychological thinbums; instead I offer my
experience. I must be possible for me to find my income with Mac
Developing.
PS.: I've got some ServerCertificates in email and IT forensic as well
as a solid understanding of software engeneering.
I could imagine that an employer would be contempt if, I on my side
would offer 6 months "hire an fire" on a daily base (sorry english is
not my native language) if he/she can do without tests or the like.
I put this puposely on the web, maybe I find a job as pure Mac
Developer.
Thanks very much for the help on the list and Good Bye!
Robert
Mannheim
Germany
Noble
familiar with C. May main concern about asking this question in the
first place is the fact that I know and use Java and I have had people
tell me that Java programs running on a Mac people tend to shun. Is
this true? I am just trying to find the best way to utilize my Java
crossplatform skills to develop shareware and freeware that will run
on Mac, Pc, and Linux.
Thanks for all your input. I really appreciate it.
nb
silverdr
> [...] It's difficult to write anything
> substantial without using Carbon (which means some procedural code) but
> for the things that Cocoa does provide, it's a big help.
I am not sure if I understand this sentence correctly - could you rephrase?
Gregory Weston
silverdr <silv...@inet.pl.remove.it> wrote:
Yeah, I see how that could be a tough read. Keep in mind that the
context is the prior statement about most Mac development being done in
a combination of Carbon and Cocoa.
Writing substantial, conformant Mac OS software without using any part
of the Carbon API is virtually impossible. There are a number of fairly
important elements of the Mac OS user experience for which Cocoa
approaches either don't exist, have major shortcomings, or are
gratuitously resource-intensive.
On the other hand, you _can_ write a Mac application that meets user
expectations without going anywhere near Cocoa. It's just not not an
approach that I'd recommend unless you have really specific need to go
that route. The "it" in the last clause of what I wrote before is
"Cocoa." So that sentence should be read as: "When a Cocoa approach is
available it's typically worth pursuing."
Gregory Weston
Noble <Nobl...@gmail.com> wrote:
> Interesting indeed. I am not that upto speed with C++. I am more
> familiar with C. May main concern about asking this question in the
> first place is the fact that I know and use Java and I have had people
> tell me that Java programs running on a Mac people tend to shun. Is
> this true? I am just trying to find the best way to utilize my Java
> crossplatform skills to develop shareware and freeware that will run
> on Mac, Pc, and Linux.
There are two aspects to this.
The first is that there is a subset of the Mac user community that's
oddly persnickety about the development tools used to create their
software. They somehow get the notion that software created with "this
tool" is somehow inherently inferior and shouldn't be used. This extends
to the point where if they find out that a program they've been using
was created with "inferior" tools they will suddenly become dissatisfied
with it.
Happily, these people are rare.
Much more common, though, is that Mac users can get persnickety about
the behavior of the software they're using and it's fairly well
justified. One of the major historical benefits of the Mac as a
mainstream tool is consistency of interface and the ability to leverage
knowledge and experience from one application to other tools. One
recurring drama that has happened in the world of Macintosh software is
the major vendor who decides they'd like to go after the Mac market and
then does just enough work to get their Windows product to compile as a
Mac app. They'll ship it, it'll be roundly rejected by the community
because it's virtually unusable - meaning prior knowledge _can't_ be
leveraged - and then the product will be cancelled, along with a press
release from the company claiming that there's really no meaningful
market for Mac software.
Getting a Java program to look and act like a Mac program _can_ be done
- and when it is done most people won't have a problem with it - but
it's more work than most people seem to be willing to put into it. And
it's most likely in that context that you were told that Mac users avoid
Java solutions. They don't, really. They just avoid things that don't
fit into their workflow.
Tom Harrington
Objective-C and C. Cocoa where possible, otherwise Carbon, CF, BSD
and/or AppleScript as appropriate to the situation.
--
Tom "Tom" Harrington
MondoMouse makes your mouse mightier
See http://www.atomicbird.com/mondomouse/
silverdr
> Writing substantial, conformant Mac OS software without using any part
> of the Carbon API is virtually impossible. There are a number of fairly
> important elements of the Mac OS user experience for which Cocoa
> approaches either don't exist, have major shortcomings, or are
> gratuitously resource-intensive.
Would you give some, e.g. most common or "spectacular" examples. Honest
request, I am not nitpicking here ;-)
> On the other hand, you _can_ write a Mac application that meets user
> expectations without going anywhere near Cocoa. It's just not not an
> approach that I'd recommend unless you have really specific need to go
> that route. The "it" in the last clause of what I wrote before is
> "Cocoa." So that sentence should be read as: "When a Cocoa approach is
> available it's typically worth pursuing."
That explains - thanks.
Robert Welz
The best counterexample is JXExplorer, the Java based LDAP Browser. The
Graphical User Interface seems to loose refresh sometimes, so you end up
with a plane white window but it is still fully functional (although you
cant see the buttons anymore).
Standard is C++ for heavy weighted applications. You could give QT (
www.trolltech.com ) a try. I looked at the Mac Demo applications and
they work excellent. I did some learning Linux Programming in QT and it
was straight forward. The C++ learning curve is not so hard as you may
think since you are already familiar with the concepts.
I have a small C++ book with 150 ready to compile C++ source files,
commented and written for beginners to advance to an intermediate level.
The advanced and highly sophisticated stuff comes automagically, as soon
as you need it ( f.e. abstract classes, templates ).
And it would be nice to see a QT Application on the market here since
germany at the moment works like "kraut and carrots": We have a lot of
small Windows companies and when the market share gets low they cry
"lets try our Program/Product" on the Mac.
So if you are the Mac Programmer then you have to start from nothing and
you need soooo much time to implement the Graphical Userinterface and
end up with no earnings but double work to "meet the train" with the
windows application.
Trolltech is free for shareware programmers but has a commercial
license, but it is foar more better than the rest of the cross plattform
development frameworks.
I once did exactly what I wrote here, I worked for spheronvr, which
exactly had the same problem. After half a year of an 1 hour/day during
my studies I had to move to a company with a different focus. But QT
here has the chance to create many jobs if and only if we could make the
Windows folks looking for "Cross Platform Development and there C++ is
far superior compared to Java. (Its even faster!).
If you like, I can send you a copy of this book, since I own the license
so you can get a quick entry into C++.
And in case of questions I will stay here on the list.
Maybe somebody has an opportunity to host the book in ZIP Format
somewhere? I have no webserver at the moment.
Robert
Don Bruder
Well, I can't speak for anybody else, but it's always been my personal
bias (and, unfortunately, experience) that if it's Java, it's
slow-motion junk. So yes, THIS person, at least, shuns Java.
As for my own coding work, I go with probably 90% C under Carbon, and
I've recently started experimenting (with only slight success...) with
Objective C under Cocoa, and can function in Python - if I absolutely
have to...
--
Don Bruder - dak...@sonic.net - If your "From:" address isn't on my whitelist,
or the subject of the message doesn't contain the exact text "PopperAndShadow"
somewhere, any message sent to this address will go in the garbage without my
ever knowing it arrived. Sorry... <http://www.sonic.net/~dakidd> for more info
Lothar Behrens
> C/C++ aka the Carbon Framework, ObjectiveC for easyness, QT for platform
> independance, wxWidgets for platform independant shareware.
>
You also could write commercial software with wxWidgets !
Lothar
Lothar Behrens
> C/C++ aka the Carbon Framework, ObjectiveC for easyness, QT for platform
> independance, wxWidgets for platform independant shareware.
>
You also could write commercial software with wxWidgets.
Lothar
Steven Fisher
Gregory Weston <u...@splook.com> wrote:
> Getting a Java program to look and act like a Mac program _can_ be done
> - and when it is done most people won't have a problem with it - but
> it's more work than most people seem to be willing to put into it. And
> it's most likely in that context that you were told that Mac users avoid
> Java solutions. They don't, really. They just avoid things that don't
> fit into their workflow.
Can you give an example? I agree it's probably possible, but I've never
seen it actually happen. Of course, if it was actually done to a high
enough standard, I would not realize I was seeing it...
Lothar Behrens
> independance, wxWidgets for platform independant shareware.
>
You also could write commercial software with wxWidgets !
Lothar
Gregory Weston
silverdr <silv...@inet.pl.remove.it> wrote:
> Gregory Weston wrote:
>
> > Writing substantial, conformant Mac OS software without using any part
> > of the Carbon API is virtually impossible. There are a number of fairly
> > important elements of the Mac OS user experience for which Cocoa
> > approaches either don't exist, have major shortcomings, or are
> > gratuitously resource-intensive.
>
> Would you give some, e.g. most common or "spectacular" examples. Honest
> request, I am not nitpicking here ;-)
Off the top of my head, Cocoa-based context menu plugins and iTunes
plugins are very tough. There's no general Cocoa replacement for
Gestalt. There's almost nothing for dealing with FSRefs or Aliases. No
notification manager. Manipulating preferences of other processes has
some gotchas (this might be the sort of a thing a prefPane would do
acting as the config interface for a background process). Doing anything
serious with QuickTime. No real replacement for the process manager.
Parts of some of these are addressed if you're willing to declare 10.4
as a minimum system requirement.
G
Gregory Weston
Steven Fisher <st...@pyile.com> wrote:
Largely it is, I think, a matter of "close enough." People appreciate
when someone clearly tried even if they don't succeed 100%. It's not
like you're guaranteed 100% even from a solution that is native, after
all.
I use GanttProject: <http://ganttproject.biz/>
I have seen recommendations for MoneyDance, even though I'm not
especially fond of it: <http://www.moneydance.com/>
They're clearly not Mac-native programs, but the authors also clearly
made at least an attempt to do it right.
Michael Ash
> Gregory Weston wrote:
>
>> Writing substantial, conformant Mac OS software without using any part
>> of the Carbon API is virtually impossible. There are a number of fairly
>> important elements of the Mac OS user experience for which Cocoa
>> approaches either don't exist, have major shortcomings, or are
>> gratuitously resource-intensive.
>
> Would you give some, e.g. most common or "spectacular" examples. Honest
> request, I am not nitpicking here ;-)
Try doing anything interesting with audio and you'll find that you have to
depart the home nest pretty quickly. Cocoa itself can beep or play audio
files and that's it. If you count QTKit you can do some fancier playback,
but even then you hit limitations pretty fast. Even something as simple as
displaying the QuickTime export configuration window is impossible using
pure QTKit.
Video input basically requires QuickTime. I believe it's possible to do it
in a basic fashion by using a Quartz Composer patch, but then there's no
way to let the user choose or configure the input source.
3D graphics means OpenGL. While not Carbon, it's not Cocoa either.
My opinion is that you should learn Cocoa but keep an open mind. Always
think, "how can I do this in my app?" rather than asking, "how ccan I do
this in Cocoa?" the way so many people do. There are places where they
don't mix, but for the most part a Carbon solution will work in a Cocoa
apap. I personally don't know how to do simple stuff in Carbon like
showing a window, reacting to a clicked button, etc., but I learn what I
need when I need it and I don't shy away from any of the non-Cocoa APIs,
whether it's Carbon, QuickTime, OpenGL, POSIX, etc.
--
Michael Ash
Rogue Amoeba Software
Robert Welz
I did it half a year as a scientific co-worker at Professor v.Puttkamers
working group at University Kaiserslautern which himself was the chief
of the only Apple Department I have seen there. I did this on windows
and I didn't like it for several reasons:
1. No community, at least in Kaiserslautern,
2. I left Kaiserslauten the as soon as possible since it was a boring,
stupid town.
3. No books to learn available. QT has several books for beginners. Its
nonsense for a commercial development if you can't read at least 2
different books about just to hear someone else's opinion.
I wouldn't use it since I tend to runaway if I really can't stand
something.
Robert
--
a
silverdr
[...]
>>> important elements of the Mac OS user experience for which Cocoa
>>> approaches either don't exist, have major shortcomings, or are
>>> gratuitously resource-intensive.
>> Would you give some, e.g. most common or "spectacular" examples. Honest
>> request, I am not nitpicking here ;-)
>
> Try doing anything interesting with audio and you'll find that you have to
> depart the home nest pretty quickly. Cocoa itself can beep or play audio
> files and that's it. If you count QTKit you can do some fancier playback,
[...]
> My opinion is that you should learn Cocoa but keep an open mind. Always
> think, "how can I do this in my app?" rather than asking, "how can I do
> this in Cocoa?" the way so many people do. There are places where they
> don't mix, but for the most part a Carbon solution will work in a Cocoa
> apap. I personally don't know how to do simple stuff in Carbon like
> showing a window, reacting to a clicked button, etc., but I learn what I
> need when I need it and I don't shy away from any of the non-Cocoa APIs,
> whether it's Carbon, QuickTime, OpenGL, POSIX, etc.
Well, I am far from saying or even thinking that Cocoa is THE way to go
always. Surely I'd prefer to avoid mixing APIs / libs for various
reasons but if that can help without hurting the users, I can wrap in
even some bash or Ruby scripts. My question comes rather from curiosity
of what may I expect on my Cocoa adventure and where to refrain from
wasting time on searching for Cocoa solutions. Both your and Gregory's
posts give me some peace of mind though as most of the things you both
mention are not very close to my core interests.
As for Quicktime - I heard some rumours that it is on the way out and
should be replaced "soon" with something more palatable to Cocoa fans
;-) This of course would mean that apps using this new stuff would
possibly run something like 10.6 and up only ;-)
Paul Floyd
> I have been using it for about 6 months now. Though its alright I was
> wandering what most programmers prefer to use to write their Mac
> software? Java? Objective-C?
C++, Qt, Boost.
A bientot
Paul
Patrick Machielse
> I have a question. I have bought and been using REALbasic for the Mac.
> I have been using it for about 6 months now. Though its alright I was
> wandering what most programmers prefer to use to write their Mac
> software? Java? Objective-C?
If you want to target Mac OS X, learn to use the Cocoa framework. This
means that you will need to learn C and Objective-C. When Leopard ships,
you'll be able to use Python and Ruby as well (supported by Apple).
Java is always an option. The language is OK, although it always feels a
bit restrictive if you're used to Objective-C, or even C. About 50% (I
exagerate) of the API seems to be deprecated, which is a pretty bad
statistic when you consider that Java is much newer than Cocoa. Creating
good gui's is possible, but requires a lot of work compared to Cocoa.
If it is your goal to write cross platform software, REALbasic may not
be such a bad choice. I used it many years ago, and even then it mostly
delivered on its promise.
patrick
Gregory Weston
silverdr <silv...@inet.pl.remove.it> wrote:
> As for Quicktime - I heard some rumours that it is on the way out and
> should be replaced "soon" with something more palatable to Cocoa fans
> ;-) This of course would mean that apps using this new stuff would
> possibly run something like 10.6 and up only ;-)
It seems very unlikely that QuickTime as a toolset is on its way out.
Possibly what you heard is a handed-down reinterpretation of the release
and possible future development of QTKit (which is, though still limited
today, leaps and bounds beyond the previous support for QT in Cocoa).
Lothar Behrens
> I wouldn't use it since I tend to runaway if I really can't stand
> something.
>
I didn't force you to use wxWidgets. It's your desicion what to be
used. But no community may be wrong.
At least the developers of the wxMac version do answer your questions
in the wxwidgets news group.
They also have a book about wxWidgets - at least since some time.
Ok, QT is also a good choice, but I don't like to pay any more for
software development stuff if there are
usable alternatives.
But I also didn't like to use wxWidgets only - it's my design of my
project to avoid too close coupling to it.
Lothar
> Robert
>
> --
> a
Robert Welz
Yes, and I like "Designing Databeses for Mere Mortals" and nobody uses
it. It worked through 1/2 a year and find no job?
Personally I think for commercial software developing for which time is
cruical it is good to have personal support. And free support, well,...
wxWidgets is not bad but not my flavor.
Greetings,
Robert
--
a
Robert Welz
Yes, and I like "Designing Databeses for Mere Mortals" and nobody uses
it. It worked it through 1/2 a year and find no job?
Personally I think for commercial software developing for which time and
money is
Robert Welz
Yes, and I like "Designing Databeses for Mere Mortals" and nobody uses
it. It worked it through 1/2 a year and find no job? Its fine for big
databases for 100eds of users with mySQL and Postgres.
Gabriele Greco
> I have a question. I have bought and been using REALbasic for the Mac.
> I have been using it for about 6 months now. Though its alright I was
> wandering what most programmers prefer to use to write their Mac
> software? Java? Objective-C?
Actually as multiplatform programmer I stay as far as possible from
Objective-C and Cocoa, also if I understand that "real" mac apps need
at least a cocoa interface.
I've used SDL for two C++ commercial games I ported (I also made the
linux port, www.ankh-game.com is one) and I've used GTK for a few GPL
apps I wrote ( http://ggmud.sourceforge.net is one for instance).
Maybe I'll use wxWidgets or QT in future but I'll stay away if possible
from Cocoa stuff mostly because I hate Objective C syntax :)
I've written a Carbon updater for the Mac version of ankh and I've had a
lot of problem with objects like fsref or pascal strings, stuff that on
other platform you can resolve with a plain std::string, so my approach
to mac GUI programming hasn't be that good :)
Beside that I still have a lot of problems to use autoconf/automake with
objc++ files (mostly because of the extension .mm that is not recognised
by autoconf)
Bye,
Gabry
Robert Welz
> Hello, I am a new Mac user (less than a year). I have been programming
> and using Dos/Windows for over 25 years and thought that it was
> finally time to give the Mac a try. I love it to say the least.
>
> I have a question. I have bought and been using REALbasic for the Mac.
> I have been using it for about 6 months now. Though its alright I was
> wandering what most programmers prefer to use to write their Mac
> software? Java? Objective-C?
>
> Thanks for your help.
> nb
Besides, I say: Since the Mac has the API with Documentation twice the
size of Windows it would be cheaper the develop on the Mac first than
port to windows than develop on windows first and port to mac.
I am really trying hard to postulate a way to confirm a Windows Hardware
developing Company who never had or evangelized Macs as development
platform.
Since the usual way is develop on Windows first, then, if at all get it
eventually on the Mac it would be cheaper to develop in some platform
independend framework. Can I say that or would someone strongly say that
this is not true? I guess not. I am convinced. But , when I start such a
project, I don't want get my asbestos underpants heated by flames from
the Mac Community.
So lets discuss this first, before my underpants get burned;)
Greetings,
Robert
--
a
Michael Ash
> Since the usual way is develop on Windows first, then, if at all get it
> eventually on the Mac it would be cheaper to develop in some platform
> independend framework. Can I say that or would someone strongly say that
> this is not true? I guess not. I am convinced. But , when I start such a
> project, I don't want get my asbestos underpants heated by flames from
> the Mac Community.
Is it cheaper to develop with some platform-independent framework? Almost
certainly. I'm pretty sure that Qt or WxWidgets or whatever you use will
not be any harder to develop with than using a native Windows API, so you
can use that to make your Windows version, and then you get a Mac version
for nearly free.
But that's a bad question to ask. What you need to ask is whether it's
*worth* using such a framework. My answer to that one is an absolute no*.
Applications written with such a framework universally look and act badly
on the Mac. We've discussed this before in this group with some people
claiming that you can get very close, but when asked for an example, the
example is never anything I would consider acceptable.
In conclusion, you can use a cross-platform GUI framework to make a Mac
version of your application very cheaply, but unless you have a captive
audience, you shouldn't expect your Mac version to find many users.
* Except for games. For various reasons that I don't really appreciate but
which are facts of life, it has become standard for games to have
custom-made GUIs anyway, so games can generally get away with using
cross-platform frameworks such as SDL with no real downside.
Gregory Weston
Michael Ash <mi...@mikeash.com> wrote:
> But that's a bad question to ask. What you need to ask is whether it's
> *worth* using such a framework. My answer to that one is an absolute no*.
> Applications written with such a framework universally look and act badly
> on the Mac. We've discussed this before in this group with some people
> claiming that you can get very close, but when asked for an example, the
> example is never anything I would consider acceptable.
I am aware of one toolkit that did a decent job, but it was
prohibitively expensive for most developers, it imposed a significant
disk footprint (relative to storage at the time) on apps and it's
defunct now anyway.
All the ones that are around now are rubbish if you have any goal other
than quickly and cheaply getting something merely to launch.
G
Noble
information. I want to thank everyone for voicing their opinions on
this. It is really helping me get a feel for what I need to do.
nb
Noble
Noble
Paul Floyd
> Robert Welz <mac...@nospam.fixe-post.de> wrote:
>> Since the usual way is develop on Windows first, then, if at all get it
>> eventually on the Mac it would be cheaper to develop in some platform
>> independend framework. Can I say that or would someone strongly say that
>> this is not true? I guess not. I am convinced. But , when I start such a
>> project, I don't want get my asbestos underpants heated by flames from
>> the Mac Community.
>
> Is it cheaper to develop with some platform-independent framework? Almost
> certainly. I'm pretty sure that Qt or WxWidgets or whatever you use will
> not be any harder to develop with than using a native Windows API, so you
> can use that to make your Windows version, and then you get a Mac version
> for nearly free.
>
> But that's a bad question to ask. What you need to ask is whether it's
> *worth* using such a framework. My answer to that one is an absolute no*.
From what I've seen, Trolltech is making strides in ensuring that Qt 4
conforms to the Aqua guidelines. Since I'm a C++ programmer first and
foremost, I see no interest whatsoever in going down the
Objective-C/Cocoa path.
Of course, there's also Java, which gives you that cross-platform Java
look which we all love so much.
A bientot
Paul
Steven Fisher
> But that's a bad question to ask. What you need to ask is whether it's
> *worth* using such a framework. My answer to that one is an absolute no*.
> Applications written with such a framework universally look and act badly
> on the Mac. We've discussed this before in this group with some people
> claiming that you can get very close, but when asked for an example, the
> example is never anything I would consider acceptable.
Qt 4 is getting *really* good at this point. I think the major issue
with applications built in Qt is that they're almost universally written
by Windows developers, and of course whatever UI sin is created there
gets ported to Mac.
glenn andreas
Paul Floyd <ro...@127.0.0.1> wrote:
> Since I'm a C++ programmer first and
> foremost, I see no interest whatsoever in going down the
> Objective-C/Cocoa path.
The problem with that attitude is that new advances in the OS usually
come first (and often only) via Cocoa.
If you want to write an application that takes advantage of these,
you're going to, at the very least, need to make a "Cocoa in Carbon"
application.
(And on the flip side, there are often (usually lower level)
technologies that don't have an Objective-C API that a Cocoa programmer
will need to use)
Ultimately, it doesn't matter what "Mac Programmers Prefer", but rather
what do "Mac Users Prefer", since they are the consumers that will
purchase your product, so just because you might be able to write
something in say, Java, doesn't mean that this is the correct path
(consumer acceptance of Java based OS X apps is extremely low).
Michael Ash
Since the entire point is to allow you to use the same code everywhere,
this seems like a given.
I don't see how a cross-platform framework is going to give you a regular
Mac app complete with pretty icons, Mac-like toolbars, sheets,
AppleScriptability, and other such Mac-exclusive features.
Even ignoring those, the user experience will tend to be less than idea
due to the shared code. A properly-designed Mac app *acts* differently
than a properly-designed Windows app and it's not the sort of thing that
can be encapsulated inside a framework.
However, I am happy to be proven wrong, if anyone wants to post a link to
some software written with one of these frameworks which they believe is
as Mac-like as a native app would be.
Steven Fisher
Michael Ash <mi...@mikeash.com> wrote:
> Since the entire point is to allow you to use the same code everywhere,
> this seems like a given.
Getting the same code running everywhere is only part of the problem.
Having someone that can tell you "those icons look like they belong on
XP" and "the interface is really confusing here" (for instance) is
important.
> I don't see how a cross-platform framework is going to give you a regular
> Mac app complete with pretty icons, Mac-like toolbars, sheets,
> AppleScriptability, and other such Mac-exclusive features.
Then you haven't used Qt. Qt can do all of these.
> Even ignoring those, the user experience will tend to be less than idea
> due to the shared code. A properly-designed Mac app *acts* differently
> than a properly-designed Windows app and it's not the sort of thing that
> can be encapsulated inside a framework.
This is exactly what I was talking about above. :) Yes, your
application's behavior can't be entirely encapsulated in the Qt
framework. The idea is ridiculous. There's nothing to stop you from
using Windows icons, MDI (yes, Qt can kinda do it on the Mac), dialogs
with Retry, Abort and Fail, confusing interfaces and poorly-written
error message, etc, etc.
But you can make poor decisions in a Mac application for the most part
without Qt's help. (How many times have I seen people asking here how to
move the mouse to the OK button, for instance?)
But all of these are reasons you can't just recompile q Windows
application that uses Qt on the Mac and declare yourself done. They're
not reasons you can't use Qt well to construct something that looks at
home on Mac and Windows. If something that the Mac version suggests
would be an interface improvement on both Mac and Windows, do it on
both. If it isn't, it's entirely possible to do it on both without
introducing a lot of platform-specific code.
> However, I am happy to be proven wrong, if anyone wants to post a link to
> some software written with one of these frameworks which they believe is
> as Mac-like as a native app would be.
We're not shipping our Qt version yet, sorry. However, if you're really
interested, there's a GPL-only version of Qt to play around with...
-- Steve
Steven Fisher
Steven Fisher <st...@pyile.com> wrote:
> We're not shipping our Qt version yet, sorry. However, if you're really
> interested, there's a GPL-only version of Qt to play around with...
I should also add I don't really recommend Qt for Mac-only development,
unless it is significantly closer to the way you think than Carbon and
Cocoa. Sure, you could do it, but why bother? Apple has some perfectly
good tools available. They're just not cross-platform. But Qt is great
if you want to sell a product to both Mac and Windows users with minimal
extra cost.
Silver Dream !
>> I don't see how a cross-platform framework is going to give you a regular
>> Mac app complete with pretty icons, Mac-like toolbars, sheets,
>> AppleScriptability, and other such Mac-exclusive features.
>
> Then you haven't used Qt. Qt can do all of these.
Well, the last time I checked, even the examples looked really nice and
I'd risk to say: more elegant than what I got used to on GNU/Linux or
Windows but OTOH certainly not like OS X app.
Steven Fisher
"Silver Dream !" <silv...@inet.pl.remove.it> wrote:
> Well, the last time I checked, even the examples looked really nice and
> I'd risk to say: more elegant than what I got used to on GNU/Linux or
> Windows but OTOH certainly not like OS X app.
Yes, the examples aren't great examples of Mac OS X applications. But I
haven't run into much that I wanted to do but couldn't with Qt.
silverdr
>> Well, the last time I checked, even the examples looked really nice and
>> I'd risk to say: more elegant than what I got used to on GNU/Linux or
>> Windows but OTOH certainly not like OS X app.
>
> Yes, the examples aren't great examples of Mac OS X applications. But I
> haven't run into much that I wanted to do but couldn't with Qt.
And how do you find the current version's "footprint" (on memory, CPU
usage, etc.) when compared to other frameworks available for OS X? I
vaguely recall that this area was also something that made me doubt.
Robert Welz
Yeah, all those technical restrictions...
We used to do PowerPlant, but what I compell is High-End Hardware
development, which is, unfortunately done mostly in windows. I haven't
studied softwareengeneering for nearly 10 years now to do some shareware
games or funware. So I will at least not bother wheather a potential
customer use a MacPro or an recent PowerPook.
But be honest: If you have such a fine Machine like a MacPro and some
app crashes with a kernel panic or you have a printer driver which
consumes 500 MB RAM when printing 5 pages you would be absolutely
dissapointed.
But to come back to jobs, it looks very sad at the moment: We have
nothing to eat, some out of work money by estate and this quite a long
time now. So I wonder if someone hires me, at least for fun, just to
proof what I can ;)
greetings from my flat too all!
wish all the best!
Robert
--
a
Robert Welz
Yeah, all those technical restrictions...
We used to do PowerPlant, but what I compell is High-End Hardware
development, which is, unfortunately done mostly in windows. I haven't
studied softwareengeneering for nearly 10 years now to do some shareware
games or funware. So I will at least not bother wheather a potential
customer use a MacPro or an recent PowerPook.
But be honest: If you have such a fine Machine like a MacPro and some
app crashes with a kernel panic or you have a printer driver which
consumes 500 MB RAM when printing 5 pages you would be absolutely
dissapointed.
But to come back to jobs, it looks very sad at the moment: We have
nothing to eat, some out of work money by estate and this quite a long
time now. So I wonder if someone hires me, at least for fun, just to
proof what I can ;)
BTW: Someone in need for some device drivers, preferably USB?
greetings from my flat too all!
greetings to all of my friends!
Jon Harrop
> Hello, I am a new Mac user (less than a year). I have been programming
> and using Dos/Windows for over 25 years and thought that it was
> finally time to give the Mac a try. I love it to say the least.
>
> I have a question. I have bought and been using REALbasic for the Mac.
> I have been using it for about 6 months now. Though its alright I was
> wandering what most programmers prefer to use to write their Mac
> software? Java? Objective-C?
I am not yet a Mac user but I would like similar information.
We develop in OCaml on Linux and F# on Windows. Windows Forms makes GUI
programming easy under F# (thanks to .NET) but the GUI situation seems to
be as dire on OSX as it is on Linux, which surprises me. There is Cocoa
but, like Qt, it seems to be totally uninteroperable (in contrast to .NET).
I have been searching for similar tools used by Mac programmers for several
days now with little success. Mac programmers still seem to be using C++
and have yet to adopt modern functional languages.
There is an OCaml port to the Mac:
http://www.cocan.org/getting_started_with_ocaml_on_mac_os_x
but I cannot find any satisfactory way to create native OSX GUIs.
--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
Michael Ash
> We develop in OCaml on Linux and F# on Windows. Windows Forms makes GUI
> programming easy under F# (thanks to .NET) but the GUI situation seems to
> be as dire on OSX as it is on Linux, which surprises me. There is Cocoa
> but, like Qt, it seems to be totally uninteroperable (in contrast to .NET).
Can you explain what "totally uninteroperable" means? I have no idea what
you're referring to.
The word itself I could think of as referring to an inability to use it on
other OSes, or an inability to use it from other languages. However,
neither of these apply to Qt. Also, .NET isn't exactly portable, and Cocoa
can be used from many languages that are not ObjC.
> I have been searching for similar tools used by Mac programmers for several
> days now with little success. Mac programmers still seem to be using C++
> and have yet to adopt modern functional languages.
You say this as though the situation were different on any other operating
system. As far as I can tell, "modern" languages such as OCaml are in the
vast minority on every platform.
However, C++ is not as popular on the Mac as on some other platforms
because it can't be used to access Cocoa. Objective-C is probably the most
commonly used language on the platform today, although I bet some people
would dispute that.
> There is an OCaml port to the Mac:
>
> http://www.cocan.org/getting_started_with_ocaml_on_mac_os_x
>
> but I cannot find any satisfactory way to create native OSX GUIs.
A little digging turns up some mentions of OCaml-ObjC bridges which would
allow you to use Cocoa, but I wasn't able to find any working links.
Otherwise, I assume OCaml has a way to call C functions, so you can just
use Carbon.
Lorenzo Thurman
> Noble wrote:
>> Hello, I am a new Mac user (less than a year). I have been programming
>> and using Dos/Windows for over 25 years and thought that it was
>> finally time to give the Mac a try. I love it to say the least.
>>
>> I have a question. I have bought and been using REALbasic for the Mac.
>> I have been using it for about 6 months now. Though its alright I was
>> wandering what most programmers prefer to use to write their Mac
>> software? Java? Objective-C?
>
> I am not yet a Mac user but I would like similar information.
>
> We develop in OCaml on Linux and F# on Windows. Windows Forms makes GUI
> programming easy under F# (thanks to .NET) but the GUI situation seems to
> be as dire on OSX as it is on Linux, which surprises me. There is Cocoa
> but, like Qt, it seems to be totally uninteroperable (in contrast to .NET).
>
> I have been searching for similar tools used by Mac programmers for several
> days now with little success. Mac programmers still seem to be using C++
> and have yet to adopt modern functional languages.
>
> There is an OCaml port to the Mac:
>
> http://www.cocan.org/getting_started_with_ocaml_on_mac_os_x
>
> but I cannot find any satisfactory way to create native OSX GUIs.
>
a glance at Apple's developer site: http://developer.apple.com, that the
language of choice is Objective-C. As a superset of C, it can use C w/o
any bridging technologies. I often make C calls in my Objective-C code
and only need to include the appropriate header. C++ is provided by
Objective-C++. I've never used Objective-C++, so I can't comment on how
well it works. Of course, Qt also works with Cocoa. Developing GUI's on
OSX is quite straightforward using Interface Builder. As another poster
stated, I don't know what you mean by interoperable. Nothing you mention
operates outside of Windows except Qt (ok, maybe OCaml).
Also, what do you mean by "satisfactory way to create native OSX GUI's"?
Interface Builder makes this pretty trivial. Its mostly drag & drop and
allows you to do such things as define an elements behavior, setup user
preferences all w/o a line of code. I don't know how much easier it can be.
If you have specific questions about Cocoa, Apple supports mailing lists
for most of its technologies. Look here:
http://lists.apple.com/mailman/listinfo
The Cocoa list is cocoa-dev
Lots of smart people on these lists. I'm sure they can help find your way.
Jon Harrop
> I'm not sure where you've been looking, but it should be clear from just
> a glance at Apple's developer site: http://developer.apple.com, that the
> language of choice is Objective-C.
Yes.
> Also, what do you mean by "satisfactory way to create native OSX GUI's"?
> Interface Builder makes this pretty trivial. Its mostly drag & drop and
> allows you to do such things as define an elements behavior, setup user
> preferences all w/o a line of code. I don't know how much easier it can
> be.
I want to write GUIs from modern languages (statically-typed functional).
For example, under Windows I can use F# and Windows Forms (via .NET):
let form = new Form(Text="A circle", Visible=true)
form.TopMost <- true
form.Resize.Add(fun _ -> form.Invalidation())
form.Paint.Add(fun e ->
let rect = form.ClientRectabgle
let r = min rect.Width rect.Height
e.Graphics.DrawEllipse(new Pen(Color.Black), 0, 0, r, r))
You can do the same sort of thing with OCaml and GTK on Linux (although it
is harder).
I'd like to know how easily I can do something similar on OSX, using the
native GUI. It seems that I have to drop to C and bind all of the relevant
Carbon functions before I can start writing in a language like OCaml. If it
works, that's better than nothing.
Are there any Carbon bindings for similar languages (OCaml, SML, Haskell)?
The nearest I've found is Scala for Swing (Java) but that seems to be a very
rare language.
> If you have specific questions about Cocoa, Apple supports mailing lists
> for most of its technologies. Look here:
> http://lists.apple.com/mailman/listinfo
> The Cocoa list is cocoa-dev
>
> Lots of smart people on these lists. I'm sure they can help find your way.
I'll check them out. Thanks.
Jon Harrop
>> I have been searching for similar tools used by Mac programmers for
>> several days now with little success. Mac programmers still seem to be
>> using C++ and have yet to adopt modern functional languages.
>
> You say this as though the situation were different on any other operating
> system. As far as I can tell, "modern" languages such as OCaml are in the
> vast minority on every platform.
I believe Linux programmers use a much more diverse range of languages
(starting with bash). Even Windows programmers have C++, VB and C#. Mac
programmers seem to have only Objective C, which is rather offputting if
you moved on from C/C++ many years ago.
> However, C++ is not as popular on the Mac as on some other platforms
> because it can't be used to access Cocoa.
This is what I meant by "totally uninteroperable". If you can't even access
Cocoa from a very similar language (C++), how is anyone supposed to write
bindings for more unrelated languages like OCaml?
> Objective-C is probably the most
> commonly used language on the platform today, although I bet some people
> would dispute that.
I certainly get the impression that everyone codes in Objective-C on the Mac
because that is the only option they have. I think this is a great shame
because Objective C was superceded on other platforms a long time ago.
Apple would do well to create a language agnostic framework like .NET,
IMHO.
>> There is an OCaml port to the Mac:
>>
>> http://www.cocan.org/getting_started_with_ocaml_on_mac_os_x
>>
>> but I cannot find any satisfactory way to create native OSX GUIs.
>
> A little digging turns up some mentions of OCaml-ObjC bridges which would
> allow you to use Cocoa, but I wasn't able to find any working links.
Yes. I found similar things but all of these projects seem to have failed.
> Otherwise, I assume OCaml has a way to call C functions, so you can just
> use Carbon.
Ok, I'll look into this. Thanks.
Sherm Pendley
> Michael Ash wrote:
>
>> However, C++ is not as popular on the Mac as on some other platforms
>> because it can't be used to access Cocoa.
>
> This is what I meant by "totally uninteroperable". If you can't even access
> Cocoa from a very similar language (C++)
You *can* access Cocoa from other languages - Perl, Python, Ruby, FScript,
SmallTalk, etc. Note that these are all highly dynamic languages. C++ is
*not* a "very similar language"; it's entirely static, which is why it's a
poor match for Cocoa.
>> Objective-C is probably the most
>> commonly used language on the platform today, although I bet some people
>> would dispute that.
>
> I certainly get the impression that everyone codes in Objective-C on the Mac
> because that is the only option they have.
Nonsense.
> I think this is a great shame
> because Objective C was superceded on other platforms a long time ago.
Their loss.
> Apple would do well to create a language agnostic framework like .NET,
You would do well to do a little research and see just how language agnostic
Cocoa actually is.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Sherm Pendley
> I want to write GUIs from modern languages (statically-typed functional).
> For example, under Windows I can use F# and Windows Forms (via .NET):
>
> let form = new Form(Text="A circle", Visible=true)
> form.TopMost <- true
> form.Resize.Add(fun _ -> form.Invalidation())
> form.Paint.Add(fun e ->
> let rect = form.ClientRectabgle
> let r = min rect.Width rect.Height
> e.Graphics.DrawEllipse(new Pen(Color.Black), 0, 0, r, r))
You have to write code to create your GUI? And you call that "modern"???
Interface Builder: So easy a caveman can do it. (Sorry GEICO...)
Reinder Verlinde
Jon Harrop <j...@ffconsultancy.com> wrote:
> Michael Ash wrote:
> >> I have been searching for similar tools used by Mac programmers for
> >> several days now with little success. Mac programmers still seem to be
> >> using C++ and have yet to adopt modern functional languages.
> >
> > You say this as though the situation were different on any other operating
> > system. As far as I can tell, "modern" languages such as OCaml are in the
> > vast minority on every platform.
>
> I believe Linux programmers use a much more diverse range of languages
> (starting with bash). Even Windows programmers have C++, VB and C#. Mac
> programmers seem to have only Objective C, which is rather offputting if
> you moved on from C/C++ many years ago.
>
> > However, C++ is not as popular on the Mac as on some other platforms
> > because it can't be used to access Cocoa.
>
> This is what I meant by "totally uninteroperable". If you can't even access
> Cocoa from a very similar language (C++), how is anyone supposed to write
> bindings for more unrelated languages like OCaml?
C++ and Objective-C share a subset but are quite different in philosophy.
It is perfectly possible to hook up Cocoa to any language that allows
C-style bindings, but glueing a compile-time strongly-typed language
like C++ to Cocoa does not make a good fit.
I have a feeling that you are making too much of the fact that you may
have to do some Objective-C coding to build an UI. To get a good Mac UI,
use Cocoa. To implement your logic, use whatever language you want. To
glue them together, use C bindings.
You can either use bindings somebody else has made or roll you own. The
former limits you to languages for which somebody else (Apple or
somebody else) has done that, but that is not different from the way
things are on other platforms (you could argue that the exception here
is platforms where compilers compile to some VM and the VM has bindings
to GUI libraries, but that just moves your search from "find C bindings
for myFavouriteLanguage" to the "find a compiler to someVM for
myFavouriteLanguage"
Reinder
Gregory Weston
Jon Harrop <j...@ffconsultancy.com> wrote:
> Michael Ash wrote:
> >> I have been searching for similar tools used by Mac programmers for
> >> several days now with little success. Mac programmers still seem to be
> >> using C++ and have yet to adopt modern functional languages.
> >
> > You say this as though the situation were different on any other operating
> > system. As far as I can tell, "modern" languages such as OCaml are in the
> > vast minority on every platform.
>
> I believe Linux programmers use a much more diverse range of languages
> (starting with bash). Even Windows programmers have C++, VB and C#. Mac
> programmers seem to have only Objective C, which is rather offputting if
> you moved on from C/C++ many years ago.
Mac programmers have C, C++ and Objective-C. They also have Perl, Ruby,
Java, RealBASIC, Forth, ....
>
> > However, C++ is not as popular on the Mac as on some other platforms
> > because it can't be used to access Cocoa.
>
> This is what I meant by "totally uninteroperable". If you can't even access
> Cocoa from a very similar language (C++),
What gave you the idea that C++ is "very similar" to Objective-C?
> how is anyone supposed to write
> bindings for more unrelated languages like OCaml?
Considering it's been done, the question has little meaning.
> > Objective-C is probably the most
> > commonly used language on the platform today, although I bet some people
> > would dispute that.
>
> I certainly get the impression that everyone codes in Objective-C on the Mac
> because that is the only option they have.
Nope. Not everyone uses Objective-C. Those who do do so because it's the
path of least resistance for mainstream application development. It's a
well-supported tool to turn out anything close to a "normal" Mac OS X
application with a minimum of time spent on boilerplate.
> I think this is a great shame
> because Objective C was superceded on other platforms a long time ago.
> Apple would do well to create a language agnostic framework like .NET,
> IMHO.
I think it's a great shame that people start making judgments without
really knowing what they're talking about, IMNSHO.
G
Michael Ash
> Michael Ash wrote:
>>> I have been searching for similar tools used by Mac programmers for
>>> several days now with little success. Mac programmers still seem to be
>>> using C++ and have yet to adopt modern functional languages.
>>
>> You say this as though the situation were different on any other operating
>> system. As far as I can tell, "modern" languages such as OCaml are in the
>> vast minority on every platform.
>
> I believe Linux programmers use a much more diverse range of languages
> (starting with bash). Even Windows programmers have C++, VB and C#. Mac
> programmers seem to have only Objective C, which is rather offputting if
> you moved on from C/C++ many years ago.
This is completely ridiculous and shows how little you actually know about
the platform. (I mean no offense by this; being ignorant about the
platform is common, and easily remedied, and I don't mean to indicate any
sort of character flaw by it.)
Here is a (probably incomplete) list of languages I have personally used
on OS X:
- Bash
- Perl
- Python
- Common Lisp
- ML
- PPC assembly
- AppleScript
- Java
- C
- C++
- Objective-C
- Objective-C++
- SmallTalk
Many other languages exist and are usable. The reason Mac programming is
so ObjC heavy is not because it's all we have, it's because ObjC is damned
good and so often the right tool for the job.
>> However, C++ is not as popular on the Mac as on some other platforms
>> because it can't be used to access Cocoa.
>
> This is what I meant by "totally uninteroperable". If you can't even access
> Cocoa from a very similar language (C++), how is anyone supposed to write
> bindings for more unrelated languages like OCaml?
Once again, this shows that you're missing knowledge on the subject. Aside
from the part where they share most of C, these two languages are vastly
different. It simply is not technically possible to allow access to Cocoa
from C++. Cocoa depends, at a very deep level, on various object-oriented
language features which C++ simply lacks.
If you look at languages which are *actually* similar to ObjC, such as
SmallTalk, Ruby, Python, etc., then you will almost invariably discover
that Cocoa *is* accessible from those languages.
>> Objective-C is probably the most
>> commonly used language on the platform today, although I bet some people
>> would dispute that.
>
> I certainly get the impression that everyone codes in Objective-C on the Mac
> because that is the only option they have. I think this is a great shame
> because Objective C was superceded on other platforms a long time ago.
> Apple would do well to create a language agnostic framework like .NET,
> IMHO.
That's rich. Can you access .NET from C++? No? Why does .NET get a free
pass but not Cocoa?
Cocoa is plenty language agnostic. All you have to do is write a language
bridge. In a language that supports decent introspection, this is fairly
easy. (Our own Sherm Pendly, seen elsewhere in this thread, wrote and
maintains a Perl-ObjC bridge and, as far as I know has done so
single-handedly.) In a language that doesn't, it's impossible. This is no
different from the .NET situation or the situation with any other
framework.
I believe you will find that many Mac programmers, myself included, will
strongly dispute the idea that "Objective C was superceded on other
platforms a long time ago". As a matter of fact I believe that Objective-C
created a powerful fusion of low-level C and an excellent object system, a
combination which still has no match today. There's a reason I do most of
my Mac development in this language, and it's not out of necessity: you've
heard of Carbon, right? It's accessible from more languages due to being
written entirely in C. Plenty of people use it, too.
But most people don't use Carbon, they use Cocoa, because Cocoa is
excellent and unmatched. And the reason it is excellent is Objective-C.
(Note: there are many things about Objective-C which I find annoying,
distateful, stupid, or lacking. I have noticed that this proves true of
any language which I get to know sufficiently well. I am by no means
attempting to claim that ObjC is perfect; it's not. However, I do happen
to believe that ObjC's peculiar set of tradeoffs make it the best choice
for practical application programming on the Mac, and it would be the best
choice for practical application programming on any platform where good
libraries were available.)
Jon Harrop
> In article <46685c8f$0$8734$ed26...@ptn-nntp-reader02.plus.net>,
> Jon Harrop <j...@ffconsultancy.com> wrote:
>> This is what I meant by "totally uninteroperable". If you can't even
>> access Cocoa from a very similar language (C++), how is anyone supposed
>> to write bindings for more unrelated languages like OCaml?
>
> C++ and Objective-C share a subset but are quite different in philosophy.
>
> It is perfectly possible to hook up Cocoa to any language that allows
> C-style bindings, but glueing a compile-time strongly-typed language
> like C++ to Cocoa does not make a good fit.
Right, this is exactly the impression I have. I am only interested in
statically-typed languages, which makes Cocoa much harder for me to use.
Having said that, I see no reason why I cannot compile a high-level GUI
description into Objective C code that implements it. Perhaps this is the
way forward. I'll use Objective C as an intermediate language...
> I have a feeling that you are making too much of the fact that you may
> have to do some Objective-C coding to build an UI. To get a good Mac UI,
> use Cocoa. To implement your logic, use whatever language you want. To
> glue them together, use C bindings.
The difference is that I could abstract my GUI and run it across platforms
if I could write it in OCaml. If am forced to code-to-the-metal, write C
bindings and so on then there is a lot more work involved and that work is
entirely Mac-specific.
> You can either use bindings somebody else has made...
In my searches I have only found several failed attempts at writing Cocoa
bindings for OCaml.
Jon Harrop
> Jon Harrop <j...@ffconsultancy.com> writes:
>> This is what I meant by "totally uninteroperable". If you can't even
>> access Cocoa from a very similar language (C++)
>
> You *can* access Cocoa from other languages - Perl, Python, Ruby, FScript,
> SmallTalk, etc. Note that these are all highly dynamic languages. C++ is
> *not* a "very similar language"; it's entirely static, which is why it's a
> poor match for Cocoa.
Yes. I am interested in statically-typed functional languages. These are all
also a "poor match for Cocoa".
>> I think this is a great shame
>> because Objective C was superceded on other platforms a long time ago.
>
> Their loss.
From the Debian package popularity contest, OCaml is 10x more popular than
Objective C. So, given the choice, people don't choose Objective C.
Jon Harrop
> Mac programmers have C, C++ and Objective-C. They also have Perl, Ruby,
> Java, RealBASIC, Forth, ....
I am less interested in BASIC and Forth and more interested in OCaml,
Standard ML, Haskell, Scala, Nemerle, JoCaml, F# or any other modern FPL.
>> This is what I meant by "totally uninteroperable". If you can't even
>> access Cocoa from a very similar language (C++),
>
> What gave you the idea that C++ is "very similar" to Objective-C?
Both are C + a bit of OOP. Neither offer most of the features that I use
everyday, so you can see why I'm not particularly keen to go back in time
just to write a Mac GUI...
>> how is anyone supposed to write
>> bindings for more unrelated languages like OCaml?
>
> Considering it's been done, the question has little meaning.
http://caml.inria.fr/pub/ml-archives/caml-list/2005/02/a8948ea57870109f8f1524745cdcb02d.en.html
http://caml.inria.fr/pub/ml-archives/caml-list/2005/02/ce582de1298671b77be42191586efe31.en.html
http://groups.google.com/group/fa.caml/msg/042bd5461576b6c6
I can find no evidence that this has been done at all, let alone well. Can
you post a link to the Cocoa bindings for OCaml that you've found/written?
>> I certainly get the impression that everyone codes in Objective-C on the
>> Mac because that is the only option they have.
>
> Nope. Not everyone uses Objective-C. Those who do do so because it's the
> path of least resistance for mainstream application development. It's a
> well-supported tool to turn out anything close to a "normal" Mac OS X
> application with a minimum of time spent on boilerplate.
That is my impression. I was just very surprised to find that a hugely
expensive commercial platform has much worse development tools than a free
platform. This is really a testament to the Linux community who have
completed and polished their product better than Apple. Amazing.
David Stone
Jon Harrop <j...@ffconsultancy.com> wrote:
[snip]
>
> The difference is that I could abstract my GUI and run it across platforms
> if I could write it in OCaml. If am forced to code-to-the-metal, write C
> bindings and so on then there is a lot more work involved and that work is
> entirely Mac-specific.
>
My approach would be different - abstract the core functionality,
and wrap it in a GUI built for that specific operating system.
This discussion has been up recently here: programs which use a
framework to implement the same GUI cross-platform are, in my
experience, horrible to use on anything except the primary platform
the framework was designed to mimic.
Yamaha's Studio Manager is a very good case in point - it looks like
a framework built using windows tools, but designed to emulate the
Mac "look and feel" and work under OS X. It works, but is incredibly
unresponsive to menu and window selection, while the graphic elements
of the interface look just plain wrong. Everything appears to be
ever-so-slightly narrower, and the colours don't quite match.
Speaking as a user, if I have a Mac version of an application, I want
it to BE a Mac version (which means following the interface guidelines
and behaving appropriately). Similarly, if I happen to be using the
same application on a Windows box, I want it to work the way Windows
applications are supposed to.
Jon Harrop
> This is completely ridiculous and shows how little you actually know about
> the platform. (I mean no offense by this; being ignorant about the
> platform is common, and easily remedied, and I don't mean to indicate any
> sort of character flaw by it.)
Sure, I am completely new here.
> Here is a (probably incomplete) list of languages I have personally used
> on OS X:
>
> - Bash
> - Perl
> - Python
> - Common Lisp
> - ML
> - PPC assembly
> - AppleScript
> - Java
> - C
> - C++
> - Objective-C
> - Objective-C++
> - SmallTalk
>
> Many other languages exist and are usable. The reason Mac programming is
> so ObjC heavy is not because it's all we have, it's because ObjC is damned
> good and so often the right tool for the job.
Assuming by "ML" you mean Standard ML, how would you write a Mac GUI
application in ML?
> If you look at languages which are *actually* similar to ObjC, such as
> SmallTalk, Ruby, Python, etc., then you will almost invariably discover
> that Cocoa *is* accessible from those languages.
Sure. We are unlikely to adopt dynamically-typed scripting languages just to
support OSX though.
> Why does .NET get a free pass but not Cocoa?
I don't need to write my own development tools or change languages and
programming paradigms to create GUI programs under Windows (or Linux). I do
on the Mac.
That is a huge difference: if my assessment of how much more difficult it is
for us to develop GUI apps under OSX is accurate then we are highly
unlikely to develop any products for the Mac. However, we might develop
products aimed at developers, to let them develop cross-platform GUIs more
easily. I'd want a lot of evidence that OSX is going places though, and
trends like this don't exactly instill confidence in the platform:
http://www.google.com/trends?q=osx%2C+ubuntu
> Cocoa is plenty language agnostic. All you have to do is write a language
> bridge.
Exactly, you'd start by writing some kind of Common Language Run-time.
> In a language that supports decent introspection, this is fairly
> easy. (Our own Sherm Pendly, seen elsewhere in this thread, wrote and
> maintains a Perl-ObjC bridge and, as far as I know has done so
> single-handedly.) In a language that doesn't, it's impossible. This is no
> different from the .NET situation or the situation with any other
> framework.
That is completely different from the .NET situation where .NET languages
can interoperate seamlessly.
Take my toy example:
let form = new Form(Text="A circle", Visible=true)
form.TopMost <- true
form.Resize.Add(fun _ -> form.Invalidation())
form.Paint.Add(fun e ->
let rect = form.ClientRectabgle
let r = min rect.Width rect.Height
e.Graphics.DrawEllipse(new Pen(Color.Black), 0, 0, r, r))
using code like this I can compose GUIs that run under Linux and Windows,
written in OCaml and F# respectively, without having to leave the comfort
of ML and with minimal work to support the other platform.
Under OSX, it seems I would either have to ditch all existing GUI work and
start from scratch in a language that lacks almost all of the features that
I use everyday, then I would have to write my own development tools or
bindings to use our existing code base.
So, from my point of view, .NET and F# make the transition completely
painless whereas OSX provides essentially nothing at all to help. You can
see why this is offputting...
Rainer Joswig
Jon Harrop <j...@ffconsultancy.com> wrote:
> Michael Ash wrote:
> > This is completely ridiculous and shows how little you actually know about
> > the platform. (I mean no offense by this; being ignorant about the
> > platform is common, and easily remedied, and I don't mean to indicate any
> > sort of character flaw by it.)
>
> Sure, I am completely new here.
Guys, Jon Harrop (aka 'we') is a certified troll and spammer.
He is just advertising his business here.
Don't waste your time. Recently he advertised in comp.lang.lisp
and comp.lang.c++.
Jon Harrop
> In article <4669357f$0$8753$ed26...@ptn-nntp-reader02.plus.net>,
> Jon Harrop <j...@ffconsultancy.com> wrote:
>> The difference is that I could abstract my GUI and run it across
>> platforms if I could write it in OCaml. If am forced to
>> code-to-the-metal, write C bindings and so on then there is a lot more
>> work involved and that work is entirely Mac-specific.
>
> My approach would be different - abstract the core functionality,
> and wrap it in a GUI built for that specific operating system.
Absolutely. This is exactly what we've done to support Linux and Windows.
> This discussion has been up recently here: programs which use a
> framework to implement the same GUI cross-platform are, in my
> experience, horrible to use on anything except the primary platform
> the framework was designed to mimic.
I agree entirely.
> Yamaha's Studio Manager is a very good case in point - it looks like
> a framework built using windows tools, but designed to emulate the
> Mac "look and feel" and work under OS X. It works, but is incredibly
> unresponsive to menu and window selection, while the graphic elements
> of the interface look just plain wrong. Everything appears to be
> ever-so-slightly narrower, and the colours don't quite match.
>
> Speaking as a user, if I have a Mac version of an application, I want
> it to BE a Mac version (which means following the interface guidelines
> and behaving appropriately). Similarly, if I happen to be using the
> same application on a Windows box, I want it to work the way Windows
> applications are supposed to.
Sure, I don't mind implementing Mac look and feel for the few bits where it
differs from a generic GUI. Indeed, this is exactly what we did to support
Windows. However, I'd like to store that information in the same place
(OCaml source code).
Another problem is that a large part of our GUI is performance-intensive
OpenGL rendering. So we need a tight coupling between the OCaml back-end
and the front-end, hence my wanting an OCaml front-end.
Gregory Weston
Jon Harrop <j...@ffconsultancy.com> wrote:
> Gregory Weston wrote:
> > Mac programmers have C, C++ and Objective-C. They also have Perl, Ruby,
> > Java, RealBASIC, Forth, ....
>
> I am less interested in BASIC and Forth and more interested in OCaml,
> Standard ML, Haskell, Scala, Nemerle, JoCaml, F# or any other modern FPL.
Typing Haskell and "OS X" into a Google search field gave me this
<http://hoc.sourceforge.net/index.html>
>
> >> This is what I meant by "totally uninteroperable". If you can't even
> >> access Cocoa from a very similar language (C++),
> >
> > What gave you the idea that C++ is "very similar" to Objective-C?
>
> Both are C + a bit of OOP.
So oversimplified as to be incorrect.
> Neither offer most of the features that I use
> everyday, so you can see why I'm not particularly keen to go back in time
> just to write a Mac GUI...
As someone else pointed out already, if you're coding your GUI, you
already are back in time.
> >> how is anyone supposed to write
> >> bindings for more unrelated languages like OCaml?
> >
> > Considering it's been done, the question has little meaning.
>
> ...
>
> I can find no evidence that this has been done at all, let alone well. Can
> you post a link to the Cocoa bindings for OCaml that you've found/written?
I never said a peep about OCaml. I was responding to the much broader
issue of "unrelated languages." See, when you said "like" I thought you
mean "of which one example is" not "by which I mean."
> >> I certainly get the impression that everyone codes in Objective-C on the
> >> Mac because that is the only option they have.
> >
> > Nope. Not everyone uses Objective-C. Those who do do so because it's the
> > path of least resistance for mainstream application development. It's a
> > well-supported tool to turn out anything close to a "normal" Mac OS X
> > application with a minimum of time spent on boilerplate.
>
> That is my impression.
Odd. It wasn't your impression yesterday. I could've sworn you indicated
a belief that Mac programmers didn't have a choice.
> I was just very surprised to find that a hugely
> expensive commercial platform has much worse development tools than a free
> platform. This is really a testament to the Linux community who have
> completed and polished their product better than Apple. Amazing.
What's amazing is how many errors are in those last couple of sentences.
Gregory Weston
Jon Harrop <j...@ffconsultancy.com> wrote:
> >> I think this is a great shame
> >> because Objective C was superceded on other platforms a long time ago.
> >
> > Their loss.
>
> From the Debian package popularity contest, OCaml is 10x more popular than
> Objective C. So, given the choice, people don't choose Objective C.
Did the contest require familiarity with all the options? If not, then
popularity is a meaningless metric.
Gregory Weston
Jon Harrop <j...@ffconsultancy.com> wrote:
> Reinder Verlinde wrote:
> > In article <46685c8f$0$8734$ed26...@ptn-nntp-reader02.plus.net>,
> > Jon Harrop <j...@ffconsultancy.com> wrote:
> >> This is what I meant by "totally uninteroperable". If you can't even
> >> access Cocoa from a very similar language (C++), how is anyone supposed
> >> to write bindings for more unrelated languages like OCaml?
> >
> > C++ and Objective-C share a subset but are quite different in philosophy.
> >
> > It is perfectly possible to hook up Cocoa to any language that allows
> > C-style bindings, but glueing a compile-time strongly-typed language
> > like C++ to Cocoa does not make a good fit.
>
> Right, this is exactly the impression I have. I am only interested in
> statically-typed languages, which makes Cocoa much harder for me to use.
>
> Having said that, I see no reason why I cannot compile a high-level GUI
> description into Objective C code that implements it. Perhaps this is the
> way forward. I'll use Objective C as an intermediate language...
Bringing a product from another platform to the Mac with "minimize
effort to do so" as a major criterion is an excellent way to deliver a
Mac product that will fail. The great majority of Mac users will be able
to differentiate between a "Mac program" and a "program that has been
made to run on the Mac" and will use the latter only if there is
literally no alternative. Least-effort Mac ports miss the point so
drastically that in general they aren't worth using.
G
Jon Harrop
> Bringing a product from another platform to the Mac with "minimize
> effort to do so" as a major criterion is an excellent way to deliver a
> Mac product that will fail. The great majority of Mac users will be able
> to differentiate between a "Mac program" and a "program that has been
> made to run on the Mac" and will use the latter only if there is
> literally no alternative. Least-effort Mac ports miss the point so
> drastically that in general they aren't worth using.
I agree in general but Maple, Matlab, Mathematica, Fink and DarwinPorts seem
to be obvious counter-examples.
Michael Ash
>> Many other languages exist and are usable. The reason Mac programming is
>> so ObjC heavy is not because it's all we have, it's because ObjC is damned
>> good and so often the right tool for the job.
>
> Assuming by "ML" you mean Standard ML, how would you write a Mac GUI
> application in ML?
I haven't used most of those languages for GUI programming, ML included,
so I haven't investigated it. Presumably ML has some way of calling C, so
I would use Carbon.
>> If you look at languages which are *actually* similar to ObjC, such as
>> SmallTalk, Ruby, Python, etc., then you will almost invariably discover
>> that Cocoa *is* accessible from those languages.
>
> Sure. We are unlikely to adopt dynamically-typed scripting languages just to
> support OSX though.
I'm not saying you should adopt it, I'm saying that whining about access
to a framework which depends on specific advanced object-oriented
programming features when you don't have those features is stupid.
>> Why does .NET get a free pass but not Cocoa?
>
> I don't need to write my own development tools or change languages and
> programming paradigms to create GUI programs under Windows (or Linux). I do
> on the Mac.
Did you read my message? No you don't. Carbon exists, is usable, is
*used*, and has a C interface so it can be used from anything.
I don't know if you're a troll like the other poster said, but ignoring
the most workable alternative and whining about how you have no choices
sure sounds like trolling behavior.
> That is a huge difference: if my assessment of how much more difficult it is
> for us to develop GUI apps under OSX is accurate then we are highly
> unlikely to develop any products for the Mac.
If your plan is to dump a half-baked port on the market, then this is
probably for the best.
> However, we might develop
> products aimed at developers, to let them develop cross-platform GUIs more
> easily.
Clearly with libraries like GNUStep, Cocotron, WxWidgets, Qt, etc. we just
don't have enough of those libraries. I'm sure your library, built with
such deep understanding and caring about the Mac platform, will be so much
better.
> I'd want a lot of evidence that OSX is going places though, and
> trends like this don't exactly instill confidence in the platform:
>
> http://www.google.com/trends?q=osx%2C+ubuntu
Then why are you here?
Let me lay this out for you:
We don't care about your product if your plan is to make a half-assed
port. We don't particularly care about your opininion that OCaml is the
best language ever, either. It may be, it may not be, it doesn't matter.
On this OS you have many, many choices for writing code and for writing
GUI applications. I happen to believe that Cocoa is the best choice on
this or anay platform, but you have lots of options. Whining about how you
have no options does not get you anywhere.
>> Cocoa is plenty language agnostic. All you have to do is write a language
>> bridge.
>
> Exactly, you'd start by writing some kind of Common Language Run-time.
Does making such blanket announcements while having no knowledge of the
subject give you some sort of warm feeling?
In fact you *wouldn't* start by writing any such thing, as evidenced by
the numerous language bridges which exist and none of them have done so.
>> In a language that supports decent introspection, this is fairly
>> easy. (Our own Sherm Pendly, seen elsewhere in this thread, wrote and
>> maintains a Perl-ObjC bridge and, as far as I know has done so
>> single-handedly.) In a language that doesn't, it's impossible. This is no
>> different from the .NET situation or the situation with any other
>> framework.
>
> That is completely different from the .NET situation where .NET languages
> can interoperate seamlessly.
And non-.NET languages? Can I call into C# from Objective-C?
It's completely the same. The difference is that .NET is more popular by
virtue of living on Windows and therefore has a lot more work put into
getting languages moved to it.
All those languages you talk about working on .NET didn't just
spontaneously appear, you know.
> Take my toy example:
>
> let form = new Form(Text="A circle", Visible=true)
> form.TopMost <- true
> form.Resize.Add(fun _ -> form.Invalidation())
> form.Paint.Add(fun e ->
> let rect = form.ClientRectabgle
> let r = min rect.Width rect.Height
> e.Graphics.DrawEllipse(new Pen(Color.Black), 0, 0, r, r))
>
> using code like this I can compose GUIs that run under Linux and Windows,
> written in OCaml and F# respectively, without having to leave the comfort
> of ML and with minimal work to support the other platform.
And if you insist on using these same ideas to write Mac software, the
result will be a horrible port that will not get very many Mac users.
> Under OSX, it seems I would either have to ditch all existing GUI work and
> start from scratch in a language that lacks almost all of the features that
> I use everyday, then I would have to write my own development tools or
> bindings to use our existing code base.
Or you could just use Carbon. But I suppose that ignoring the existence of
Carbon lets you whine better.
> So, from my point of view, .NET and F# make the transition completely
> painless whereas OSX provides essentially nothing at all to help. You can
> see why this is offputting...
I can't imagine that learning how to write GUI code in .NET was 100%
painless. Once again you seem to be ignoring the transition costs to .NET
while counting only the mots difficult transition cost to OS X.
Michael Ash
> Gregory Weston wrote:
>> Bringing a product from another platform to the Mac with "minimize
>> effort to do so" as a major criterion is an excellent way to deliver a
>> Mac product that will fail. The great majority of Mac users will be able
>> to differentiate between a "Mac program" and a "program that has been
>> made to run on the Mac" and will use the latter only if there is
>> literally no alternative. Least-effort Mac ports miss the point so
>> drastically that in general they aren't worth using.
>
> I agree in general but Maple, Matlab, Mathematica,
Have enormous installed bases which care more about the product than the
OS it runs on.
> Fink and DarwinPorts
Are targeted toward the sort of person who enjoys working at the UNIX
command line.
> seem
> to be obvious counter-examples.
But when you actually examine them, they aren't.
Jon Harrop
> Typing Haskell and "OS X" into a Google search field gave me this
>
> <http://hoc.sourceforge.net/index.html>
That's the best lead I've had so far.
>> >> This is what I meant by "totally uninteroperable". If you can't even
>> >> access Cocoa from a very similar language (C++),
>> >
>> > What gave you the idea that C++ is "very similar" to Objective-C?
>>
>> Both are C + a bit of OOP.
>
> So oversimplified as to be incorrect.
If C++ is wildly different to Objective C then OCaml certainly is.
> As someone else pointed out already, if you're coding your GUI, you
> already are back in time.
Pick'n'mix GUI design is not suitable for programmatic renderers or
autogenerated GUIs.
>> I can find no evidence that this has been done at all, let alone well.
>> Can you post a link to the Cocoa bindings for OCaml that you've
>> found/written?
>
> I never said a peep about OCaml.
Ok. I appreciate that I can use Perl on OSX but that is not of any use to
me. I'm only interested in statically-typed functional programming
languages like the ones I listed.
>> > Nope. Not everyone uses Objective-C. Those who do do so because it's
>> > the path of least resistance for mainstream application development.
>> > It's a well-supported tool to turn out anything close to a "normal" Mac
>> > OS X application with a minimum of time spent on boilerplate.
>>
>> That is my impression.
>
> Odd. It wasn't your impression yesterday. I could've sworn you indicated
> a belief that Mac programmers didn't have a choice.
Like you said, all the good alternatives are prohibitively difficult due
to "boilerplate". That was the impression I had. This is only the case on
OSX, not on Linux or Windows.
Gregory Weston
Jon Harrop <j...@ffconsultancy.com> wrote:
> Gregory Weston wrote:
> > Bringing a product from another platform to the Mac with "minimize
> > effort to do so" as a major criterion is an excellent way to deliver a
> > Mac product that will fail. The great majority of Mac users will be able
> > to differentiate between a "Mac program" and a "program that has been
> > made to run on the Mac" and will use the latter only if there is
> > literally no alternative. Least-effort Mac ports miss the point so
> > drastically that in general they aren't worth using.
>
> I agree in general but Maple, Matlab, Mathematica, Fink and DarwinPorts seem
> to be obvious counter-examples.
They're only counter-examples if they were "least-effort" ports. I've
never used Maple and haven't used Matlab in years, but the version of it
that I used and the other three products you mentioned don't qualify.
Gregory Weston
Jon Harrop <j...@ffconsultancy.com> wrote:
> Gregory Weston wrote:
> > Typing Haskell and "OS X" into a Google search field gave me this
> >
> > <http://hoc.sourceforge.net/index.html>
>
> That's the best lead I've had so far.
>
> >> >> This is what I meant by "totally uninteroperable". If you can't even
> >> >> access Cocoa from a very similar language (C++),
> >> >
> >> > What gave you the idea that C++ is "very similar" to Objective-C?
> >>
> >> Both are C + a bit of OOP.
> >
> > So oversimplified as to be incorrect.
>
> If C++ is wildly different to Objective C then OCaml certainly is.
I didn't say otherwise. I just rejected the assertion that C++ was very
similar to Objective-C.
> >> >> I certainly get the impression that everyone codes in Objective-C on the
> >> >> Mac because that is the only option they have.
> >> >
> >> > Nope. Not everyone uses Objective-C. Those who do do so because it's
> >> > the path of least resistance for mainstream application development.
> >> > It's a well-supported tool to turn out anything close to a "normal" Mac
> >> > OS X application with a minimum of time spent on boilerplate.
> >>
> >> That is my impression.
> >
> > Odd. It wasn't your impression yesterday. I could've sworn you indicated
> > a belief that Mac programmers didn't have a choice.
>
> Like you said, all the good alternatives are prohibitively difficult due
> to "boilerplate".
Oddly enough, I didn't say that. I neither said nor implied that options
other than Objective-C and Cocoa were "prohibitively difficult." I said
that Objective-C and Cocoa were the simplest choice for mainstream
development. Saying one option is simpler than others doesn't mean those
other options are objectively difficult or that they don't exist. Those
are your words, and they're not accurate.
G
Gregory Weston
Michael Ash <mi...@mikeash.com> wrote:
> > So, from my point of view, .NET and F# make the transition completely
> > painless whereas OSX provides essentially nothing at all to help. You can
> > see why this is offputting...
>
> I can't imagine that learning how to write GUI code in .NET was 100%
> painless.
It can attest to the fact that it's not.
Even for mainstream stuff where you're not building the GUI on the fly
as this poster seems to need there are some very subtle gotchas. There's
a GUI building interface that superficially seems fairly comparable to
IB. The trouble there is that you don't end up with this freeze-dried UI
that's reconstituted ready-to-go at need. It simply generates code.
Interestingly, the auto-generated code sets up the event handlers before
it sets up the initial values for any controls that it creates. And then
the handlers fire as those initial values are set. If those handlers
happen to refer to controls which haven't yet been set to sane values -
say a group of radio buttons which haven't had their initial selection
established - hilarity may ensue.
Jon Harrop
> Jon Harrop <j...@ffconsultancy.com> wrote:
>> Gregory Weston wrote:
>>> Bringing a product from another platform to the Mac with "minimize
>>> effort to do so" as a major criterion is an excellent way to deliver a
>>> Mac product that will fail. The great majority of Mac users will be able
>>> to differentiate between a "Mac program" and a "program that has been
>>> made to run on the Mac" and will use the latter only if there is
>>> literally no alternative. Least-effort Mac ports miss the point so
>>> drastically that in general they aren't worth using.
>>
>> I agree in general but Maple, Matlab, Mathematica,
>
> Have enormous installed bases which care more about the product than the
> OS it runs on.
Yes, exactly.
Jon Harrop
> Jon Harrop <j...@ffconsultancy.com> writes:
>> I want to write GUIs from modern languages (statically-typed functional).
>> For example, under Windows I can use F# and Windows Forms (via .NET):
>>
>> let form = new Form(Text="A circle", Visible=true)
>> form.TopMost <- true
>> form.Resize.Add(fun _ -> form.Invalidation())
>> form.Paint.Add(fun e ->
>> let rect = form.ClientRectabgle
>> let r = min rect.Width rect.Height
>> e.Graphics.DrawEllipse(new Pen(Color.Black), 0, 0, r, r))
>
> You have to write code to create your GUI? And you call that "modern"???
>
> Interface Builder: So easy a caveman can do it. (Sorry GEICO...)
Note that half of that program is the programmatic paint callback. So an
interface builder might let you "draw" the first three lines of code but it
costs you platform interoperability and three quarters of your revenue. Bad
idea.
Paul Floyd
>
> That is my impression. I was just very surprised to find that a hugely
> expensive commercial platform has much worse development tools than a free
> platform. This is really a testament to the Linux community who have
> completed and polished their product better than Apple. Amazing.
You can't polish a turd.
A bientot
Paul
Gregory Weston
Jon Harrop <j...@ffconsultancy.com> wrote:
> Sherm Pendley wrote:
> > Jon Harrop <j...@ffconsultancy.com> writes:
> >> I want to write GUIs from modern languages (statically-typed functional).
> >> For example, under Windows I can use F# and Windows Forms (via .NET):
> >>
> >> let form = new Form(Text="A circle", Visible=true)
> >> form.TopMost <- true
> >> form.Resize.Add(fun _ -> form.Invalidation())
> >> form.Paint.Add(fun e ->
> >> let rect = form.ClientRectabgle
> >> let r = min rect.Width rect.Height
> >> e.Graphics.DrawEllipse(new Pen(Color.Black), 0, 0, r, r))
> >
> > You have to write code to create your GUI? And you call that "modern"???
> >
> > Interface Builder: So easy a caveman can do it. (Sorry GEICO...)
>
> Note that half of that program is the programmatic paint callback. So an
> interface builder might let you "draw" the first three lines of code but it
> costs you platform interoperability and three quarters of your revenue. Bad
> idea.
Perhaps you've heard of a tool called Gorm.
But probably not.
Michael Ash
> Sherm Pendley wrote:
>> Jon Harrop <j...@ffconsultancy.com> writes:
>>> I want to write GUIs from modern languages (statically-typed functional).
>>> For example, under Windows I can use F# and Windows Forms (via .NET):
>>>
>>> let form = new Form(Text="A circle", Visible=true)
>>> form.TopMost <- true
>>> form.Resize.Add(fun _ -> form.Invalidation())
>>> form.Paint.Add(fun e ->
>>> let rect = form.ClientRectabgle
>>> let r = min rect.Width rect.Height
>>> e.Graphics.DrawEllipse(new Pen(Color.Black), 0, 0, r, r))
>>
>> You have to write code to create your GUI? And you call that "modern"???
>>
>> Interface Builder: So easy a caveman can do it. (Sorry GEICO...)
>
> Note that half of that program is the programmatic paint callback. So an
> interface builder might let you "draw" the first three lines of code but it
> costs you platform interoperability and three quarters of your revenue. Bad
> idea.
If you're truly serious about marketing your product on multiple platforms
you will realize than a cross-platform GUI framework is unlikely to
deliver good results anyway. You will therefore split your code into a
platform-specific GUI frontend and a portable backend, then rewrite the
GUI portions for each platform. This allows you to use Interface Builder
and create an actual Mac-like program on the Mac.
And once again you talk about something even though you know little about
it. IB does a lot more than save you three lines of code.
Given your attitude I have to ask: are you actually hear to learn about
Mac programming, or are you just here to whine about it?
If your goal is to learn then you could probably benefit from some serious
changes to your approach.
If your goal is just to whine, it would be nice to know now so I can
killfile you without going through the annoying and painful series of
arguments first.
Raffael Cavallaro
> I think it's a great shame that people start making judgments without
> really knowing what they're talking about, IMNSHO.
This is something of a Harrop specialty.
His others are unrepresentative toy examples, and advocating his
commercial offerings in irrelevant fora (a.k.a, spamming).
He's been trolling comp.lang.lisp for quite a while.
silverdr
>>> I think this is a great shame
>>> because Objective C was superceded on other platforms a long time ago.
>> Their loss.
I agree ;-)
> From the Debian package popularity contest, OCaml is 10x more popular than
> Objective C. So, given the choice, people don't choose Objective C.
Non sequitur.