09 Dec, 2011, Vigud wrote in the 61st comment:
Votes: 0
I intentionally call Ruby and Python higher-level languages to distinguish them from other high-level languages like C. It may not be a perfect way to do that, but I think it should be clear what I mean by higher-level languages. So no, Tyche, I wasn't talking about C.
10 Dec, 2011, David Haley wrote in the 62nd comment:
Votes: 0
Tyche's sarcasm was meant to point out the fallacy in your statement, Vigud.
10 Dec, 2011, Tyche wrote in the 63rd comment:
Votes: 0
Vigud said:
I intentionally call Ruby and Python higher-level languages to distinguish them from other high-level languages like C. It may not be a perfect way to do that, but I think it should be clear what I mean by higher-level languages. So no, Tyche, I wasn't talking about C.


I know. That's why I was smiling. :-)
I wanted to list a bunch of things that C insulates the programmer from, which really establish it on the very same level as COBOL, Fortran, PL/I, Algol, Pascal, and many others.
Of course even in higher-level languages, one can introduce even higher-level abstractions and still not lose access to lower-level abstractions.
C++ with the STL is a pretty good example of that.
Some higher-level languages are designed to prevent the programmer from accessing features, often for security, like Javascript.
I think most of the languages developed for muds fall into that category.

Earlier I mentioned Ruby/FFI. It allows the the Ruby programmer to easily call operating system routines, use structs, access and use pointers.
There's also RubyInline, similar to C vendor __asm__ which allow you to compile and execute C, assembler and fortran on the fly.
There are probably similar extensions for Python.
So even though one might attempt to put mittens on programmers in higher-level languages, there are always people who are willing to code around them.
10 Dec, 2011, Vigud wrote in the 64th comment:
Votes: 0
David Haley said:
Tyche's sarcasm was meant to point out the fallacy in your statement, Vigud.

I thought so too, for a moment, but then I realized there was no fallacy in my statement, so I felt I needed to clarify some things.

Tyche, the abstraction level of C is not an analogy to what I mean. C is a programming language at a higher level than assembly languages first and foremost to make it more portable than them. That's the whole point of C. On the other hand, the whole point of higher-level languages is that you don't have to do many difficult and boring things, that you have to do when programming in C. It's portability vs convenience (+efficiency), not level 2 of abstraction vs level 4.
10 Dec, 2011, David Haley wrote in the 65th comment:
Votes: 0
Your statement was that people dealing with low-level constructs in higher-level languages than C are doing something wrong. You've provided no justification or explanation for that statement, despite several people telling you why it was a pretty sketchy thing to say. For example, one might want to leverage a higher-than-C language for all the benefits it provides, yet still need (for whatever reason) to deal with low-level things occasionally – sending binary data is a very good case of this.

This has nothing to do with "difficult and boring things", but simply solving problems.
Thus, it is fallacious, or ignorant, to state that people using higher-level-than-C languages while still manipulating low-level constructs are making any kind of mistake.
10 Dec, 2011, Runter wrote in the 66th comment:
Votes: 0
Yes, I agree with the full context of your statement. C is not convenient. ;)
11 Dec, 2011, Tyche wrote in the 67th comment:
Votes: 0
Vigud said:
Tyche, the abstraction level of C is not an analogy to what I mean. C is a programming language at a higher level than assembly languages first and foremost to make it more portable than them. That's the whole point of C.


That's the point of all high-level languages. There isn't anything different with C compared to the other high-level languages I listed. They are all portable for the same reason: they abstract themselves from the underlying machine. However, as I mentioned in an earlier post, what made C more portable was its standard library. For example, neither ALGOL and COBOL had a portable I/O library.
11 Dec, 2011, Vigud wrote in the 68th comment:
Votes: 0
Tyche said:
Vigud said:
Tyche, the abstraction level of C is not an analogy to what I mean. C is a programming language at a higher level than assembly languages first and foremost to make it more portable than them. That's the whole point of C.
That's the point of all high-level languages.
I disagree. Once the C programming language has been widely ported to multiple platforms, there wasn't any reason to create another OS programming language – other than the evolution of programming. In those times people have already been able to write their programs once, for many architectures and systems. So Perl, Ruby, Python, Java et al. exist not because more portability was needed, but more usability or convenience. Sure, higher-level languages may be portable, but that's not their purpose.
11 Dec, 2011, Runter wrote in the 69th comment:
Votes: 0
That's some crazy-silly logic. Why can't their (languages other than C) purpose be to achieve portability and convenience? If you think C didn't bring convenience as a goal when it was created you are wrong. Your disdain for higher level languages is pretty funny. Because people said similar things about higher level languages like C as you say about Python, Ruby, or whatever. You know, using C is for people who don't want to "soil their hands" in something near machine code. So maybe you've just decided there's a level of portability and convenience you're okay with. Any beyond that is indicative of lazy, ignorant programmers who don't want soil their hands. Right?
11 Dec, 2011, Vigud wrote in the 70th comment:
Votes: 0
Quote
Why can't their (languages other than C) purpose be to achieve portability and convenience?
Because the portability is already there. A programming language that aims to be as portable as C, without any additional treats, is just a plan to reinvent the wheel. It's the goodies higher-level languages give you that make them worth using. You don't use Ruby to make your program portable, most people don't care about portability anyway.

Quote
If you think C didn't bring convenience as a goal when it was created you are wrong.
It did, but only kind of - it's obviously more convenient to write a program in one version than having to write it in as many versions as the number of systems you'd want to be able to run it.

Quote
Your disdain for higher level languages is pretty funny.
I just said they're an effect of evolution and that they offer more convenience to programmers when compared to C… How is that disdain, I cannot see.

Quote
Because people said similar things about higher level languages like C as you say about Python, Ruby, or whatever.
I don't care about some abstract group of people you're referring to, but my guess is that they meant something else than I mean.

Quote
You know, using C is for people who don't want to "soil their hands" in something near machine code.
This tells me you didn't understand my point. C in the first place was for the programmers who wanted to limit the work needed to make a program run on more than just one system. C was meant to be the cure for multiple architectures, not filth of assembly languages.

Quote
Any beyond that is indicative of lazy, ignorant programmers who don't want soil their hands. Right?
Of course not. I hope it's clear now that that's not what I mean.
12 Dec, 2011, David Haley wrote in the 71st comment:
Votes: 0
Vigud said:
Quote
Any beyond that is indicative of lazy, ignorant programmers who don't want soil their hands. Right?
Of course not. I hope it's clear now that that's not what I mean.

No, it's not really clear at all, because you saying exactly that is how we got into this conversation. So unless you're saying now that you didn't actually mean that, you've only made things more confusing. :smile:
12 Dec, 2011, Runter wrote in the 72nd comment:
Votes: 0
C might have been "first to the market" in terms of good portability.. Although I don't really even believe that's true.. But portability is pretty standard quo in new languages in of the last 20 years, and I think you're wrong that Ruby developers, or any other developers, don't care about portability. That's not a trait unique to people writing lower level code. In my professional life, I'm testing, staging, and deploying code across many different architectures. It's no surprise that the Ruby interpreter would be written in C. It can be built and optimized to any architecture, and I think that is actually quite important.
12 Dec, 2011, David Haley wrote in the 73rd comment:
Votes: 0
Right. The difference is that you rely on the interpreter to take care of portability.

Oh wait – just like you rely on the compiler to take care of portability.

:smirk:
12 Dec, 2011, Vigud wrote in the 74th comment:
Votes: 0
Quote
Oh wait – just like you rely on the compiler to take care of portability.
Could you explain, please?
12 Dec, 2011, David Haley wrote in the 75th comment:
Votes: 0
You rely on the compiler to translate your keywords and control flow into whatever machine language, and in some cases, OS environment, the compiler targets. You also rely on the standard library that, typically, comes with the compiler to translate OS-specific commands (like I/O).

That's portability: you write code in C, and you let the compiler worry about turning C into machine instructions in x86, ARM, whatever.
13 Dec, 2011, Rarva.Riendf wrote in the 76th comment:
Votes: 0
The reason C is so ubiquitous is because its intruction set is low. It may be a 'high level' langage, it is not a very high one. There is a difference between writing a compiler for xx number of instruction and one with xxxx instructions.

edit:And before everyone start being anal about it, yes i know has no 'instruction set' as defined by the cpu. But most higher langage use a lot more of default libraries. ANSI C
13 Dec, 2011, Tyche wrote in the 77th comment:
Votes: 0
Rarva.Riendf said:
The reason C is so ubiquitous is because its intruction set is low. It may be a 'high level' langage, it is not a very high one. There is a difference between writing a compiler for xx number of instruction and one with xxxx instructions.

edit:And before everyone start being anal about it, yes i know has no 'instruction set' as defined by the cpu. But most higher langage use a lot more of default libraries. ANSI C


I don't know what you mean by instruction set, but if language keywords are any measure of compiler complexity:
Quote
LUA 21
XPL 32
PL/I 28
Python 31
Oberon 32
C 32
Pascal 35
Ruby 36
Java 50
Algol 61
C++ 62
Fortran 72
Cobol 357

Now I've read that it was a real pain in the ass to write a COBOL compiler, yet it was the most used programming language up until 1990.
XPL, PL/M (subset of PL/I above), Oberon have and still are being used to develop operating systems and compilers.
Looks like LUA and Python have "low instruction sets" compared to C.
13 Dec, 2011, Tyche wrote in the 78th comment:
Votes: 0
Vigud said:
I disagree. Once the C programming language has been widely ported to multiple platforms, there wasn't any reason to create another OS programming language – other than the evolution of programming.


There's been a slew of systems programming languages before and after C. Apple used Pascal up until they went to Darwin, and Pascal spawned Modula-2 and Oberon which continue to be used in operating system development. PL/M is still being used in both IBM Z/series and ES/9000 series operating systems in spite of C being available. The kernel of Windows is written and maintained using MASM still to this day. Many of the supporting dlls and drivers have migrated to C and C++. With Windows 7 and 8 much of the operating system is written in C# managed code. C as an operating system language, and application language is popular on architectures where the compiler produces fast code. This is not an inherent feature of the C language itself, it's a feature of particular implementations.
60.0/78