Hi people, I’m new to D and I am curious about how high level is D compared to another languages. I have a list of what languages to compare and I wanna know where you would classify D among them.
The languages are: C, C++, Objective-C, D, Go, Swift, Pascal, Fortran, BASIC, Cobol, C#, Forth and Java.

When I talk about low and high level language I’m referring to how much control the language gives to the hardware and what has more abstraction levels.

On Wednesday, 21 November 2018 at 09:56:16 UTC, bmelo wrote:
> Hi people, I’m new to D and I am curious about how high level is D compared to another languages. I have a list of what languages to compare and I wanna know where you would classify D among them.
> The languages are: C, C++, Objective-C, D, Go, Swift, Pascal, Fortran, BASIC, Cobol, C#, Forth and Java.
>
> When I talk about low and high level language I’m referring to how much control the language gives to the hardware and what has more abstraction levels.

Well, at a high level, D does support the notion of a class.

However, D does not treat a class as an isolated conceptual unit (a type).

You can pretend a class is such a unit however, by isolating it within its own module.

So to understand D, you need to first understand the purpose of the module - and I still have trouble with that, since I use classes as the highest form of abstraction.

As for low level, which I don't do, the compiler is now written in D isn't it? Presumably, that involves some pretty low level stuff ;-)

So compare with languages that can do these two things, I would say.

I'm not sure that Cobol has a compiler written in Cobol??

On Wednesday, 21 November 2018 at 09:56:16 UTC, bmelo wrote:
> Hi people, I’m new to D and I am curious about how high level is D compared to another languages. I have a list of what languages to compare and I wanna know where you would classify D among them.
> The languages are: C, C++, Objective-C, D, Go, Swift, Pascal, Fortran, BASIC, Cobol, C#, Forth and Java.
>
> When I talk about low and high level language I’m referring to how much control the language gives to the hardware and what has more abstraction levels.

In this regard, D is a lot like C++ in the regard that it can go both low-level and high-level. You can go as low as you can with C/C++/Forth: You can drop the type system, manage raw memory and even embed assembly into code.

But D can also get high-level and abstract a lot. Of the languages you listed, I don't think any of them, with possible exception of Swift (which I don't know about, except that it's a new language), or Forth with some VERY advanced meta library, can match expressive power of D.

On Wednesday, 21 November 2018 at 11:26:04 UTC, Dukc wrote:
> On Wednesday, 21 November 2018 at 09:56:16 UTC, bmelo wrote:
>> Hi people, I’m new to D and I am curious about how high level is D compared to another languages. I have a list of what languages to compare and I wanna know where you would classify D among them.
>> The languages are: C, C++, Objective-C, D, Go, Swift, Pascal, Fortran, BASIC, Cobol, C#, Forth and Java.
>>
>> When I talk about low and high level language I’m referring to how much control the language gives to the hardware and what has more abstraction levels.
>
> In this regard, D is a lot like C++ in the regard that it can go both low-level and high-level. You can go as low as you can with C/C++/Forth: You can drop the type system, manage raw memory and even embed assembly into code.
>
> But D can also get high-level and abstract a lot. Of the languages you listed, I don't think any of them, with possible exception of Swift (which I don't know about, except that it's a new language), or Forth with some VERY advanced meta library, can match expressive power of D.

But D gives more access to hardware than Go? I listened about D not going so weel to embedded and operating system programming like C and C++ because GC. Is D's GC more able to give you hardware control than Go's GC?

On Wednesday, 21 November 2018 at 12:30:28 UTC, bmelo wrote:

> But D gives more access to hardware than Go? I listened about D not going so weel to embedded and operating system programming like C and C++ because GC. Is D's GC more able to give you hardware control than Go's GC?

You only need the GC to access all of D's standard library. D also has things like -betterC:
https://dlang.org/spec/betterc.html
It's not difficult to get rid of the GC, you just don't have as nice a language if you do that.

On Wednesday, 21 November 2018 at 12:30:28 UTC, bmelo wrote:
> But D gives more access to hardware than Go? I listened about D not going so weel to embedded and operating system programming like C and C++ because GC.

Here's embedded D: https://github.com/JinShil/stm32f42_discovery_demo#the-good

On Wednesday, 21 November 2018 at 10:27:11 UTC, NoMoreBugs wrote:
> Well, at a high level, D does support the notion of a class.
>
> However, D does not treat a class as an isolated conceptual unit (a type).
>
> You can pretend a class is such a unit however, by isolating it within its own module.

What? D certainly does "treat classes as types". Every class in D is its own type and supoorts the reguar methods of encapsulation as you would expect. The only difference is that in D, private class members and methods are module-public, meaning that anything else in the module can freely access them. That does not break encapsulation by any means, however.

On Wed, 21 Nov 2018 16:30:30 +0000, Meta wrote:
> On Wednesday, 21 November 2018 at 10:27:11 UTC, NoMoreBugs wrote:
>> Well, at a high level, D does support the notion of a class.
>>
>> However, D does not treat a class as an isolated conceptual unit (a
>> type).
>>
>> You can pretend a class is such a unit however, by isolating it within its own module.
> 
> What? D certainly does "treat classes as types". Every class in D is its own type and supoorts the reguar methods of encapsulation as you would expect. The only difference is that in D, private class members and methods are module-public, meaning that anything else in the module can freely access them. That does not break encapsulation by any means, however.

NoMoreBugs and their 4-5 other aliases are extremely annoyed at D's `private` being private-to-the-module, like a third of programming languages, instead of private-to-the-type, like a different third of programming languages. It's apparently far too much work to put a type in a different module from code that shouldn't be able to access its private members.

On Wednesday, 21 November 2018 at 12:30:28 UTC, bmelo wrote:
> But D gives more access to hardware than Go? I listened about D not going so weel to embedded and operating system programming like C and C++ because GC. Is D's GC more able to give you hardware control than Go's GC?

More machine-contorl than Go? Easily. Go's GC cannot be dropped, or so I've been told. In D, you can program even if the GC hasn't been implemented for your platform at all. The whole C standard library and large parts of Phobos are still in use, and you can still manage memory by RAII (Resource-Acquisition-Is-Initialization) idiom or by reference counting.

You are still miles ahead of using C, and not necessarily worse off than with C++ either. Many third-party D libraries won't work without GC, but you can still use all C libraries and some C++ libraries (Can somebody tell what are the changes of C++ interop working in practice? No personal experience) from D.

But what you need to consider for embedded targets is that unlike C/C++, D excepts at least 32-bit architechture by design. If one wants to program devices smaller than that, something else is needed.

On Wednesday, 21 November 2018 at 16:48:29 UTC, Neia Neutuladh wrote:
>
> NoMoreBugs and their 4-5 other aliases are extremely annoyed at D's `private` being private-to-the-module, like a third of programming languages, instead of private-to-the-type, like a different third of programming languages. It's apparently far too much work to put a type in a different module from code that shouldn't be able to access its private members.

Actually, I pointed this out for a reason.

(1) - it's just plain fact (i.e. the private state of a class, within a module, is not really private at all)

(2) - its' completely unlike what a C++/Java/C# programmer would expect (the 3 most widely used languages).

If (2) weren't also fact, I would not feel inclined to mention it.

Your constant attacks on me for not liking D's leaking class abstraction is a reflection of *your attitude* towards me. But my statement is factually correct. Better to know that upfront than to discover it by mistake, as many seem to do - me included.

Please let me enlighten newcomers so that they understand D, without being constantly attacking for doing so, by people like you. What is your motive for doing so anyway?