Re: In the Shallow End

"GreyCloud" <mist@xxxxxxxxxxx> wrote in message
news:-OGdnY_Y-I_AZEHZnZ2dnUVZ_tSdnZ2d@xxxxxxxxxxxxxx
Dan Johnson wrote:
And MS's transparency is much better for developers than
Apple's secrecy.

Transparency? You mean vapour-ware.

Well, the two go together. But developers find it
very hard to change directions as fast as Apple
would have them do so. Microsoft gives them a
lot more lead time.

That Apple even keep the Intel Switch
secret, and surprised developers with it, is very remarkable,
but it is also very, very hard on Apple's developers.

Not really. If you've studied XCode, you'd know that when you
compile the code, the code will detect which arch to run on.
That's why it is called universal binaries.

I have studiend- and used XCode, and I know how this works.

And that is not how.

You check some checkboxes in XCode and it then compiles
your program twice, once emitting PowerPC and once x86
output. (And twice more if you want to add 64-bit supports, too!)

These binaries are merged, so you get one file for each target's
output, containing both kinds of executable code.

When a user launches the resulting program, the loader
selects which binary to actually use depending on the
processor it runs on. It prefers, I believe, native over emulated
code, then 64-bits over 32-bits. If necessary the loader will
start Rosetta, and off you go.

It's called "Universal Binaries" because you get a binary that
runs on any architecture.

But the fly in the ointment is the compilation step; you
compile your source *twice*, and get two different
outputs. In C, C++ and Objective-C there's a lot of wiggle
room in the language definition, and the compiler can
produce quite different behaviors for the different
versions.

The fact that a company can keep a secret is quite common in industry.

It is. Doesn't mean its a good idea though.

[snip]
A different scenario for MS. For Apple it didn't matter. All the
developer needed to do was recompile his own code for intel versions.
The PPC will still run the universal binaries.

This is not all a developer needs to do. Even for the
simplest cases, you have to test and debug on the new
architecture. The behavior of your program is changed
by the compiler when it targets a new architecture.

Compilers are allowed to do this for performance
reasons, but its very awkward for porting. More
recent langauges (Java, C#, etc) nail down behavior
much more strictly precisely because of this problem.

[snip]
No. Shipping features is not especially easier
in Unix.

Of course it is. Once you understand how unix works, the rest falls into
place.

No. I've programmed on Unix professionally, and I didn't
like it much. Unix, qua Unix, provides very little in the
way of applications serves.

An idea, once figured out, usually comes to fruition faster on Unix than
it will in windows... especially when using Objective-C.
What we are seeing now are the modules being better utilized.

I see; you imagine that Mac OS X is good precisely and strictly
because it is Unix like. That's mistaken; Apple has added
a *large* amount of value to the basic Unix-like architecture.

A lot of it is really NeXT's code, but it still helps.

Normal Unixes do not use Objective-C but C, or C++ if you
are lucky. They do not have a framework like Cocoa,
never mind all the stuff Apple has added. There's stuff in
there that even Windows hasn't got.

I tend to think that overall, programs written to Cocoa will
ship features easier than those written to Carbon, or for
that matter Win32. But this is not a Unix thing; it's a
NeXT thing.

The advantage here is mostly that the "native language" of
Cocoa is Objective-C, and the "native language" of
nearly everybody else is just C. There's a productivity-sapping
impedance mismatch if you use any other language but the
native, even a closely related one (like C++ on Windows
say).

[snip]
XCode is widely derided as not ready for the big leagues;
it's performance is not there yet. It doesn't scale to large
projects. Perhaps XCode 3 will fix this.. when it ships.

That was taken care of in XCode 2.1. The core is Gnu compiler set... and
they've tightened it up quite a bit. It used to be that Suns C compiler
generated 45% better code, but not anymore.

No, the issue is not the performance of the generated programs,
but the speed of the IDE *itself*. It bogs down on large
projects. It is slow to open files, slow to edit files.

Heck, even on small projects the code-sense they have
is terribly slow.

Objective-C is an old and unlovely language, which
Apple is trying to make presentable. But they are rather
late to the game, and are now far behind the efforts
of Sun and Microsoft.

Does better than the windows APIs that are written in straight C.

Ya. This is one key advanage they have on Windows;
you *can* program Windows in C++, Ob jective-C, C#,
or many many other languages, but there will always be
a translation layer in your way, causing problems.

But even so these enhanced langauges are worth it. And
MS is working on the problem; the version of .NET that
will ship with Vista will offer its own UI support that
won't just wrap Win32, and that's the biggest remaining
piece they don't have yet. This will make C# much more
competitive, and it's pretty good even now.

I've already been there, and nowhere is anything in Visual Studio is like
Objective-C. I find it faster to get code out in XCode compared to VS.

Objective-C is a strength because it's the native language
for Cocoa, and C-based APIs will always be at a
disadvantage next to that.

But C# *as a language* is much nicer than Objective-C:
It's got:
o Constructors
o Namespaces
o Nested Classes
o Abstract Methods & Classes
o Sealed Methods & Classes
o Attributes
o Delegates
o Events
o Properties
o Operator Overloading
o Foreach Loops
o Safe Switches
o Generics
o Closures
o Generators
o Fixed blocks

Plus a syntax that isn't a crawling horror for the sewers
of hell, much stronger typesafety, and it generates 'safe'
code by default. And it uses the more popular
Simula cast-and-dispatch semantics.

Much of this will seem rather pedestrian to, say,
Java 1.0 users- but Objective-C hasn't got any of
that stuff.

Objective-C has:
o Categories
o Class Methods
o Selectors

And it uses the less popular (and slower) Smalltalk
dynamic dispatch semantics.

In short, it's Cocoa that makes Objecive-C
worthwhile.

[snip- web clipping widget]
What's depressing is that Apple was reduced to demoing
that as a Great New Feature.

Depressing? I thought it was great. You want to know what depressing is?
Watching M$ demo their speech recognition software.

That's entertaining! *Especially* when it breaks. :D

[snip]
Yes. Perhaps Time Machine's UI will be the Best Restore UI
Ever. I haven't used it, and we've only seen it briefly. It's
awfully heavyweight and terribly whizzy, but it may work.

Of course it will work. Most end users, those that just buy a PC out of
the box, have no idea what a backup is. This will alleviate some headaches
for a lot of that type of user.

Unless Apple will sell their new Macs with two disks
each, they still won't know, and won't be helped.

Time Machine requires a second disk of some kind to
backup to. Slick UI, but the hard problem remains
unsolved: how do you handle backup for very naive users
who don't know about it, and wouldn't care if they did?

[snip]
Er, I have never used a virtual desktop utility that can't
do that. It'd be quite limiting not to have that.

Have you ever used CDE?

No, but I understand it's a crawling horror.

I last used virtual desktops years ago, on Sun
boxes. I could do this then- it involved dragging little
wireframe proxies for the windows between little
proxies for the virtual desktops.

I forget which window manager this was, though.

[snip]
I have done that; it looks like incremental backup to me.

Got a better idea over incremental backup? In this case it is done daily
automatically, and is a good idea.
What does MS have in mind for Vista?

They have incremental backup there too, of course.

They also propose to bring Windows Server 2003's'
Previous Versions feature to Vista.

Each time you save the previous version of the file is
retained, and can be recovered. There's a way to get
deleted files back, too. The old copies are stored
on a per-block basis, so its uses less space, and it
does not need a separate backup media.

The UI is done with list views and isn't terribly whizzy,
but it is available today in Windows Server, and will
be in a Vista near you soon! :D

Notice that Apple emphasises the UI in the demos, and
they don't talk about the underlying tech. Notice that
they only ever restore individual files. Notice that they
never talk about the *backup* part, just the restore part.

The backup is automatic.
The underlying tech does not need to be demoed in this case...
Unix is the tech.

You got a Unix fixation there.

I do not know what they are using for backup
exactly; I wouldn't be surprised to learn it just
the old open-source backup tools.

If so, you could demo them, but it would be a yawn,
so it is no wonder they didn't.


.

Relevant Pages

  • Re: In the Shallow End
    ... You have the Gnu compiler that can do it. ... No one wanted NT because they had better o/ses for these archs, like OpenVMS or Tru-64 UNIX and better tools. ... you'd have known why it is easier to do in UNIX compared to Windows NT and its later revisions. ... That's mistaken; Apple has added ...
    (comp.sys.mac.advocacy)
  • Re: In the Shallow End
    ... and the compiler can ... Unix, qua Unix, provides very little in the ... you'd have known why it is easier to do in UNIX compared to Windows NT and its later revisions. ...
    (comp.sys.mac.advocacy)
  • Re: parse error before = token
    ... >>> (Did you copy the file from a Windows machine to a Unix box, ... >> have a C compiler that can't handle newline characters ...
    (comp.lang.c)
  • Re: OT - Any Backup software for LINUX that will backup windows client & Server?
    ... > solution that will run on Linux and that will backup not only unix boxes ... The backup media is a DLT-200GB tape. ... FWIW ArcServe has Windows, Macintosh OSX and Unix ...
    (Fedora)
  • Re: parse error before = token
    ... >> (Did you copy the file from a Windows machine to a Unix box, ... > character with value 13, ... > have a C compiler that can't handle newline characters ... Unix text files use a single LF character to mark the end of a line; ...
    (comp.lang.c)