f



What do Mac Programmers Prefer?

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

0
Noble
5/21/2007 11:21:52 AM
comp.sys.mac.programmer.help 4653 articles. 2 followers. Post Follow

81 Replies
736 Views

Similar Articles

[PageSpeed] 49

Noble wrote:

> 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".
0
silverdr
5/21/2007 11:37:51 AM
Noble <NobleBell@gmail.com> 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?
> 
> Thanks for your help.
> nb
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????????? )
0
mackel
5/21/2007 1:19:39 PM
In article <1179746512.204326.64790@x18g2000prd.googlegroups.com>,
 Noble <NobleBell@gmail.com> 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?
> 
> Thanks for your help.
> nb

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.
0
Gregory
5/21/2007 1:41:54 PM
Noble <NobleBell@gmail.com> 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?
> 
> Thanks for your help.
> nb

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


0
mackel
5/21/2007 1:45:01 PM
Noble <NobleBell@gmail.com> 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?
> 
> Thanks for your help.
> nb

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

0
mackel
5/21/2007 1:46:49 PM
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.

Thanks for all your input. I really appreciate it.
nb

0
Noble
5/21/2007 2:33:35 PM
Gregory Weston wrote:

> [...] 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?
0
silverdr
5/21/2007 2:58:52 PM
In article <4651b3aa$1@news.inet.com.pl>,
 silverdr <silverdr@inet.pl.remove.it> wrote:

> Gregory Weston wrote:
> 
> > [...] 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?

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."
0
Gregory
5/21/2007 3:17:52 PM
In article <1179758015.126928.281180@r3g2000prh.googlegroups.com>,
 Noble <NobleBell@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.
0
Gregory
5/21/2007 3:27:31 PM
In article <1179746512.204326.64790@x18g2000prd.googlegroups.com>,
 Noble <NobleBell@gmail.com> 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?

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/
0
Tom
5/21/2007 3:36:13 PM
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 ;-)

> 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.
0
silverdr
5/21/2007 3:40:50 PM
Noble <NobleBell@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.
> 
> Thanks for all your input. I really appreciate it.
> nb


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






    
0
mackel
5/21/2007 3:53:20 PM
In article <1179758015.126928.281180@r3g2000prh.googlegroups.com>,
 Noble <NobleBell@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.
> 
> Thanks for all your input. I really appreciate it.
> nb

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 - dakidd@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
0
Don
5/21/2007 4:24:48 PM
On 21 Mai, 15:19, mac...@nospam.fixe-post.de (Robert Welz) wrote:
> 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

0
Lothar
5/21/2007 4:36:27 PM
> 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

0
Lothar
5/21/2007 4:37:32 PM
In article <uce-6313B0.11273121052007@comcast.dca.giganews.com>,
 Gregory Weston <uce@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...
0
Steven
5/21/2007 4:41:30 PM
On 21 Mai, 15:19, mac...@nospam.fixe-post.de (Robert Welz) wrote:
> 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

0
Lothar
5/21/2007 5:04:41 PM
In article <4651bd80$1@news.inet.com.pl>,
 silverdr <silverdr@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
0
Gregory
5/21/2007 5:48:20 PM
In article <steve-B1B9C3.09413121052007@shawnews.vc.shawcable.net>,
 Steven Fisher <steve@pyile.com> wrote:

> In article <uce-6313B0.11273121052007@comcast.dca.giganews.com>,
>  Gregory Weston <uce@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...

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.
0
Gregory
5/21/2007 5:59:49 PM
silverdr <silverdr@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 ;-)

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
0
Michael
5/21/2007 6:12:13 PM
Lothar Behrens <lothar.behrens@lollisoft.de> wrote:

> On 21 Mai, 15:19, mac...@nospam.fixe-post.de (Robert Welz) wrote:
> > 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

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
0
mackel
5/21/2007 6:15:41 PM
Michael Ash wrote:

[...]

>>> 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 ;-)
0
silverdr
5/21/2007 6:49:42 PM
On 21 May 2007 04:21:52 -0700, Noble <NobleBell@gmail.com> wrote:
> 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

0
Paul
5/21/2007 7:16:34 PM
Noble <NobleBell@gmail.com> wrote:

> 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
0
noreply
5/21/2007 10:46:51 PM
In article <4651e9c4$1@news.inet.com.pl>,
 silverdr <silverdr@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).
0
Gregory
5/21/2007 10:58:18 PM
On 21 Mai, 20:15, mac...@nospam.fixe-post.de (Robert Welz) wrote:

> 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


0
Lothar
5/22/2007 8:59:03 AM
Lothar Behrens <lothar.behrens@lollisoft.de> wrote:

> On 21 Mai, 20:15, mac...@nospam.fixe-post.de (Robert Welz) wrote:
> 
> > 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.


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
0
mackel
5/22/2007 12:08:43 PM
Lothar Behrens <lothar.behrens@lollisoft.de> wrote:

> On 21 Mai, 20:15, mac...@nospam.fixe-post.de (Robert Welz) wrote:
> 
> > 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.


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
cruical it is good to have personal support. And free support, well,...

wxWidgets is not bad but not my flavor.

Greetings,
Robert

-- 
a
0
mackel
5/22/2007 12:09:50 PM
Lothar Behrens <lothar.behrens@lollisoft.de> wrote:

> On 21 Mai, 20:15, mac...@nospam.fixe-post.de (Robert Welz) wrote:
> 
> > 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.


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.

Personally I think for commercial software developing for which time and
money is
cruical it is good to have personal support. And free support, well,...

wxWidgets is not bad but not my flavor.

Greetings,
Robert

-- 
a
0
mackel
5/22/2007 12:11:40 PM
Noble wrote:

> 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


0
Gabriele
5/22/2007 3:25:55 PM
Noble <NobleBell@gmail.com> 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?
> 
> 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
0
mackel
5/22/2007 7:44:48 PM
Robert Welz <mackel@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*. 
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.

-- 
Michael Ash
Rogue Amoeba Software
0
Michael
5/22/2007 9:31:13 PM
In article <1179869473.13526@nfs-db1.segnet.com>,
 Michael Ash <mike@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
0
Gregory
5/23/2007 12:30:30 AM
This thread is really interesting me. I am gathering allot of useful
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

0
Noble
5/23/2007 1:53:55 AM
This thread is really interesting me. I am gathering allot of useful
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

0
Noble
5/23/2007 1:54:30 AM
This thread is really interesting me. I am gathering allot of useful
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

0
Noble
5/23/2007 1:54:47 AM
On Tue, 22 May 2007 16:31:13 -0500, Michael Ash <mike@mikeash.com> wrote:
> Robert Welz <mackel@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

0
Paul
5/23/2007 7:10:51 AM
In article <1179869473.13526@nfs-db1.segnet.com>,
 Michael Ash <mike@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.

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.
0
Steven
5/23/2007 7:25:45 AM
In article <slrnf57q7r.1ti.root@bourbiere.local>,
 Paul Floyd <root@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).
0
glenn
5/23/2007 2:43:29 PM
Steven Fisher <steve@pyile.com> wrote:
> In article <1179869473.13526@nfs-db1.segnet.com>,
> Michael Ash <mike@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.
> 
> 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.

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.

-- 
Michael Ash
Rogue Amoeba Software
0
Michael
5/23/2007 2:51:33 PM
In article <1179931892.989503@nfs-db1.segnet.com>,
 Michael Ash <mike@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
0
Steven
5/23/2007 4:33:00 PM
In article <steve-187AAB.09325923052007@shawnews.vc.shawcable.net>,
 Steven Fisher <steve@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.
0
Steven
5/23/2007 4:36:38 PM
Steven Fisher wrote:

>> 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.
0
Silver
5/23/2007 9:11:00 PM
In article <f32atd$4gl$1@nemesis.news.tpi.pl>,
 "Silver Dream !" <silverdr@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.
0
Steven
5/23/2007 9:12:27 PM
Steven Fisher 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.

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.
0
silverdr
5/24/2007 3:00:09 PM
silverdr <silverdr@inet.pl.remove.it> wrote:

> Steven Fisher 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.
> 
> 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.

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
0
mackel
5/26/2007 9:39:27 AM
silverdr <silverdr@inet.pl.remove.it> wrote:

> Steven Fisher 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.
> 
> 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.

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!

wish all the best!

Robert




-- 
a
0
mackel
5/26/2007 11:33:11 AM
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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/6/2007 3:47:00 PM
Jon Harrop <jon@ffconsultancy.com> wrote:
> 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.

-- 
Michael Ash
Rogue Amoeba Software
0
Michael
6/6/2007 5:13:03 PM
Jon Harrop wrote:
> 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.
> 
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. 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.
0
Lorenzo
6/6/2007 7:53:42 PM
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?

> 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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/7/2007 5:20:16 PM
Lorenzo Thurman wrote:
> 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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/7/2007 6:07:14 PM
Jon Harrop <jon@ffconsultancy.com> writes:

> 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
0
Sherm
6/7/2007 8:28:27 PM
Jon Harrop <jon@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...)

sherm--

-- 
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
0
Sherm
6/7/2007 8:40:43 PM
In article <46685c8f$0$8734$ed2619ec@ptn-nntp-reader02.plus.net>,
 Jon Harrop <jon@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
0
Reinder
6/7/2007 9:06:49 PM
In article <46685c8f$0$8734$ed2619ec@ptn-nntp-reader02.plus.net>,
 Jon Harrop <jon@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
0
Gregory
6/7/2007 10:21:51 PM
Jon Harrop <jon@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.

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.)

-- 
Michael Ash
Rogue Amoeba Software
0
Michael
6/7/2007 10:48:54 PM
Reinder Verlinde wrote:
> In article <46685c8f$0$8734$ed2619ec@ptn-nntp-reader02.plus.net>,
>  Jon Harrop <jon@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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/8/2007 10:48:38 AM
Sherm Pendley wrote:
> Jon Harrop <jon@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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/8/2007 11:00:53 AM
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.

>> 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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/8/2007 11:57:08 AM
In article <4669357f$0$8753$ed2619ec@ptn-nntp-reader02.plus.net>,
 Jon Harrop <jon@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.
0
David
6/8/2007 12:16:21 PM
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.

> 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...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/8/2007 12:42:37 PM
In article <46695036$0$8751$ed2619ec@ptn-nntp-reader02.plus.net>,
 Jon Harrop <jon@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++.

-- 
http://lispm.dyndns.org
0
Rainer
6/8/2007 12:59:33 PM
David Stone wrote:
> In article <4669357f$0$8753$ed2619ec@ptn-nntp-reader02.plus.net>,
>  Jon Harrop <jon@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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/8/2007 1:26:30 PM
In article <4669458d$0$8716$ed2619ec@ptn-nntp-reader02.plus.net>,
 Jon Harrop <jon@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.
0
Gregory
6/8/2007 1:42:07 PM
In article <4669385e$0$8721$ed2619ec@ptn-nntp-reader02.plus.net>,
 Jon Harrop <jon@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.
0
Gregory
6/8/2007 1:43:36 PM
In article <4669357f$0$8753$ed2619ec@ptn-nntp-reader02.plus.net>,
 Jon Harrop <jon@ffconsultancy.com> wrote:

> Reinder Verlinde wrote:
> > In article <46685c8f$0$8734$ed2619ec@ptn-nntp-reader02.plus.net>,
> >  Jon Harrop <jon@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
0
Gregory
6/8/2007 1:59:00 PM
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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/8/2007 2:22:16 PM
Jon Harrop <jon@ffconsultancy.com> wrote:
>> 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
Rogue Amoeba Software
0
Michael
6/8/2007 2:34:02 PM
Jon Harrop <jon@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.

> 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.

-- 
Michael Ash
Rogue Amoeba Software
0
Michael
6/8/2007 2:37:25 PM
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.

> 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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/8/2007 2:46:20 PM
In article <46696791$0$8748$ed2619ec@ptn-nntp-reader02.plus.net>,
 Jon Harrop <jon@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.
0
Gregory
6/8/2007 4:17:27 PM
In article <46696d35$0$8756$ed2619ec@ptn-nntp-reader02.plus.net>,
 Jon Harrop <jon@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
0
Gregory
6/8/2007 4:26:05 PM
In article <1181313241.744701@nfs-db1.segnet.com>,
 Michael Ash <mike@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.
0
Gregory
6/8/2007 4:42:09 PM
Michael Ash wrote:
> Jon Harrop <jon@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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/8/2007 5:31:17 PM
Sherm Pendley wrote:
> Jon Harrop <jon@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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
0
Jon
6/8/2007 5:45:43 PM
On Fri, 08 Jun 2007 12:57:08 +0100, Jon Harrop <jon@ffconsultancy.com> wrote:
>
> 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

0
Paul
6/8/2007 5:57:46 PM
In article <46699740$0$8744$ed2619ec@ptn-nntp-reader02.plus.net>,
 Jon Harrop <jon@ffconsultancy.com> wrote:

> Sherm Pendley wrote:
> > Jon Harrop <jon@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.
0
Gregory
6/8/2007 9:55:26 PM
Jon Harrop <jon@ffconsultancy.com> wrote:
> Sherm Pendley wrote:
>> Jon Harrop <jon@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.

-- 
Michael Ash
Rogue Amoeba Software
0
Michael
6/8/2007 11:03:23 PM
On 2007-06-07 18:21:51 -0400, Gregory Weston <uce@splook.com> said:

> 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.

0
Raffael
6/8/2007 11:09:01 PM
Jon Harrop wrote:

>>> 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.
0
silverdr
6/10/2007 10:36:10 PM
Reply:

Similar Artilces:

Programmers, Programmers, Programmers, ...
As Steve Balmer correctly stated, while making his monkey dance, it is applications and hence programmers that make a platform. The fact though is that if you want to do professional programming, then Linux is the platform for you. I know that this statement will get the heckels up on a lot of trolls in C.O.L.A, but I have a recent experience that proves this. I am currently working for a Windows only house producing a system that receives and transmits around 1000 telegrams per second in each direction on a UDP socket, translates them into a different format and creates a log entry for each ...

Help! iSync mac to mac
Am I right in saying that with iSync, if you want to sync 2 macs together (address book, iCal etc.) the only way to do this is via a ..Mac account, even if those computers are sitting not 5 feet from each other, both Airport equipped? If this is the case, I've never heard anything so ridiculous. Is this just part of another apple scam to get more money out of us? Does anyone know if this is indeed the case, and can you recommend any other sync software out there? I'm setting up an iMac, eMac and powerbook g4 for a friend's office, all running OSX Panther, and you'd think basi...

No Mac Help in Mac Help?
When I go to Mac Help in Finder (latest version of OSX Tiger) I get nothing. The window pops up but it's blank. Click on the little house and the initial screen fills in but nothing beyond that. I had a simiar problem with Safari help some time back and someone suggested I remove a folder from Library/Caches, (com.apple.helpui or something similar) and that did the trick for Safari's help. I honestly don't recall if I've ever had the Mac Help or I've just never used it since this machine. The problem happens on or offline so I'm not sure where the Mac Help file re...

To Mac or not to Mac?
What ho, pre-pressers! Long time no post, or view, come to that. No doubt some of you will remember me as I see that many of same crowd are **STILL** here after all these years. Grettings to Aandi, Ted, Lee, Allen...well, to you all, not forgetting Mr Shagnasty, who I am gratified can still find something to say after all this time. Right, greetings over, down to brass tacks. My early retirement plan has sadly fallen through and I find myself back at the coal face possessed of some pretty antideluvian equipment with which to earn a crust for the Tree family. So I'm looking for **SE...

Mac to mac
I just remembered these groups and wondered if someone here could tell me whether what I'd like to do is possible. (NO ONE around here knows anything about Macs) I have a G4 that was the top of the line in 1998. It will die one of these days. It's currently running OS 9.2.2. Someone else(who now lives far away) installed the internal modem, SCSI for my scanner, and my floppy drive (so I didn't have to go through hundreds of them for the bits and pieces I might someday want again). I still have the floppies and a number of Zips, all of which this computer can read. Install...

Is there a Mac programmer...?
Is there a mac programmer who wants to compile an utility for Canon 400D camera? ------------------------------------------------------------ - FocusAssist v0.1 for Windows 2000/XP - A Mac version is within the realm of possibility, since both Canon's SDK and the GUI library I used (wxWidgets) support the Mac as well as Windows. If you are a registered Canon SDK developer, have a Mac, and want to try and compile it, contact me and I'll send you the source. http://www.xmission.com/~jstanley/focusassist/ ------------------------------------------------------------- http://snipurl.com...

When is a Mac not a Mac?
This was posted in a forum recently and I thought it brought up some very interesting points relating to the Eula. For reference: http://forum.insanelymac.com/index.php?showtopic=105546 ------ This question is related to licensing OS X on a machine. The EULA says it has to be an Apple computer, before the Apple License will apply, which means Apple will only support OS X on Apple machines. So, I'm wondering, when is a machine considered an Apple Mac, for the purposes of Licensing and recieving support? Say I buy a Mac from Apple. Then the hard drive fails, and I replace that with an ...

Where to look for help (confessions of a mac/unix programmer)
I need a tutorial... I'm a mac/unix guy looking into programming windows for the first time. I have the Petzold book. I've downloaded tools from MS, in the form of Microsoft Platform SDK for Windows XP SP2 (i'm using sp2) Microsoft Visual C++ Toolkit I've edited environment variables (PATH, INCLUDE, and LIB)in the C++ Toolkit file vcvars32.bat to point at the appropriate directories in the SDK. Now, I start a shell using "Visual C++ Toolkit Command Prompt", and use cl to compile my simple file (which contains the first Petzold example). First,...

MAC RS232 / USB programmer help needed
Hi, I'd like to colaborate with a MAC programmer to port an application I'm writting onto a MAC platform. The application's engine is all ANSI C and the GUI is in QT, so those parts should work fine on Windows, Linux and Mac. However, the program needs to interface with the serial ports (RS232 and USB). I'm a linux guy myself, and even though MAC looks to be based on freeBSD, I dont feel confidant to write that part of code myself (that and the fact I dont own a Mac). The interface code is very simple and would consist of 3 API's. A setup API, "get...

Non-programmer needs help on Mac/Wx installation
I've used 2.1 in peace for a long time, but unauthorised computer removal meant an upgrade to MacOSX and Python 2.3. Problems ensued: after downloading Macpython2.3 the python launcher didn't work, and Tkinter wouldn't work: although some demos ran, none of the windows had full function, ie. couldn't be resized or closed. I installed the aqua program, which didn't seem to help, although I gained a new interpreter. I installed WX in the Python 2.3 directory, and although I can now import Wx, no code will run, and the interpreter will not identify the problem, apart from ret...

Help! I've Been Forced To Use A Mac, Online Help for Mac?
http://www.suggestafix.com/index.php?showtopic=33751 Help! I've Been Forced To Use A Mac, Online Help for Mac? Aug 29 2009, 12:23 PM Post #1 Group: Star Member Posts: 297 Joined: 31-May 06 Member No.: 14,025 Today, for a hopefully brief period of time, I'm being forced to use a Mac. Since these machines are incomprehensible, I need a simple piece of information*. I know this is heresy, but . . er . . is there anywhere on the Net where peeps answer questions without offering them the choice of (1) $15 (2) $25 or (3) $50 for the answer. ~ beau (but don't tell anyone I asked...

Looking for a Mac programmer...
still able to write an OS9 extension. Thanks for your reply, DM Quark Xtension or System Extension ? Bruno > still able to write an OS9 extension. > > Thanks for your reply, > > DM > System Extension. DM > Quark Xtension or System Extension ? > > Bruno > > > still able to write an OS9 extension. > > > > Thanks for your reply, > > > > DM > > ...

Looking for a Mac Programmer...
Hey Everybody! So, I'm trying to find a Mac programmer for what I think is a fairly simple programming project for an to-do application I've come up with. I'm a Mac Expert but my programming extent goes to some apple script and HTML. Price, terms, etc negotiable; ideally, we would collaborate on this piece and then distribute it as shareware or donation ware. Let me know if you've got the Cocoa or Objective-C skills to put something together, and I'll explain my vision! ...

The mac for Java programmers
I have composed a page with a summary of the MacIntosh which I hope will help Java programmers write code and instructions for the Mac. I don't have a Mac myself, so I would appreciate it if anyone with a Mac could check that I got it right. Additional lore to include, and suggested links welcome. see http://mindprod.com/bgloss/macintosh.html -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com In article <8n3oa49lipvs93dfpqlco4fv02gt1i8n1t@4ax.com>, Roedy Green <see_website@mindprod.com.invalid> wrote: > http://mindprod.com/bgloss/macintosh.ht...

Looking for a Mac programmer
We are looking for a Mac programmer for a freelance job, probably requiring 50-100 hours of work. We need a program to be written in Cocoa (Carbon is ok), requiring some network communications (data to be sent to a webserver periodically). This is a port of a small Windows product; we also need a small interface. Knowledge of low-level OSX system programming is a plus. I know this is a vague description...but I didn't want to post the whole project requirements on the web here. Please respond, if interested, via e-mail, to alex AT systeris DOT com. We are based in Cambridge...

Looking for a Mac Programmer...
Hey Everybody! So, I'm trying to find a Mac programmer for what I think is a fairly simple programming project for an to-do application I've come up with. I'm a Mac guy but my programming range goes as far as some apple script and HTML. Price, terms, etc negotiable; ideally, we would collaborate on this piece and then distribute it as shareware or donation ware. Let me know if you've got the Cocoa or Objective-C skills to put something together, and I'll explain my vision! ...

bmp-mac, mac and xmms-mac ports
Hello, I can't find these in the ports collections, so i've downloaded and compiled mac and xmms-mac successfully and have confirmed that they work on FreeBSD. I was looking for an APE (Monkey Audio) plug-in for XMMS in the ports collection but wasn't able to find one. I had a bit of trouble with compiling xmms-mac to start off with. The compilation would fail with the following: g++ -I/usr/X11R6/include -I/usr/X11R6/include/xmms -I/usr/local/include/gtk12 -I/usr/local/include/glib12 -I/usr/local/include -I/usr/X11R6/include -s -O3 -Wall -pedantic -DBUILD_CROSS_PLATFOR...

It's a Mac, Mac, Mac World
I wonder how the Windows users would like my (ab)normal Microsoft-free world: My business: all Mac, no PCs. My dentist, family physician and urologist are all Mac. No PCs. Went to Sir Speedy today for more bus. cards and some binding: all Mac (no surprise there). My daughter's three new college room mates have emailed her. Two have PowerBooks and one has an eMac. (She has a G5 iMac.) I never even see a PC unless I am at the public library or a store using a Windows POS unit. It never was intentional. I don't scout a place to see what frickin' computer they use. Jus...

Need Help for Transfer Mac--->Mac
Couple years ago, I gave my trusty old 7200/75 mac to a friend who finally gave up on Windows, in frustration. I told me that it on old machine and that he could get a decent newer machine for not very much. But he wanted to try it and it turned out that he was happy messing around with the old clunker, using System 9.2. Recently he finally acquired a newer Mac, a G3 with OS X. There are some documents that he would like to transfer from the old machine to his new one. unfortunately he doesn't know how to do this. Until last year I was his computer support but now he has moved aw...

Mac to MAc Firewire
Hey all Looking for some help. I am trying to use a 6-6pin 1394 cable to connect two iBooks together and transfer some large files. iBook 1 dual USB 'white' iBook OS 9.2 iBook 2 G4 OSx 10.2 I boot iBook 1 into 'target drive' mode and get the firewire icon dancing about the screen then connect it to iBook 2 but the drive does not appear on the desktop. I have tried all combinations of rebooting/ connecting before and after rebooting but nothing seams to work. When the firewire is plugged in the target disk makes a short noise then nothing the host does not appear to react at ...

Mac-to-Mac VPN?
Years ago, I set up a Mac network (under OS9) with a VPN router and some software on a remote PowerBook that allowed VPN access. I'm not terribly familiar with OSX yet, but I understand that much of this functionality is now built in. Can anybody steer me in the right direction as far as hardware, software and configuration? Here's the setup I envision: - Small LAN running two Macs and a printer with a DSL connection through a router. - Remote PowerBook connected to the net varyingly with dial-up, DSL (wired), and AirPort. - Use the PowerBook to securely connect to at l...

networking mac to mac???
Hello, Can someone out there tell me the best (easy) way to network a ibook running os.9??? possibly to a new imac running osx 5wak <rosscoism@gmail.com> wrote: > Hello, Can someone out there tell me the best (easy) way to network a > ibook running os.9??? possibly to a new imac running osx Put an ethernet cable between them, enable tcp/ip and file sharing on one and log on from the other, seems to be what you are asking for? And you do not need a cross-over cable between modern Macs. -- /Jon For contact info, run the following in Terminal: echo 361993718603049801070734...

MAC to MAC connectivity
Hi, As part of a design that I'm investigating, I am looking at connecting a number of FPGA based MACs to a dedicated broadcom switch chip. The difficulty with this is that to interface both chips, I need to have two closely coupled and redundant PHY . Is it possible to connect two MAC (SGMII) directly point-to-point, bypassing the PHY completely? Or is it necessary to have at least some PHY functionality, even if it is a point to point link? Kind regards, Stephen Steve wrote: > Hi, > > As part of a design that I'm investigating, I am looking at connecting > a number...

When is a Mac no longer a Mac?
OK, so Apple's going to go to Intel CPUs. Now Macs are no longer differentiated by a slow clock and superior instruction set--we've got the same hackjob clusterfuck on speed PCs have been using for decades now. And over the last few years Apple's gone away from SCSI, NuBus, ADB, Localtalk, etc. And PCs have picked up USB, dropped floppies, and colored their cases. The hardware's basically merging between the two platforms. On the software side, the classic MacOS is gone, replaced by Unixy stuff. And like it or not, higher up on the UI level lots of Windows-li...

Web resources about - What do Mac Programmers Prefer? - comp.sys.mac.programmer.help

Programmer - Wikipedia, the free encyclopedia
A programmer , computer programmer , developer , coder , or software engineer is a person who writes computer software . The term computer programmer ...

Programmer - Wikipedia, the free encyclopedia
A programmer , computer programmer , developer , coder , or software engineer is a person who writes computer software . The term computer programmer ...

Contract Analyst Programmer (MS.Net/Visual Basic) 160129/AP/vtd
Defining Technology for Australia's IT Leaders.

Managing Programmers
Programmers are not like the other kids. They cannot and should not be managed like normal people if your intent is to produce high quality software. ...

Programmer who aided financial malware to be sent home to Latvia
Deniss Calovskis, who pled guilty in 2015, has served 20 months combined in Latvia, US.

Two Valley teen programmers have started a movement where kids teach other kids how to code
While other high school kids spend their weekends playing sports, video games and hanging with friends, two Palo Alto teenagers spend their free ...

Prominent Programmer Dies In Apparent Suicide After Violent Encounter With San Francisco Police
A prominent member of the open source programming community died in an apparent suicide on Monday, days after a violent encounter with San Francisco ...

Programmers: It’s time to tame Python
If you’re pursuing a career in coding, you’re going to have to reckon with Python, one of the most popular programming languages in use. A valuable ...

Uber Hires Programmers Who Can Win A Fight With Their Robot
Tech companies like Uber and Dropbox are using CodeFights, a platform that enables programmers to compete with one another to solve coding challenges, ...

Fighting ‘ticket bots’: Washington AG says it’s too early to tweak state law to protect altruistic programmers ...
... to pillage vast amount of show tickets. Rep. Jesse Young, R- Gig Harbor, has introduced a bill to slightly change that law to protect programmers ...

Resources last updated: 2/17/2016 1:36:43 PM