Android—Why Dalvik?

[BGB]

of course, C# is currently up there as well, so it is mostly a battle
between C, C++, Java, and C# for the title of "most widely used
language...".

That's a meaningless title unless you define it. Used by the most
programmers? Used by the most "applications" (however that would be
defined)? Most SLOC or function points or some other dubious code
metric? Ever? In the last year, month, week?

TIOBE's rankings are suspect, as is their methodology, but at least
they have a method - they're not just pulling a list out of their
collective ass.

FYI, the most recent short-term TIOBE rankings are Java, C, C++, C#,
PHP, Objective-C, Python, "(Visual) Basic" (a dubious entry), Perl,
and Ruby, in that order.[1] That's for May 2011. (RPG has risen to
#20, by the way, from #25 last year. Time for everyone to refresh
those RPG skills!)

Their long-term data shows Java and C securely holding the top two
spots for the past decade. C++ briefly beat C for the #2 spot a couple
of times, but it didn't last.

But as I noted, the TIOBE rankings are suspect. They're based on
things like advertised positions and classes, so they mostly measure
demand or perceived demand in various markets.

but, alas, these measures are probably adequate...


if I were to ass-pull a list, mostly from most common personally
encountered code, it would likely look more like:
C
C++
Java
Perl
Python
Bash / Shell-Scripts
....

And simplistic interpretations of their data are likely to be
misleading. For example, they rank COBOL at #37, well below, say, Logo
(#24). (Time to brush up on those Logo skills!) But there are a few
billion lines of COBOL application source code still under
maintenance. They're rarely touched (indeed, businesses are
tremendously wary of touching them), because they encode business
rules. But they still exist and the programs compiled from them are
still used. Does that mean COBOL is under-ranked? Only if you
interpret the TIOBE rankings to mean something other than what they mean.

my main interpretation is more like:
top of the list means top of the list (getting things to the top of a
given list is often regarded as a goal in itself, like the "yay, we're
number one, in your face, ..." sense);
top of the list also means generally most popular languages;
languages near the top are more likely to be more "acceptable" to people
than those lower on the list;
....

Similarly, we see TIOBE ranks Alice (a language in the ML family) at
#35, and PL/I at #42. Alice is free, and comes with a free IDE. The
major PL/I implementations - IBM's and ours - are expensive. But we
still sell a goodly number of PL/I licenses, and all evidence suggests
IBM does too. We don't see PL/I customers rushing to switch to Alice.
Or even, say, C, which is more like PL/I and is the #2 language.

actually... I had thought they meant Alice in the sense of the CMU+EA
thinggy, which involves drag-and-drop to control 3D characters and was
meant as a teaching tool... either way, it would be a surprise if it
gained a whole lot of status... even more so if people were actually
trying to write serious "software" with these drag-and-drop
character-control commands...

it could make more sense as a storyboarding/pre-vis tool though...

but, yeah, if it is some other real programming language, that makes a
little more sense...

[1] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

 

[Michael Wojcik]

=>
more like "there is no universal standardized C ABI...", and nothing is
stated in the C standards to this effect, but, there ARE C-ABIs...

Wrong. Those are platform ABIs. They have nothing to do with C, a
language defined by ISO/IEC 9899, and not by implementations thereof
or their dependencies.

http://en.wikipedia.org/wiki/X86_calling_conventions

note also:
http://agner.org./optimize/calling_conventions.pdf

Neither of which have anything to do with C.

much like there is a C++ ABI (or more correctly, many C++ ABIs...).

Yes, insofar as there is no C++ ABI (much less "many C++ ABIs").

but, the "standardized" (in a largely de-facto sense) ABI for C on
32-bit x86 is commonly known as cdecl, but it has other names.

Microsoft's cdecl calling convention for Windows has nothing to do
with C, despite the name.

in its common form:

Details are irrelevant. And feel free to devote similar efforts to
your grandmother's egg-sucking edification; I've been dealing with the
inner details of various ABIs for a quarter-century.

now, the issue is that not all compilers exactly agree on all the
details, and these subtle differences can at times break code linked
together from different compilers...

No, the issue is that you apparently don't know what is and is not
part of the C language, and that you have a regrettable tendency to
wander off into irrelevant tangents.

 

[Michael Wojcik]

CHAR_BIT==8 is AFAIK more acceptable, since nearly all major/common
hardware at this point (and likely in the near future) has this property.

It's acceptable right up until it isn't. And there are still a number
of major embedded platforms which do not use 8-bit char.

That said, it's often true that an explicit assumption that CHAR_BIT
is 8 is acceptable. The problem is when that assumption isn't
explicit, and the code might be ported to a platform where CHAR_BIT >
8. (The larger problem is the existence of C programmers who don't
know about CHAR_BIT, or how C defines "byte".)

endianess matters if one thinks the code may have a chance of migrating
between different sorts of targets, such as between x86 and PPC.

Since portability is the matter under discussion...

usually
I handle endianness in my own code though.

Glad to hear it - though generally well-written C code should be
endian-neutral, especially when marshalling and unmarshalling data
that may not match the implementation's endianness. (That is, it
should employ shifting and masking using unsigned integer types, which
produces the correct result regardless of platform endianness.)

What you do, or what I do, says nothing about what most C programmers
do, however. And that was my point.

 

[Michael Wojcik]

That those are the top 10 languages in some order is probably
reasonable, if you include the use of Basic in Office macros and other
light programming, and you accept that what is being measured is the
interest in people with those language skills. Java, C, C++, and C# I
don't think anyone would disagree with;

Yes, I'd say those four are probably among the top ten programming
languages, in terms of "interest in people with those language
skills", as you put it. (And I'd agree that's a fair gloss of what
TIOBE think they're measuring.)

Objective-C is basically
programming on Mac

And the iOS platforms - the iPhone and iPad. That's a large and
vigorous market, though we'll see how long it maintains that degree of
interest.

PHP and Ruby are the most significant
web-programming languages (you might also include ASP, but that seems to
be falling out of favor, even by Microsoft). Python and Perl are of
course the premier scripting languages, and Visual Basic is the crown of
crappy macro stuff and programming for idiots.

I suspect the TIOBE rankings underestimate ECMAScript (Javascript and
other implementations) - or more precisely, that the observable
interest in ECMAScript skills is disproportionately low when compared
to the amount of ECMAScript being written. But that's partly because
many people are still under the impression that it's fine to let any
idiot write their ECMAScript scripts.

I had a discussion a few months ago about what a ranking of the
languages as measured by most lines of code (normalized to account for
expressiveness) in use would be. At the very least, Java, C, Fortran,
and COBOL would be near the top of the list; I don't know much more to
give a fuller list...

Of course it's difficult to arrive at any sort of consensus over how
to normalize for expressiveness, and it could even be argued that such
a measure is not as useful as it appears. For example, a tremendous
amount of very important code was written in various assembly
languages; but since such languages have relatively low expressiveness
(even the wildly CISCy ones), and since such programs were often
written for resource-constrained environments, that metric would tend
to rank assembly languages relatively low, even if they were all
grouped into one category.

(There are still extant business-logic applications written in
assembly, by the way. We encounter them sometimes at customer sites,
and in fact demand for our S/390 / zSeries assembly emulation has
increased in the past few years.)

Fortran (nee FORTRAN) and COBOL can claim a great many normalized
lines of source (NSLOCs?) partly because of age, of course; they're
the two oldest HLLs still in widespread use.

Besides the four you mention, I suspect C++ would place high in the
list. Demand for it has gradually diminished somewhat since the '80s
because of the proliferation of other capable, widely-available OO
languages[1], but it's often used for huge projects like office suites
and GUI frameworks, which accumulate features like flies on the
substrate of your choice.


[1] I wouldn't include the OO predecessors of C++ in this category.
SIMULA was never widely available, and Smalltalk has a host of
problems, particularly for commercial software development. (Later
Smalltalk variants, such as Squeak, solved some of those; but too
little, too late.)

 

[Michael Wojcik]

CPU architectures aren't really a major issue anymore.

All the world's a VAX.

Ah, well. More work for those of us who pay attention.

 

[BGB]

Wrong. Those are platform ABIs. They have nothing to do with C, a
language defined by ISO/IEC 9899, and not by implementations thereof
or their dependencies.

they are used for C, and defined in relation to C, and if one uses a
different ABI, their code doesn't work on the given platform...

so, same-difference really...


it is thus mandatory supplementary material.

Neither of which have anything to do with C.


Yes, insofar as there is no C++ ABI (much less "many C++ ABIs").


Microsoft's cdecl calling convention for Windows has nothing to do
with C, despite the name.

cdecl is also used on Linux on x86, and several other OS's (AFAIK
FreeBSD and others), and so is not specific to MS.

MS's own convention, "stdcall", is used far less often...

Details are irrelevant. And feel free to devote similar efforts to
your grandmother's egg-sucking edification; I've been dealing with the
inner details of various ABIs for a quarter-century.

I also write compilers...

the details *are* the thing in question.
a computer is itself details, as are programming languages, and there is
nothing apart from its details.

No, the issue is that you apparently don't know what is and is not
part of the C language, and that you have a regrettable tendency to
wander off into irrelevant tangents.

the pure C standard, by itself, would be effectively useless for getting
much done.

much of its utility is due to all of this other stuff, which FWIW, is
treated as if it were a part of the language, as it exists on the
platforms in question.



the matter then of how it exists on other platforms, well, that is how
it exists there, and one can consider it in the context of those
platforms, if it is within the confines of relevance to do so.

portability as far as applications are concerned can usually be
described as: "does it work on these N systems I care about?".

beyond this: who knows, who cares, it is a matter for another day...

 

[Lawrence D'Oliveiro]

CPU architectures aren't really a major issue anymore.

If that were true, how come ARM is giving Intel a hiding in the smartphone
and tablet space?

Linux, many BSDish operating systems, OS X and Windows all run primarily
on Intel CPUs.

Guess which is the fastest-growing one? The one that also runs on ARM.

 

[Lawrence D'Oliveiro]

[TIOBE’s] long-term data shows Java and C securely holding the top two
spots for the past decade.

With Java on a downward trend.

But as I noted, the TIOBE rankings are suspect. They're based on
things like advertised positions and classes, so they mostly measure
demand or perceived demand in various markets.

Which is a good basis for deciding what skills to brush up on, don’t you
think?

And simplistic interpretations of their data are likely to be
misleading. For example, they rank COBOL at #37, well below, say, Logo
(#24). (Time to brush up on those Logo skills!) But there are a few
billion lines of COBOL application source code still under
maintenance. They're rarely touched (indeed, businesses are
tremendously wary of touching them), because they encode business
rules. But they still exist and the programs compiled from them are
still used. Does that mean COBOL is under-ranked?

The code exists, but there’s less demand for humans to look at that code.
That’s what TIOBE is telling you.

 

[Lawrence D'Oliveiro]

That those are the top 10 languages in some order is probably
reasonable, if you include the use of Basic in Office macros and other
light programming ...

But do you count all the versions of VBA as one language? For example,
macros written for Microsoft Office 2003 do not so easily port to Office
2007 or later.

 

[Lawrence D'Oliveiro]

Using MSVC brings its own share of problems. I remember on the Python
group, if you wanted to build a C/C++ extension for Python, you had to
compile it with the exact same version of MSVC as was used for that
version of Python, otherwise it wouldn’t work.

There's no "C/C++" language. C and C++ are very different languages.[1]

Relevance being?

Requiring the same version of MSVC, for a binary compiled from C code,
indicates improper use of the C runtime by either Python or the
extension.

But that would be true of everything built with MSVC. Are you saying that
MSVC is making “improper use of the C runtime�

Mixing C runtimes is fine as long as you follow the guidelines Microsoft
publishes. In particular, resources allocated by one module shouldn't be
freed by another ...

Since Python itself provides most of the memory management for objects
created by extensions, it’s hard to see how this can be made to work in any
practical sense.

 

[Lawrence D'Oliveiro]

Used properly, autoconf works just fine on Windows - or, at any rate,
as well as it works anywhere. (Like Joshua I am not particularly
impressed with autoconf, though it's not quite as thoroughly
brain-damaged as some of its fellow GNU build tools, such as libtool.)

Can you offer anything that works better?

Once again, the real problem is that systems like autoconf only help
with C code that is written to be portable with the help of
conditional compilation. The vast majority of C code is poorly written
(spend some time on comp.lang.c if you don't understand how or why)
and a good portion of that is unportable assumptions.

That would certainly not be true with the vast majority of Free Software
written in C/C++. Which is the main kind of C/C++ code that I deal with.

 

[Arved Sandstrom]

[TIOBE’s] long-term data shows Java and C securely holding the top two
spots for the past decade.

With Java on a downward trend.

Not at the moment in any serious kind of way. After 2005 or so you'd be
hard-pressed to argue that Java has lost its position, and it certainly
hasn't over the last 12 months by TIOBE data.

Who actually cares where Java was in 2001 or what happened to it in the
first 5 years after that? Arguably Java was found in a lot of
applications at the time precisely because a lot of other languages
sucked pretty hard, but now there are reasonable competitors. Java has
now settled into a solid position that it's unlikely to give up for decades.

By your own admission you don't play in the enterprise space: I can
assure you that in that space Java has a lock.

Which is a good basis for deciding what skills to brush up on, don’t you
think?

[ SNIP ]

I agree. To an extent. The TIOBE rankings don't say anything about
application domains. One's ability to program many problems requires
comprehensive knowledge of the domain, and many domains (finance,
science, engineering etc) have preferred language choices that are
markedly different from what the overall TIOBE rankings indicate.

If you're going to be simply a general-purpose programmer with no
extensive knowledge in specific application domains then you may as well
go with TIOBE. But as soon as your education and experience starts to
position you in a sector then TIOBE is less relevant.

AHS

 

[BGB]

If that were true, how come ARM is giving Intel a hiding in the smartphone
and tablet space?

partly it is because, if one looks back in time a little further:
smartphones and tablets, in their present form, are partly an outgrowth
of earlier cell-phones and PDAs...

these were never really x86 dominated areas to begin with.

previously, m68k and Z80 chips were still holding on strong, before
getting largely displaced by ARM.

now, one can ask how things would be, say, had all of these new
smart-phones popping up, had been using a Z80 variant?...


had smartphones and tablets instead more developed, say, as an outgrowth
of making ever smaller laptops, then likely they would be running x86
instead.

Guess which is the fastest-growing one? The one that also runs on ARM.

actually, all of the above have ARM variants...

Linux and FreeBSD are generally cross-platform OS's, and Linux on ARM is
actually a notable target space (the Linux kernel is also the basis of
both Android and Chrome).

OSX has an ARM variant, namely, iOS, used on the iPhone and iPad.

Windows also has an ARM variant, previously Windows CE, then Windows
Mobile, now Windows Phone 7.



but, still, grr, it is x86, not Intel, that is the focus of the matter.

reasoning:
a fair number of desktop PC's (around 20% AFAICT) actually run non-Intel
CPUs (mostly AMD, with VIA controlling a smaller part of around 0.2%).

x86-64 was actually AMD's creation, and Intel just sort of adopted it
later when they started losing market share vs AMD.

Intel promoted/marketed the Itanium / IA-64 architecture, which failed
as far as the market goes. this means even Intel can't force people to
buy an architecture they don't really want.

AFAIK: VIA has a stronger holding on the market than Intel when it comes
to ultramobile x86 processors, mostly because apparently the VIA Nano
has both better performance and lower watts than the Intel Atom.

the AMD Fusion has better performance than the Atom (and has a GPU), but
is not as good WRT power use.


or such...

 

[BGB]

Can you offer anything that works better?

some people really like CMake.

That would certainly not be true with the vast majority of Free Software
written in C/C++. Which is the main kind of C/C++ code that I deal with.

note that he was apparently also objecting to the use of "conditional
compilation" as a portability strategy (IOW: "lots of #ifdef").

however, "#ifdef" is one of the main portability strategies with most
FOSS, and actually most software in general.

the issue though is that the requirements for making "proper" portable
software (IOW: not using piles of "#ifdef"s) is generally very
awkward/painful, and limits what sorts of things one can do, and doesn't
really buy all that much.

most people, really, probably don't care that much if the software they
are using has a few ifdef's here or there, they just care that it works.


however, if it could work, one could call it "ultraportability" though.
IOW: code that is portable well beyond the usual set of N targets it was
originally designed to work on.

but, for the most part, this isn't really necessary.
usually the code is at least written generically enough that it can be
ported to new targets without too much added pain (usually by adding
more ifdef's and special-case code for the new targets).


or such...

 

[David Lamb]

well, IMO, trying to homogenize the environment is itself a problem...

this is actually part of what I think is a weak-point of the JVM strategy:
they try to gloss over the real OS/... by basically creating a new layer
of abstractions, and wrapping everything in the new API.

Writing portable code usually means giving up on some specific features
of individual OS's ("homogenize" seems to me an uncecessarily pejorative
word for it). I'v written #ifdef code like you've suggested and got
tired of it; even with just keeping them inside header files, eventually
the whole thing became unwieldy. I'm sure that *some* programs need to
be OS-specific, but fewer than some programmers think (not a dig at you
personally; just remembering some other conversations I've heard on
similar subjects).

 

[Lawrence D'Oliveiro]

OSX has an ARM variant, namely, iOS, used on the iPhone and iPad.

Can it run OSX apps?

but, still, grr, it is x86, not Intel, that is the focus of the matter.

In case you hadn’t noticed, smartphone unit shipments are now level-pegging
with x86 PCs, and will probably surpass them in the next quarter or two.

 

[Lawrence D'Oliveiro]

Don't be coy. What's the omission?

MICROSOFT WINDOWS!!!!!!

 

[Lawrence D'Oliveiro]

("the most portable language in the world" is a
vapid claim, since "portable" is not well-defined and there's no
metric for "most".)

Most languages (including Java) that claim to be “portable†seem to be
implemented in C. Therefore they can only be ported to platforms where a C
compiler (or cross-compiler) is already available. Therefore,

Portability(all such languages) ⊆ Portability(C)

or even

Portability(all such languages apart from C) ⊂ Portability(C)

It's rare to find non-trivial C source that
doesn't make assumptions about the implementation: CHAR_BIT,
endianness, character set, etc.

Try this <http://www.blender.org/>. Is a million lines “non-trivial†enough
for you?

 

[BGB]

Can it run OSX apps?

it depends...

AFAIK, the Xcode system produces binaries in the MachO format, which can
generally target multiple architectures at the same time, so it is not
entirely implausible that dual-target (OSX and iOS) binaries could be be
possible to produce (realistically, dunno, depends partly on how Xcode
works, which I have not really investigated, and I don't have a Mac
either...).

however, as-is, plain OSX apps will probably not work on iOS.

also, iOS generally needs to be "jailbreaked" to run custom apps anyways
(IIRC, prior to uploading to AppStore people run/debug their apps in an
emulator...).

In case you hadn’t noticed, smartphone unit shipments are now level-pegging
with x86 PCs, and will probably surpass them in the next quarter or two.

I expect they will probably start leveling off again once nearly
everyone has one, as is usual for these types of things...

but, the point of the above comment was not x86 vs ARM, but rather
peoples' persistent use of "Intel" to describe all x86 chips, which is
not really the case if people are running chips from another manufacturer...

it is much like if one used the term "Windows" to describe every OS,
including Linux and MacOSX, rather than a more generic term, like OS...


but, anyways, I have before devised ideas for how one could JIT x86 code
to ARM... but, whether or not this would be useful or not is less certain.

I also have an x86 interpreter, which is based on using threaded code.

 

[BGB]

Writing portable code usually means giving up on some specific features
of individual OS's ("homogenize" seems to me an uncecessarily pejorative
word for it). I'v written #ifdef code like you've suggested and got
tired of it; even with just keeping them inside header files, eventually
the whole thing became unwieldy. I'm sure that *some* programs need to
be OS-specific, but fewer than some programmers think (not a dig at you
personally; just remembering some other conversations I've heard on
similar subjects).

most of my stuff has been compilers, VMs, and 3D engines...

in each case, most of the platform specific code tends to be centralized
in various places (with lots of "#ifdef's"), with most things being
re-exposed via "generic" APIs.

however, without being able to use advanced/OS-specific functionality
when needed, what is actually possible is greatly limited...


sometimes in the innards of a program, it is necessary to do some very
nasty and non-portable things in order to make the program work, and if
one can't do these things, then the answer is simple: the program wont
work...

but, this doesn't necessarily mean it can't work on multiple targets,
just the "deep magic" has to be addressed for whatever targets are in
question (as a failure to address it may result in a non-functional
program).