Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #27317 > unrolled thread

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

Back to article view | Back to comp.lang.java.programmer

Contents

  What's the best non-JVM native language to look at? Saxo <jeti789@web.de> - 2014-01-16 04:35 -0800
    Re: What's the best non-JVM native language to look at? lipska the kat <lipskathekat@example.com> - 2014-01-16 13:05 +0000
      Re: What's the best non-JVM native language to look at? Saxo <jeti789@web.de> - 2014-01-16 07:05 -0800
        Re: What's the best non-JVM native language to look at? lipska the kat <lipskathekat@example.com> - 2014-01-16 16:11 +0000
      Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-16 20:39 +0000
        Re: What's the best non-JVM native language to look at? Jeff Higgins <jeff@invalid.invalid> - 2014-01-16 16:18 -0500
          Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-16 21:50 +0000
            Re: What's the best non-JVM native language to look at? Jeff Higgins <jeff@invalid.invalid> - 2014-01-16 17:27 -0500
      Re: What's the best non-JVM native language to look at? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-01-17 10:28 -0600
        Re: What's the best non-JVM native language to look at? lipska the kat <lipskathekat@example.com> - 2014-01-17 18:08 +0000
          Re: What's the best non-JVM native language to look at? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-01-17 15:44 -0600
            Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-18 02:09 +0000
              Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-17 22:15 -0500
                Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-18 17:21 +0000
                  Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-18 12:41 -0500
                    Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-18 19:46 +0000
            Re: What's the best non-JVM native language to look at? Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-18 03:56 -0400
              Re: What's the best non-JVM native language to look at? lipska the kat <lipskathekat@example.com> - 2014-01-18 08:58 +0000
          Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-18 02:02 +0000
            Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-17 22:17 -0500
              Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-18 17:36 +0000
            Re: What's the best non-JVM native language to look at? Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-28 10:13 -0400
              Re: What's the best non-JVM native language to look at? lipska the kat <lipskathekat@example.com> - 2014-01-28 16:21 +0000
                Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-28 22:09 +0000
        Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-18 20:02 -0500
    Re: What's the best non-JVM native language to look at? leif.roar@invalid.com (Leif Roar Moldskred) - 2014-01-16 11:30 -0600
    Re: What's the best non-JVM native language to look at? Silvio <silvio@internet.com> - 2014-01-16 23:27 +0100
    Re: What's the best non-JVM native language to look at? Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-17 01:08 -0400
    Re: What's the best non-JVM native language to look at? Roedy Green <see_website@mindprod.com.invalid> - 2014-01-17 01:43 -0800
    Re: What's the best non-JVM native language to look at? Saxo <jeti789@web.de> - 2014-01-17 01:53 -0800
      Re: What's the best non-JVM native language to look at? Jeff Higgins <jeff@invalid.invalid> - 2014-01-17 11:03 -0500
        Re: What's the best non-JVM native language to look at? Jeff Higgins <jeff@invalid.invalid> - 2014-01-17 11:27 -0500
    Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-18 19:49 -0500
      Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-19 12:35 +0000
        Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-19 17:05 -0500
          Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-19 23:44 +0000
            Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-19 19:45 -0500
              Re: What's the best non-JVM native language to look at? Jeff Higgins <jeff@invalid.invalid> - 2014-01-19 19:55 -0500
                Re: What's the best non-JVM native language to look at? Jeff Higgins <jeff@invalid.invalid> - 2014-01-19 20:04 -0500
                  Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-20 15:38 -0500
                    Re: What's the best non-JVM native language to look at? Jeff Higgins <jeff@invalid.invalid> - 2014-01-20 18:30 -0500
                      Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-20 19:43 -0500
                        Re: What's the best non-JVM native language to look at? Jeff Higgins <jeff@invalid.invalid> - 2014-01-20 20:16 -0500
                          Re: What's the best non-JVM native language to look at? Jeff Higgins <jeff@invalid.invalid> - 2014-01-20 20:30 -0500
                          Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-20 20:43 -0500
                            Re: What's the best non-JVM native language to look at? Jeff Higgins <jeff@invalid.invalid> - 2014-01-21 00:55 -0500
                Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-20 21:41 +0000
                  Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-20 17:10 -0500
                    Re: What's the best non-JVM native language to look at? lipska the kat <lipskathekat@example.com> - 2014-01-21 08:59 +0000
                    Re: What's the best non-JVM native language to look at? leif.roar@invalid.com (Leif Roar Moldskred) - 2014-01-21 04:03 -0600
                      Re: What's the best non-JVM native language to look at? lipska the kat <lipskathekat@example.com> - 2014-01-21 11:53 +0000
                        Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-21 22:09 +0000
                    Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-21 22:05 +0000
              Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-20 21:39 +0000
                Re: What's the best non-JVM native language to look at? Arne Vajhøj <arne@vajhoej.dk> - 2014-01-20 17:21 -0500
                  Re: What's the best non-JVM native language to look at? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-21 22:17 +0000
    Re: What's the best non-JVM native language to look at? Jeff Higgins <jeff@invalid.invalid> - 2014-01-19 22:34 -0500

Page 1 of 3  [1] 2 3  Next page →

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

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

[toc] | [next] | [standalone]

#27318

On 16/01/14 12:35, Saxo wrote:
> 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

The way I see it is ...

I can't think of a language that isn't ultimately implemented in 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 :-)

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.

That's what I did (do) and I wouldn't change a thing given my time again.


-- 
Lipska the Kat©: Troll hunter, sandbox destroyer,
treacherous feline and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#27319

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 me through to see things more objectively. Think I found a way to get plain C programming 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

[toc] | [prev] | [next] | [standalone]

#27320

On 16/01/14 15:05, Saxo wrote:
> 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 me through to see things more objectively. Think I found a way to get plain C programming 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
>

Well I wouldn't call it 'plain boring C' but YMMV :-)
I have never used an IDE for anything 'C type'
I prefer gedit (or emacs if I feel masochistic), make and a terminal 
window. Having said that I don't think I've ever written anything other 
than the most trivial Java *outside* of an IDE as I just can't be 
bothered with all that classpath nonsense, so, I guess it depends on 
your preferences.

Whatever you do for $DEITY's sake *enjoy* it. It's supposed to be *fun*.
There are so many uptight, pompous, self obsessed egomaniacs in this 
business that you have to maintain a sense of reality. It *really 
really* isn't that important.

As they say, 'if it feels good, do it'

Good luck

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer,
treacherous feline and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#27323

On Thu, 16 Jan 2014 13:05:31 +0000, lipska the kat wrote:

> I can't think of a language that isn't ultimately implemented in 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 :-)
>
I agree with Lipska. As ultimately all languages using curly brackets are 
derived from C, its a good idea to know it.

As for C learning tools: 

- If you haven't already, get a copy of "The C Programing Language" by
  Kernighan and Richie. Get e3dition 2 or later because these describe
  ANSI C rather than the earlier K&R language version. 

  IMO this is one of the best language teaching books that I've seen and
  its a useful reference after that.

- Use the GNU C compiler and make for compilation and learn to use make
  as soon as you start to write C programs to include more than single
  source and header files. 
  
  This is the standard compiler for Linux and is also available for
  Windows, either as the stand-alone djgpp compilation system or as part 
  of the mingw or cygwin packages.

- The GNU compiler compiles both ANSI C and C++. Not that I advocate
  using C++. As you said, its quite complex and in any case I seen more 
  so-called C++ which is really just ANSI C with C++ comments (using the
  // delimiter than I've seen with actual objects etc.

- 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.
  The only reason to change editors is if your usual one insists on 8
  character tabs: the usual C standard is to use 3 or 4 character tabs.

- 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. 

> That's what I did (do) and I wouldn't change a thing given my time
> again.
>
Same here.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#27324

On 01/16/2014 03:39 PM, Martin Gregorie wrote:

> - 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>

[toc] | [prev] | [next] | [standalone]

#27325

On Thu, 16 Jan 2014 16:18:08 -0500, Jeff Higgins wrote:

> On 01/16/2014 03:39 PM, Martin Gregorie wrote:
> 
>> - 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>

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.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#27327

On 01/16/2014 04:50 PM, Martin Gregorie wrote:
> On Thu, 16 Jan 2014 16:18:08 -0500, Jeff Higgins wrote:
>
>> On 01/16/2014 03:39 PM, Martin Gregorie wrote:
>>
>>> - 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>
>
> 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.

[toc] | [prev] | [next] | [standalone]

#27333

On 1/16/2014 7:05 AM, lipska the kat wrote:
> 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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#27335

On 17/01/14 16:28, Joshua Cranmer 🐧 wrote:
> On 1/16/2014 7:05 AM, lipska the kat wrote:
>> 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.

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?

>> 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.

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

>> 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.

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.


-- 
Lipska the Kat©: Troll hunter, sandbox destroyer,
treacherous feline and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#27336

On 1/17/2014 12:08 PM, lipska the kat wrote:
> On 17/01/14 16:28, Joshua Cranmer 🐧 wrote:
>> On 1/16/2014 7:05 AM, lipska the kat wrote:
>>> 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.
>
> 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.

>>> 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.
>
> 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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#27338

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].


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#27339

On 1/17/2014 9:09 PM, Martin Gregorie wrote:
> 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.

Arne

[toc] | [prev] | [next] | [standalone]

#27343

On Fri, 17 Jan 2014 22:15:43 -0500, Arne Vajhøj wrote:

> On 1/17/2014 9:09 PM, Martin Gregorie wrote:
>> 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().


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#27345

On 1/18/2014 12:21 PM, Martin Gregorie wrote:
> On Fri, 17 Jan 2014 22:15:43 -0500, Arne Vajhøj wrote:
>
>> On 1/17/2014 9:09 PM, Martin Gregorie wrote:
>>> 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

[toc] | [prev] | [next] | [standalone]

#27346

On Sat, 18 Jan 2014 12:41:07 -0500, Arne Vajhøj wrote:

> strtok is standard.
> 
> (I do not like the API design, but ....)
>
Nor do I.
 
> And as you say then getline can be replaced by fgets.
> 
> I was just emphasizing the POSIX vs C difference.
> 
Yep, and I was just showing that 50 lines of C to split a line into words 
is rather a large overestimate. 10-12 is more realistic.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#27341

On 01/17/2014 05:44 PM, Joshua Cranmer 🐧 wrote:
> On 1/17/2014 12:08 PM, lipska the kat wrote:
>> On 17/01/14 16:28, Joshua Cranmer 🐧 wrote:
>>> On 1/16/2014 7:05 AM, lipska the kat wrote:
>>>> 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.
>>
>> 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
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#27342

On 18/01/14 07:56, Arved Sandstrom wrote:
> On 01/17/2014 05:44 PM, Joshua Cranmer 🐧 wrote:
>> On 1/17/2014 12:08 PM, lipska the kat wrote:
>>> On 17/01/14 16:28, Joshua Cranmer 🐧 wrote:
>>>> On 1/16/2014 7:05 AM, lipska the kat wrote:
>>>>> 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.
>>>
>>> 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. :-)

Well possibly but it's slightly more interesting than some obscure 
discussion on Nordic umlauts or whatever that we recently had to endure 
in this group :-)


-- 
Lipska the Kat©: Troll hunter, sandbox destroyer,
treacherous feline and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#27337

On Fri, 17 Jan 2014 18:08:26 +0000, lipska the kat wrote:

> 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
>
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.
  
====

Personally I still can't be arsed to spend the time needed to learn C++. 
I looked at it some time ago and found it offensive for both its 
complexity and the obscene amount of code generated. In any case, far too 
much of the so-called "C++" I've looked at has been nothing more than 
ANSI C with comments delimited by "//": and not class or object in sight. 

If a programming task is essentially file manipulation I'll use awk. If 
the job is moderately complex and can be written in ANSI C I'll use that. 
If an OO approach is called for I'll use Java and, if some fiddling is 
required that Java can't do, I'll use a combination of C and Java with 
sockets for inter-language data transfer.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#27340

On 1/17/2014 9:02 PM, Martin Gregorie wrote:
> On Fri, 17 Jan 2014 18:08:26 +0000, lipska the kat wrote:
>> 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
>>
> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web