Re: M2 for iPhone?

On 2009-04-15, beekay.noreply@xxxxxxxxx <beekay.noreply@xxxxxxxxx> wrote:

( I got a bit more clarity about your reasons for Objective M2 now. And
while I'm not (yet) in the ObjC/Smalltalk camp, assuming I were, I
understand and underwrite them.

Let's focus on the OS interface part of the discussion. (the first few and
last paragraph)
)

Then you misunderstand my point. It is more about free choice of language
and development tools than about PDP-11.

My point was that the way OS APIs have come to look like across
platforms is an accident of history which might have turned out
differently.

Well, I do not agree. A few systems that were mostly academic-only, like the
LISP workstation (AI labs mostly), and Oberon are IMHO bad examples.

And the reason why LISP didn't prevail is not sheer coincidence, but because
the procedural (which is IMHO totally not the same as Unix-) way was simply
an acceptable compromise for a computer community fragmented over a
gazillion languages and runtime systems, and LISP with its very specific
demands and engine not. Except on my HP calculator that is.

Well, different vendors bet on different models and some models
survive, some don't, sometimes vendors don't survive.

I hope the ones that try to force languages on the users don't make it.

The Lisp vendors all disappeared, many of the Unix vendors survived.

Yes. Microsoft and IBM. However Microsoft is not very active in Unix land
anymore (or after say 1990), and IBM distributes a third party product
(Linux) as much as its own Unix (AIX).

Sun is on the verge of being taken over, one of Santa Cruz offspring, SCO ,
is in bankruptcy procedings, the other is Novell which is peddling Linux,
HPUX is on lifesupport due to longliving contracts, but HPs main business is
windows servers. Wind River stopped major BSD development afaik.

Short: Old Unix is dead.

Users exercise their choices by using whichever products they want to use.
This is how we got where we are now.

I consider that a bit naieve. They can vote with their feet of course, but
in general there are more reasons to be attached to a platform than just
language and interfacing.

I prefer to use something like vanilla C or Pascal or Modula-2 for the
former and the Smalltalk derived extensions and class system in ObjC
for the latter. Other people have different preferences, fair enough,
but as far as separation by problem domain goes, I am doing the very
same thing: different language for a different problem domain, I just
draw the boundaries differently.

We'll see. I meant a bit more domainspecific btw ;_)

it does for me. The reasons why I want to replace the C base with
somehting else have to do with C itself, not anything that the hybrid
can be held responsible for. If you mix C with whatever else, you will
of course inherit from C, including that which you'd rather not have
inherited, for example the absence of modules (in ObjC only classes
are modules, the rest is just like C).

Clear, and I of course fully agree with that.

With a hybrid like Objective-C I no longer have to make this choice, I
get both in one.

We shall see. I sincerely hope you get the best of both worlds, and not the
worst of them.

Maybe you misunderstand my situation. I have been using ObjC for many
years and what I said reflects my experiences using it.

I think I did yes. It is more replacing the C underpinnings of Obj-C with M2
than developing a new hybrid concept. It makes more sense now, thanks.

Indeed I missed that the C basis is of course still there in Obj C. I assume
imperative modules are also still supported? (based on your namemangling
remark).

Absolutely, that's one of the main reasons why I wanted M2 as the base
language instead of C.

Clear, so we got that part sorted out.

If you support local procedures, the array thing is probably a minor
annoyance indeed.

It would of course be easier to leave local procedures out to get
started even faster, but that's one of those things that always upsets
me about C (that I don't have local functions), so this is something I
definitely didn't want to sacrifice, not even temporarily.

Maybe I should clarify that:

The ugly problem is the passing nested procs as procvar to something else,
while they can still access their parents variables. At least in Pascal.
(and Borland style Pascals, FPC included don't do that properly). How is
that in M2? I wasn't as deep into such details yet when I did M2.

No. I don't really program embedded for FreeBSD/Linux atm. If you know a C
one, it probably can be ported.

There is GNU pth and libtask. I use libtask because its lightweight and I
don't need many of the fancier features in pth, but GNU Modula-2 uses pth
and Gaius seems quite happy with it. GNU pth is probably more portable.

libtask is MIT/BSD, GNU is LGPL. Since for embedded applications you'd want
to statically link, licensewise I'd prefer libtask.

Ah, what is the substitute for the static validation generics in static
languages more or less guarantee?

If I understand the question correctly, you want to know how do you
ensure that the class written with dynamic typing in order to handle
different types of data can actually handle the data its being passed.

Yes, and as much of it without running it, since testing all codepaths for
every build is often hard in reasonably sized apps. IOW how do I avoid
programmer errors.

I actually don't use dynamic typing a lot, but there are situations where
it does make life easier.

I think that is the answer: You don't mass apply it, only when needed.

(skipped parts about the hybrid. As said I missed the part that statical C
is fully in Obj C).

Hmm. It is usually so yes, but that is a VM/GC strategy choice rather than a
language choice I think. It is often more the installed base of existing
code than the language spec that sets the initial choices in stone.

As far as I can see, many of the languages around these days are
designed specifically to have gc, or not to have it. The only language
I know of where you can just link to a library and get gc as a result
of that is C with the Boehm collector. But even then, everything is
being collected.

( I don't see btw why it wouldn't work for Pascal and/or most other static
languages, and afaik there are people that do such things in Delphi, though
I don't know on what scale. Some might need a bit more runtime library
adaption than C (to avoid trouble with automated types), but not too much)

Sufficient to say that in general the main focus of a toolchain is often the
best tended to, and the presence on other targets less. And it is hard to
remain productive without peers that do things you also would do.

syntactic sugar and more classes, but essentially, the whole thing is
still functionally the same it was when all the Wallstreet who is who
used it to model their financial stuff with it.

True. But the point is if I'm a non-Mac stepper, my circle gets awfully
small.

Of LLVM, but not of the control of Apple over the access. If you can't
install the forked LLVM (because it has become a part of the OS), you can
fork till you turn blue without fixing this problem.

I think Apple can impose this kind of control on a phone, but not
elsewhere. If you cannot use any other compiler than Apple's, not
because there is nobody who wants to build one, but because Apple
doesn't allow it, I think that would probably kill the platform. I
might be wrong but I don't think that is the direction they are going.

I think it is, albeit very slowly and phased. And maybe the initial reasons
where more architecture independance related, and making a start with
avoiding legacy software that inhibits that. (with all Mac arch conversions
m68k->ppc32->ppc64->x86->x86_64 (soon)).

But the result is still the same: making choice harder.
.

Relevant Pages

  • Re: FORTH levels
    ... Forth does not enforce a grammar ... We needed a language, not just a vocabulary, but nobody recognized the distinction. ... those systems were largely running code written in the time frame before the Unix systems showed up. ... Maybe some reasons could help to improve ...
    (comp.lang.forth)
  • Re: Is VB Caca??
    ... Calling a function of a language "quirky" seems terribly judgmental. ... with all of the VB6 work out there that has not been converted to VB.Net, ... like Java fundamentally yet program in VB.Net for economic reasons and ...
    (microsoft.public.dotnet.languages.vb)
  • Re: defining the behavior of zip(it, it) (WAS: Converting a flat list...)
    ... The real spirit of zipis ... a full understanding of zipcan be had by remembering ... making this a defined behavior results in making the language ... your reasons is ...
    (comp.lang.python)
  • Re: Speed Test between C and Fortran 95
    ... forgetting to recompile after editing, 3) forgetting to save the edited ... I'll also note that all generalizations are false. ... than C." There can be several reasons to recode something in a different ... language, but I wouldn't suggest undertaking a huge Fortran/C conversion ...
    (comp.lang.fortran)