What's the best non-JVM native language to look at?

[Saxo]

Hello,

I have only been worked with vm based languages (first Smalltalk, then Java). Now I would like to have a look at a language that is natively compiled.I know this forum is not really the place for native PLs. But it is the place where people best understand my background.

I will probably make my living with Java or maybe some other JVM language for a long time to come. It's only about looking into some native compiled language as a complement and to look at new things. So I have been looking into Go, D, Rust, C, C++. Problem is that after many iterations I have somewhat ended up in disorientation. So I would like to check out what other people think to get some quality check.

I think I will only have a chance to do a bit C at work one time (or C withusing a C++ compiler as a better C compiler. C++ takes years to learn on full-time assignment and I don't think I will have a chance to pick it up well enough, because there are simply too many aspects of the language.

Go is ideal for someone with my background, easy to pick up, no manual memory management, good networking, good concurrency (based on CSP by Hoare as Rust and Occam). But the language itself is really simplistic.

Then there is D which I like quite much as it is really high-level, but also allows for system programming and low-level stuff. But I don't think you will ever get work for it. For sure not in my country.

So what I end up is looking into C using a C++ compiler or looking into Go (to get better understanding of concurrency using channels as different approach). D would be really nice, but I fear it would also be quite effortfulto pick it up nice.

From what I've written so far you might be able to see where the disorientation / confusion originates from ... My mind says I should do some C proramming where there is the best chance to do some work with it at some companyone day. But my heard tells me to do some more fancy stuff like Go or D.

I wonder how people in a similar situation would reason about this.

Thanks so much, Saxo

 

[Saxo]

Thanks for your reply lipska. You surely have a point here. And on all popularity lists C is among the top 3 languages. Somehow I just hated to do plain boring C: "not exciting enough syndrom". I have been spending time here and then for the last months as a matter of fact and your comment helped methrough to see things more objectively. Think I found a way to get plain Cprogramming more exciting: I use Objective-C from which you can easily call C and even C++. So I write my Objective-C code for fun (maybe I get to program Objective-C one day, who knows) and embed some C or C++ code in my Objective-C files. There are numerous articles on the Internet that describe how to get this done. And XCode is a real nice IDE. So that sounds like a plan now ;-).

Cheers, Saxo

 

[Jeff Higgins]

- If you're writing C for Linux or another of the Unices, you may also
want a copy of "UNIX System Programming for System VR4" from O'Reilly.
I've had my copy since the late '90s and its still a very relevant
reference in my library.

The Linux Programming Interface, Michael Kerrisk, No Starch Press.
<http://www.nostarch.com/tlpi>

 

[Silvio]

Hello,

I have only been worked with vm based languages (first Smalltalk, then Java). Now I would like to have a look at a language that is natively compiled. I know this forum is not really the place for native PLs. But it is the place where people best understand my background.

I will probably make my living with Java or maybe some other JVM language for a long time to come. It's only about looking into some native compiled language as a complement and to look at new things. So I have been looking into Go, D, Rust, C, C++. Problem is that after many iterations I have somewhat ended up in disorientation. So I would like to check out what other people think to get some quality check.

I think I will only have a chance to do a bit C at work one time (or C with using a C++ compiler as a better C compiler. C++ takes years to learn on full-time assignment and I don't think I will have a chance to pick it up well enough, because there are simply too many aspects of the language.

Go is ideal for someone with my background, easy to pick up, no manual memory management, good networking, good concurrency (based on CSP by Hoare as Rust and Occam). But the language itself is really simplistic.

Then there is D which I like quite much as it is really high-level, but also allows for system programming and low-level stuff. But I don't think you will ever get work for it. For sure not in my country.

So what I end up is looking into C using a C++ compiler or looking into Go (to get better understanding of concurrency using channels as different approach). D would be really nice, but I fear it would also be quite effortful to pick it up nice.

From what I've written so far you might be able to see where the disorientation / confusion originates from ... My mind says I should do some C proramming where there is the best chance to do some work with it at some company one day. But my heard tells me to do some more fancy stuff like Go or D.

I wonder how people in a similar situation would reason about this.

Thanks so much, Saxo

I would also opt for C since that language is both low level and concise
enough that it allows you to focus on what's really different when you
go native.

Among other paths I walked the C => C++ => Java route but I do not think
that C++ is worth the investment any more if you intend to also live in
the (J)VM world. At the time it was different since it was the way out
of procedural C to OOP. Nowadays there are plenty of OO and otherwise
higher level languages on the VM side of things.

Another couple of languages I am glad I spent a lot of time with is
Prolog, Clean and Miranda (the latter two are in some way predecessors
of Haskell). Not exactly in the same arena but a great way to learn new
concepts.

Pure personal opinion, of course.

Cheers,

Silvio

 

[Jeff Higgins]

OK, I'll raise you one more: "The Practise of Programming" by Kernighan
and Pike.

This book's intended audience is C programmers, but it is also very
relevant for programmers writing C++, and Java and, indeed, is useful for
programmers writing almost any block structured language. It is a
programming style manual that covers sensible naming conventions for
data, functions/methods and objects, program layout and commenting for
good readability and ways of structuring programs for performance and
ease of debugging. Its the book I wish had been available when I was
starting to program professionally and that would have made life much
easier if it had been been read and understood by the designers and
authors of innumerable programs I've had to debug or amend.

No oneupmanship intended.
I had a much later start; Code Complete, Steve McConnell.

 

[Arved Sandstrom]

Hello,

I have only been worked with vm based languages (first Smalltalk, then Java). Now I would like to have a look at a language that is natively compiled. I know this forum is not really the place for native PLs. But it is the place where people best understand my background.

I will probably make my living with Java or maybe some other JVM language for a long time to come. It's only about looking into some native compiled language as a complement and to look at new things. So I have been looking into Go, D, Rust, C, C++. Problem is that after many iterations I have somewhat ended up in disorientation. So I would like to check out what other people think to get some quality check.

I think I will only have a chance to do a bit C at work one time (or C with using a C++ compiler as a better C compiler. C++ takes years to learn on full-time assignment and I don't think I will have a chance to pick it up well enough, because there are simply too many aspects of the language.

Go is ideal for someone with my background, easy to pick up, no manual memory management, good networking, good concurrency (based on CSP by Hoare as Rust and Occam). But the language itself is really simplistic.

Then there is D which I like quite much as it is really high-level, but also allows for system programming and low-level stuff. But I don't think you will ever get work for it. For sure not in my country.

So what I end up is looking into C using a C++ compiler or looking into Go (to get better understanding of concurrency using channels as different approach). D would be really nice, but I fear it would also be quite effortful to pick it up nice.

From what I've written so far you might be able to see where the disorientation / confusion originates from ... My mind says I should do some C proramming where there is the best chance to do some work with it at some company one day. But my heard tells me to do some more fancy stuff like Go or D.

I wonder how people in a similar situation would reason about this.

Thanks so much, Saxo

If you do not know C, seriously learn it. It's not like it's perfect,
but it's one of the original foundational languages. I wouldn't like
devote hundreds of hours of study to it, but get a solid handle on it.

C++ takes years to learn, period. People who know it well enough to use
it safely are people who could be on C++ specifications committees, or
already are. I'm not saying C++ is bad, per se, but unless you have a
great deal of time, I wouldn't go down this road.

Not actually sure why "natively compiled" is important to you.

AHS

 

[Roedy Green]

Now I would like to have a look at a language that is natively compiled.=

Pretty well any language can be natively compiled. Java is natively
compiled with Jet. See http://mindprod.com/jgloss/jet.html
The code is astounding, better that I could generate in ASM by hand.
It takes factors into consideration almost no assembler programmer
would have the patience to track.

 

[Saxo]

And I thought I would get some answer like "why are you posting this to comp.lang.java.programmer, you moron?". Now I got plenty of useful replies ..

"As lipska says, forget IDEs - use your favourite editor and run 'make'
from the command line or from the editor if it offers that facility. "

This will get me a hard time as I'm used very much to IDEs. JetBrains announced they are working on an IDE for C/C++. That would be something I would usually opt for. But I'll try ;-). I like C with XCode on Mac, because Apple's C compiler has support for closures (yeah, I'm a spoiled child that can't live without all the comfort...).

"Among other paths I walked the C => C++ => Java route but I do not think
that C++ is worth the investment any more if you intend to also live in
the (J)VM world"

Without several years of development experience in C++ you simply won't geta C++ job. So, I think C makes sense as a complement to Java or Objective-C.

"Another couple of languages I am glad I spent a lot of time with is
Prolog, Clean and Miranda (the latter two are in some way predecessors
of Haskell)."

I started with Scala some weeks ago. I don't really like it, because it is a bit overloaded with too many features for my taste. But Scala + Akka is very strong on concurrency + multi-threading and this is what I like to do and where I already gained some experience. But it is another JVM language and I wanted to have a look into systems programming.

"C++ takes years to learn, period. People who know it well enough to use
it safely are people who could be on C++ specifications committees, or
already are. I'm not saying C++ is bad, per se, but unless you have a
great deal of time, I wouldn't go down this road."

I developed my thesis work in C++ and that was about 15 years ago or something. Yeah, C++ is too effortful. You can't learn it in your spare time. Maybe I do basically C, but make use of some features of C++ to make C development easier. I'm thinking of an approach of writing C in a style like in Go.. With the use of a C++ compiler that should be possible.

Thanks for all the book hints. I have "Practical C Programming" by Steve Oualline already. Thinking of buying "Understanding and Using C Pointers" from O'Reilly somewhen later, because pointers is something where I need to learn a lot (especially with regard to C). But I'll have a look at all the other books mentioned as well.

Regards, Oliver

 

[Jeff Higgins]

Thanks for all the book hints. I have "Practical C Programming" by Steve Oualline already. Thinking of buying "Understanding and Using C Pointers" from O'Reilly somewhen later, because pointers is something where I need to learn a lot (especially with regard to C). But I'll have a look at all the other books mentioned as well.

A recent post to c.l.c <[email protected]>
reminds me of a resource that I have found helpful.
Steve Summit C Programming
<http://www.eskimo.com/~scs/>

 

[Jeff Higgins]

A recent post to c.l.c <[email protected]>
reminds me of a resource that I have found helpful.
Steve Summit C Programming
<http://www.eskimo.com/~scs/>

Excellent introductory text; C Programming: A Modern Approach, K.N.
King, W.W. Norton & Co.

 

[Joshua Cranmer ðŸ§]

I can't think of a language that isn't ultimately implemented in C.

Zero-cost exception handling cannot be expressed in (ISO) C code (or, at
the very least, not in a way that a C compiler will faithfully compile
it--in the situation that would arise, clang and gcc are both extremely
happy to mangle the code, even at -O0). Well, MSVC has __try/__catch,
but that's not ISO C.

If you think about it, any language *other* than C is simply a high(er)
level interface to C (ignoring assembler of course). Even C compilers
are written in C (go figure

Clang is written in C++. GCC is written in C++ as of 4.8. MSVC is
written in C++. I'm pretty sure icc is also written in C++. Open64
appears to be in C++ as well. Which means that all the C compilers which
find major use are written in C++, not C.

Unless there is a revolution in the development of software development
languages I can't see C becoming obsolete any time soon. If you spend
time with C it will help you with almost any other language you can
think of. It's a no-brainer AFAICS. Use Java to earn good money, learn C
as an essential addition to your skill set.

I have reached the point where I find C unusable as a programming
language. While it lets you bury yourself in details and change things
to your hearts content, it also requires that you bury yourself in
details--you can't convert C code into partially-managed memory like you
can in C++ with std::shared_ptr or std::unique_ptr. Also, C lacks a
usable standard library (no hash maps, no auto-growing arrays). And I
can go on and on.

 

[Joshua Cranmer ðŸ§]

I've been reading up on this Zero-cost exception handling thing.
It seems that while there may be no overhead for exception handlers if
no exception is raised, the performance of exception propagation is
poor. Maybe it should be called 'Zero-cost exception handling if no
exception occurs'. It's not impossible though is it, it's a compiler
thing so it *could* be implemented ... if the compiler supported it.
It's not a fundamental shortcoming of the language per-se is it?

Zero-cost exception handling simply cannot be expressed in ISO C code.
In essence, it requires building external unwind tables, which can be
thought of as "if an exception reaches between these two points, jump to
that location instead"--which requires some notion of computed goto
(more specifically, the ability to take the address of a label). gcc's
computed goto extension is not formally specified, but experimentation
with both clang and gcc indicate that taking the address of a label and
not jumping to it [in the same function] is insufficient to preserve the
existence of the code after that block, even when compiling at -O0.

In general, C strongly believes that there exists only a single entry
point to every function; constructs where this notion doesn't really
hold true (exceptions, generators, coroutines, continuations) can't be
effectively expressed in C code.

According to lots of references on the intertubes the first C++ compiler
was written in something called 'C with classes' which was written in ... C

The assertion I was disagreeing with was "C compilers are written in
C"--the major C compilers are in fact written in C++. That C++ was once
bootstrapped by a compiler written in C doesn't particularly
matter--Java was probably bootstrapped by a C++ compiler and Rust was
bootstrapped by OCaml. I suspect OCaml, Haskell, and Scheme are likely
to be more popular languages than C for bootstrapping, largely because
PL people are the ones who like to design new languages, and they prefer
the more powerful constructs in those languages for design than C.

I'm sure you can but implementing simple dynamic data structures (Linked
List for example) in C is trivial isn't it ... I've never really been
attracted to C++, don't know why TBHWY, I have a couple of books. Too
busy earning a crust I suppose.

But I shouldn't *have* to reimplement simple dynamic data structures.
Compare the simple task of reading in a text file in different
languages. In Python, I can write this:

with open('file.txt') as fd:
words = [line.split(' ') for line in fd]

In Java:
List<String[]> words = new ArrayList<>();
BufferedReader reader = new BufferedReader(new FileReader("file.txt"));
String line;
while ((line = reader.readLine()) != null)
words.add(line.split(' ');

In C++ [after looking up a split on stack overflow]:
std::ifstream file("file.txt");
std::vector<std::vector<std::string>> words;
while (true) {
std::string line;
std::getline(file, line);
if (file.eof()) break;
words.push_back(split(line));
}
[It's worth noting that the C++ committee is considering adding split to
the standard library].

In C... I'm not even going to attempt it. C++'s split was 10 lines of
code. C's split is a good 50 lines of code. I'd have to come up with a
representation for an ArrayList or LinkedList-equivalent datatype in C,
make sure it works, write unbounded file parsing, double-check I'm not
leaking memory, etc., just to read in a bloody file. And that's why C is
unusable for me: I spend my time trying to debug my implementation
instead of debugging my algorithm.

 

[Arne Vajhøj]

In C... I'm not even going to attempt it.

Its quite simple. Use getline() and strtok() [since POSIX 2008].

Strictly speaking that that is not C but C on POSIX platform.

Arne

 

[Arne Vajhøj]

Way back when C++ was the new kid on the block I remember reading that
the first C++ compilker was actually a standard C compiler with the Cfront
preprocessor substituted for the usual cpre preprocessor.

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

Arne

 

[Arved Sandstrom]

I've been reading up on this Zero-cost exception handling thing.
It seems that while there may be no overhead for exception handlers if
no exception is raised, the performance of exception propagation is
poor. Maybe it should be called 'Zero-cost exception handling if no
exception occurs'. It's not impossible though is it, it's a compiler
thing so it *could* be implemented ... if the compiler supported it.
It's not a fundamental shortcoming of the language per-se is it?

Zero-cost exception handling simply cannot be expressed in ISO C code.
In essence, it requires building external unwind tables, which can be
thought of as "if an exception reaches between these two points, jump to
that location instead"--which requires some notion of computed goto
(more specifically, the ability to take the address of a label). gcc's
computed goto extension is not formally specified, but experimentation
with both clang and gcc indicate that taking the address of a label and
not jumping to it [in the same function] is insufficient to preserve the
existence of the code after that block, even when compiling at -O0.

In general, C strongly believes that there exists only a single entry
point to every function; constructs where this notion doesn't really
hold true (exceptions, generators, coroutines, continuations) can't be
effectively expressed in C code.

[SNIP]

With all due respect, Joshua. Let's not get *too* deep here. I get
that you're a computer scientist, but at this point I think we are
totally not helping with answering the original question.

I've been a programmer since the '70's. I'd like to think I am even good
at it. Most people think I am. I even understood assembler for IBM
and DEC chips way back when, knew machine code for a few chips, and
learned microcode even. But the thing with you CS guys - all due respect
- is that you get too theoretical when it's not needed.

Most of us professionals - I hope most of us - sorta know things like
certain constructs can't be easily implemented in C. The operative word
being "easily", and another being C is "low-level".

I don't think we're helping the OP here by mentioning external unwind
tables.

AHS

 

[Arne Vajhøj]

On Fri, 17 Jan 2014 15:44:32 -0600, Joshua Cranmer 🧠wrote:

In C... I'm not even going to attempt it.

Its quite simple. Use getline() and strtok() [since POSIX 2008].

Strictly speaking that that is not C but C on POSIX platform.

I used the getline() standardisation detail for strtok() as well, which
was a mistake.


My man pages actually say
- strtok() was defined for SVr4, POSIX.1-2001, 4.3BSD, C89, C99
- getline() was defined for POSIX.1-2008
- fgets() was defined for C89, C99, POSIX.1-2001

There's a possibility that the manpage might be incorrect about getline()
standardisation because both getline() and strtok() are described in
K&R second edition (1988) though only strtok() and fgets() appear in
Appendix B: The Standard Library.

However, my point still stands provided you replace getline() with
fgets().

strtok is standard.

(I do not like the API design, but ....)

And as you say then getline can be replaced by fgets.

I was just emphasizing the POSIX vs C difference.

Arne

 

[Arne Vajhøj]

I have only been worked with vm based languages (first Smalltalk,
then Java). Now I would like to have a look at a language that is
natively compiled. I know this forum is not really the place for
native PLs. But it is the place where people best understand my
background.

I will probably make my living with Java or maybe some other JVM
language for a long time to come. It's only about looking into some
native compiled language as a complement and to look at new things.
So I have been looking into Go, D, Rust, C, C++. Problem is that
after many iterations I have somewhat ended up in disorientation. So
I would like to check out what other people think to get some quality
check.

I think I will only have a chance to do a bit C at work one time (or
C with using a C++ compiler as a better C compiler. C++ takes years
to learn on full-time assignment and I don't think I will have a
chance to pick it up well enough, because there are simply too many
aspects of the language.

Go is ideal for someone with my background, easy to pick up, no
manual memory management, good networking, good concurrency (based on
CSP by Hoare as Rust and Occam). But the language itself is really
simplistic.

Then there is D which I like quite much as it is really high-level,
but also allows for system programming and low-level stuff. But I
don't think you will ever get work for it. For sure not in my
country.

So what I end up is looking into C using a C++ compiler or looking
into Go (to get better understanding of concurrency using channels as
different approach). D would be really nice, but I fear it would also
be quite effortful to pick it up nice.

From what I've written so far you might be able to see where the
disorientation / confusion originates from ... My mind says I should
do some C proramming where there is the best chance to do some work
with it at some company one day. But my heard tells me to do some
more fancy stuff like Go or D.

I think (an many of the previous posts) that you should go with C.

You already know a high level platform independent language in
Java.

If you look for a language that can be used for what Java is
not suited for like low level high platform dependent code, then
C is perfect.

So I would say that C supplement Java nicely.

The other alternative I can think of is C# with the intention
to do Windows desktop apps.

Arne

 

[Arne Vajhøj]

Zero-cost exception handling cannot be expressed in (ISO) C code (or, at
the very least, not in a way that a C compiler will faithfully compile
it--in the situation that would arise, clang and gcc are both extremely
happy to mangle the code, even at -O0). Well, MSVC has __try/__catch,
but that's not ISO C.


Clang is written in C++. GCC is written in C++ as of 4.8. MSVC is
written in C++. I'm pretty sure icc is also written in C++. Open64
appears to be in C++ as well. Which means that all the C compilers which
find major use are written in C++, not C.

And they would probably benefit from being written in something easier
like Java.

I have reached the point where I find C unusable as a programming
language. While it lets you bury yourself in details and change things
to your hearts content, it also requires that you bury yourself in
details--you can't convert C code into partially-managed memory like you
can in C++ with std::shared_ptr or std::unique_ptr. Also, C lacks a
usable standard library (no hash maps, no auto-growing arrays). And I
can go on and on.

But if you really need those high level features wouldn't there be
even better alternatives to C than C++?

To me:
need for high level powerful language => Java or a step further Scala
need for low level (rare but happens) => C is good

Well - I guess there is one more:
need for high level language integratable with legacy C => C++

Arne

 

[Arne Vajhøj]

This could well be a dead-end language unless Windows 9 is stunning
enough to undo the damage caused by Vista and Windows 8.

Windows is still on something like 90% of all PC's - not very
likely to go away.

IMO this would also including providing the same unified API for all
flavours of Windows 9, i.e. desktop, server, phone and tablet) so that an
application program written for any of them will compile and run on the
other others without needing any source code changes or conditional
compilation features. I did and still do find it unbelievable that MS
could have made such an obvious mistake as using different sets of APIs
the three W8 flavours.

????

Isn't that exactly what MS did with WinRT?

OK - they did not achieve full functional parity on all
platforms in 8, but they have promised to improve that in 9.

But I am not sure that it matters so much. Any attempt to use
the same UI on a phone and a PC will fail miserable.

Arne

 

[Arne Vajhøj]

Isn't that exactly what MS did with WinRT?

Thats what they *said* they did, but apparently what they said and what
they did are not the same.

Its not impossible: its only a matter of providing the same[*] API in an
ARM box as is already implemented in an X86 box. Proof that this is quite
possible is given by the seamless port of Debian Linux and the GNU C
compiler toolset to the RaspberryPi (ARM) from the PC (X86). I know,
because I've done it with both my own and some 3rd party packages, that
you can use cvs to checkout a set of sources and makefiles from a PC
running Linux to an RPi running Raspbian (the Debian port) and compile it
without changing anything that was checked out. If the tiny Raspberry Pi
Foundation can make this work, than Microsoft certainly should be able to
do the same.

[*] 'same' as in functionally identical interfaces after compiling them
on any of the target hardware.

But I am not sure that it matters so much. Any attempt to use the same
UI on a phone and a PC will fail miserable.

Why do you say that? There's absolutely no excuse for file system APIs to
differ

????

Isn't that what Windows.Storage.Streams.FileInputStream,
Windows.Storage.Streams.FileOutputStream and the rest provide?

If your OS exposes a set of, say, APIs to manage a graphical
display, that should work on all hardware regardless of whether the code
implementing the system side of the API is the same on all hardware or
not. In fact I'd expect the system code to differ in order to do
something sensible with the different screen sizes, pixel size and colour
palettes supported by target hardware and to hide differences between a
single-touch screen and a mouse. Again, this is nothing new. the X system
works perfectly well on the RPi and can easily handle different screen
sizes and resolutions. I can easily run code written for a WinCE-based PNA
on a Windows box after its been recompiled. Actually its running on a
remote Linux box under Wine and using my Linux laptop's display: the
window it presents on the laptop is a lot bigger than the PNA's screen,
but it has the same aspect ratio and much better resolution and, given
that mouse clicks and drags and a keyboard are used instead of the single
touch PNA screen with a graphical keyboard, inputs works exactly the
same too.

????

The menus of a modern PC app is useless on a phone.

That is not something I am making up.

Try comparing how web browsers look on PC and phone.

Arne