Nick Keighley said:
I've used both makefiles and IDEs. IDEs tend to encourage simpler
project layouts and I confess the more esoteric makefiles I find hard
work.
You can use Visual Studio with C as well...
yep.
for Makefiles, I tend to use a lot of copy/paste/edit.
namely, I found a structure which works fairly well, and copy and edit it to
deal with the specifics of the new piece of code.
VS works, but more in the "quickly beat together something small and simple
with a GUI" sense...
sometimes I end up combining some of VS's tools with an otherwise
command-line build, ...
however, most of the stuff I build tends to be largish, and VS doesn't seem
particularly well suited to managing and building larger projects (could
work, but likely to involve manually hacking some stuff).
they're partly understandable. They wouldn't be using a particular
tool if it didn't suit them at some level better than the alternatives
(though sometimes the reason is just inertia). I tend to just ignore
the more zealous.
yep.
I don't care what they use...
I'm sure there must be something better than Notepad... Have you
looked at ConText? Easy to use but with a few features like syntax
highlighting (I can hardly ever stand the default settings) and
indenting.
I am using Notepad2 some now, but a lot of these arguments took place before
using it, and the difference is not all that drastic...
it is like, ones' task is to edit text.
since most usable text editors do similar stuff and have similar UI's, there
is no real strong difference between them IME...
nothing is the solution to everything
yep.
I'm not sure this is even doable. The variation in environments is so
vast. I'm not sure I want .NET in my anti-lock brakes.
Some manufactureere have acheived good levels of integration (DEC VMS
you could mix components from various languages fairly freely) (maybe
Apple too). But of course this all fell apart when you changed
platforms.
yeah, that is another problem...
a lot of my effort has ended up going into designing and implementing
typesystem and ABI mechanics...
I have an ABI, which is partly combines parts of other ABIs (notably the
IA64 C++ ABI / GCC C++ ABI, JVM, and parts of MSIL).
part of the trick is getting all of these languages to use compatible ABI's
and typesystems, which MS was partly right about this part (trying to
crazy-glue all of the different systems together gets nastier faster).
however, each language can still have its own specific typesystem and
semantics, as it is not so much that "language A has the same types and
semantics as language B", but rather that commonality can be reached at the
ABI level.
like most C++ ABI's, mine directly builds upon the C ABI.
sadly, at the moment, direct C++ compatibility is unlikely (C++ needs to
interface at the C level).
I ended up not directly using the existing C++'s as they didn't match
exactly with my uses (however, the IA64 / GCC C++ ABI has contributed
notably to much of the core type notations, ...). however, a lot of other
syntax conventions came from the JVM, and some minor features came from MSIL
(mostly adding the ability to encode things like calling-convention and
access modifiers into signature strings, ...).
also things like generics can be represented, however the notation can't
currently handle C99 VLAs (VLAs pose technical problems at several levels,
and are thus far unimplemented). a likely eventual strategy could be to
silently convert it into a dynamic array.
int arr[x];
silently becomes (analogous to):
int[] arr = new int[x];
however, a few things create issues at the ABI level:
good GC mechanics (currently I have conservative GC, and there is no obvious
way around this for now);
lexical closures (currently these are a hack involving allocating GC'ed
executable memory objects);
full continuations (there is no good way I know of to pull this off without
making a horrid mess).
exist only continuations are possible, but some languages (such as Scheme)
expect full continuations.
the issue is that there is no good way to support these (at least for
mixed-language stack frames).
currently I don't officially support Scheme, but a half-assed form exists as
it was used as the basis of the IL for my BS language (partial ECMAScript
variant).
and even simpler things:
reliable stack unwinding (mixed-language stacks and using optimizing
compilers tends to foul up stack unwinding, since some compilers consider it
a good idea to omit frame pointers, ...);
inter-language base-type naming issues (names of base types in one language
may be different than in other languages);
inter-language dynamic-type naming issues (some languages, such as
ECMAScript and friends, happen to specify the names of various dynamic
types, which don't match what my stuff uses internally, hence requiring
rename hacks...);
....
for example:
_fixint_t, _flonum_t, _int_t, _float_t, _long_t, _double_t, ... all map to
the ES/JS "number" type.
(an underscore prefix is generally used for all types which are part of the
framework itself).
given JS supports:
if(typeof(x)=="number")
...
no clean solutions exist.
sadly it is not at present...
given I can't portably compile Java or C# directly to native code, use a
wide variety of non-"JVM" languages on the JVM (like C and C++).
C# is also tied to .NET, with no real direct native options (although on
Windows the difference between .NET and native is minor, but apart from
Windows, the border is not so clean...).
for example, the main convinient way I had found for using .NET with a C
codebase was to have a DMZ of C++/CLI, so both C# and C can interface with
this DMZ, and thus with each other.
however, AFAICT, this strategy does not work with Mono or others (one has to
resort to the decidedly less clean P/Invoke strategy, although at least it
is still probably less awkward than JNI...).
compiling C# to native code which could work on both Windows and Linux and
interface more directly with C would be preferable.
however, I am unlikely to ever really fully support C++, so if I were to do
a C++/CLI analogue, it would likely be a sort of faux-C++ (and likely
technically closer to a hybrid of C and C# than a true C++...).
on my framework, most non-C facilities can be accessed via API calls, but
this of course lessens the ideal of framework independence (where, ideally,
my stuff should not even entirely depend on my own stuff, although
practically this is unavoidable).
I'm not convinced that what you want is actually possible.
it may not be.
I was writing about an ideal world, rather than a realistic world.
however, there is still more that can be done...
apart from whether any such ideals can be realized, costs, benefits, and
tradeoffs still exist (within the current world), and no particular choice
is universally better than the others.
one person chooses C (and native), another C# (via .NET), and another Java
(via JVM).
each with their own merits and costs...
I'm not convinced that language interoperability needs VMs
part is how one defines a VM...
but, at least in the more traditional sense (JVM, .NET, or things like the
Flash or Python VM), no, probably not...
interoperability itself needs common ABI's...
sadly, a language like Java or C# (or JavaScript) needs a good deal of
runtime support to actually work...
in this case, a "VM" may exist, but more as a big set of runtime facilities
and possibly codegen machinery, rather than a bytecode-based interpreter or
JIT engine.
my strategy is more in trying to provide most of the facilities, and thus
far I have *no* standardized bytecode (most of the code is statically
compiled native code, or is compiled at runtime typically from source-code
or generating code at runtime).
most of the overall structure is similar to that found in a more traditional
compiler (such as GCC).
I tried to keep the design much more orthodox than in LLVM and friends (some
people push for me to use LLVM, but as is it would still be fairly painful
to try to plug it into my framework...).
hence, I am still left writing my own compiler machinery.
where I come from electrical plugs have three prongs
depends on the plug...
either way, it is still an arbitrary decree...
here in the US, there are usually 2 flat blade prongs (at 110-120VAC and
60Hz), and sometimes an optional 3rd prong used for grounding (mostly on
computers and similar). then there are the much larger 3-blade plugs
(240VAC), usually used for dryers, stoves, welders, and similar...
many other places it is 2 or 3 round prongs, usually at 240VAC and 50Hz
AFAIK and with a wider prong spacing.
then one can switch between them via transformer boxes...
sometimes it would be convinient if there were 12VAC power available in
houses, say then using rectifiers in the power boxes to have 12VDC
available.
or such...
