Re: Can I remove an element from a global associative array from within a class destructor?

2019-08-02 Thread Jonathan M Davis via Digitalmars-d-learn
On Friday, August 2, 2019 5:13:10 PM MDT realhet via Digitalmars-d-learn 
wrote:
> Hi,
>
> I tried to make some resource statistict for my OpenGL Buffer
> objects:
>
>
> //here are the things that hold the statistics.
> private __gshared{ size_t[int] textureSizeMap, bufferSizeMap; }
>
> struct GLCounters{
>int programs, shaders, textures, buffers;
>size_t textureSize, bufferSize;
> }
> __gshared GLCounters glCounters;
>
> ...
>
> //And this is the buffer creation.
> int genBuffer(size_t size){
>int res; glGenBuffers (1, ); glChk;
>glCounters.buffers ++;
>glCounters.bufferSize  += size;
>bufferSizeMap [res] = size;
>writefln("buffer allocated %d %d", res, size);
>return res;
> }
>
> //Finally, this is the deallocation. If it is called from the GC
> (when it destroys a class), it has a big chance to throw an
> Invalid Memory Operation exception.
>
> void deleteBuffer (int handle){
>if(!handle) return;
>glDeleteBuffers (1, ); glChk;
>glCounters.buffers --;
>glCounters.bufferSize  -= bufferSizeMap [handle];
>writefln("buffer deallocated %d %d", handle, bufferSizeMap
> [handle]);
>bufferSizeMap.remove(handle); <- this is the problematic part.
> }
>
> 
> Today I read the documentation about structs, unions and classes,
> but I haven't find any restrictions for the ~this() destructors.
>
> Is there some extra rules regarding the GC and what I must not do
> in the destructors?
>
> I think the destructor always called in the same thread where the
> instance was created. This can't be the case.
> But what I can guess is: The GC makes a collection and calls my
> destructor and inside I do something and the GC calls a
> collection again recursively. But it seems a bit crazy, so I
> think it's not the case :D
>
> Please help me solve this!
>
> *I'm using LDC 1.6.0 Win64

As I understand it, you can't do much of anything that involves the GC
inside a destructor that's being run as a finalizer by the GC (as is almost
always the case with classes). Structs or classes on the stack (which for
classes requires something like scope) don't have that problem, because
they're not being run by the GC. But if a struct or class is on the GC heap,
then attempting to allocate or deallocate GC resources doesn't work, because
the destructor/finalizer runs when the GC is doing a collection. Even trying
to use other objects that are on the GC heap from a finalizer is not a
allowed, because there is no guarantee about the order that the objects are
collected (otherwise, cyclical references would be a big problem), meaning
that references in the finalizer could refer to objects that have already
been destroyed and their memory freed.

https://dlang.org/spec/class.html#destructors

Basically, destructors/finalizers for anything on the GC heap are just for
cleaning up non-GC-allocated resources.

- Jonathan M Davis





Re: [OT] Re: Using Haskell for teaching [was: Help me decide D or C]

2019-08-02 Thread Jonathan M Davis via Digitalmars-d-learn
On Friday, August 2, 2019 11:05:13 AM MDT Russel Winder via Digitalmars-d-
learn wrote:
> On Fri, 2019-08-02 at 10:25 -0600, Jonathan M Davis via
> Digitalmars-d-learn wrote:
>
> […]
>
> > My feeling is that functional languages are likely to be a very poor
> > place for most folks to start learning, much as I think that they're
> > great for someone to learn and work with at some point. I have heard of
> > beginning programming classes using functional languages and having it
> > go very well, but it seems hard to believe to me. Imperative
> > programming can already be a lot for beginners, but most people really
> > don't think even vaguely in a functional manner. Even simple recursion
> > tends to be a bit of a mind-bender for people at first.
>
> […]
>
> At UCL in the late 1980s and early 1990s, we used a functional programming
> language in the first term and C++ in the second term for teaching
> programming. Initially Scheme was the functional programming language but
> we then switched to Miranda (which was a pre-cursor to Haskell).
>
> This deep immersion in two totally different programming paradigms worked
> very well. The mid/late 1990s mad rush to Java everywhere in teaching (of
> which I was a part) was in hindsight madness (of a global sort). The move
> by many institutions to using Python first and then Java rebalances
> somewhat but is missing the point – it's about the paradigms. I have
> retrenched as a believer in the Haskell/C++, or Prolog/Java, or some
> such. In the new era with new undergraduates already knowing Scratch and
> Python, universities should really go the whole hog in getting
> programming paradigms and programming as a skill as well as knowledge,
> with all the tools,fair and square into the first year curriculum.
>
> Of course I have been out of academia for 20 years, and am now out of
> employment, so my views have no impact. :-)

The university I went to had an undergrad class on programming paradigms
that I _think_ was required (maybe two even), but it was definitely just the
focus of a small number of classes, whereas my experience is that you get a
lot more out of it when you actually use a language with a different
paradigm for a while rather than just doing one group of assignments in it -
and when the class covers multiple programming paradigms, that also dilutes
how much you get out of each. On some level, as with many things, a lot of
it depends on how much the students decide to put into it on their own.

I still find it funny that the class that got me started with Haskell was
the grad version of the programming paradigms course, and we used Haskell
only because the teacher was always using Scheme (in fact, he was a
developer for Dr. Scheme IIRC) and felt like doing something different. So,
while I'd used Scheme some in an undergrad course, I ended up using Haskell
in the course with the teacher who was majorly into Scheme. It seemed a bit
like if one of the major D contributors decided to use Rust for a bit just
to try something different.

Of course, I haven't done anywhere near as good a job at learning new
languages for a while now, because I've been focused enough on D that I
haven't really wanted to spend time writing programs in something else. And
I don't think that it works very well to really learn a language if you
don't use it as your go-to language for a while (at least if you want to
be good at more than the basics). There's no question though that I'm better
at D thanks to the time I spent on languages such as Haskell.

- Jonathan M Davis






Can I remove an element from a global associative array from within a class destructor?

2019-08-02 Thread realhet via Digitalmars-d-learn

Hi,

I tried to make some resource statistict for my OpenGL Buffer 
objects:



//here are the things that hold the statistics.
private __gshared{ size_t[int] textureSizeMap, bufferSizeMap; }

struct GLCounters{
  int programs, shaders, textures, buffers;
  size_t textureSize, bufferSize;
}
__gshared GLCounters glCounters;

...

//And this is the buffer creation.
int genBuffer(size_t size){
  int res; glGenBuffers (1, ); glChk;
  glCounters.buffers ++;
  glCounters.bufferSize  += size;
  bufferSizeMap [res] = size;
  writefln("buffer allocated %d %d", res, size);
  return res;
}

//Finally, this is the deallocation. If it is called from the GC 
(when it destroys a class), it has a big chance to throw an 
Invalid Memory Operation exception.


void deleteBuffer (int handle){
  if(!handle) return;
  glDeleteBuffers (1, ); glChk;
  glCounters.buffers --;
  glCounters.bufferSize  -= bufferSizeMap [handle];
  writefln("buffer deallocated %d %d", handle, bufferSizeMap 
[handle]);

  bufferSizeMap.remove(handle); <- this is the problematic part.
}


Today I read the documentation about structs, unions and classes, 
but I haven't find any restrictions for the ~this() destructors.


Is there some extra rules regarding the GC and what I must not do 
in the destructors?


I think the destructor always called in the same thread where the 
instance was created. This can't be the case.
But what I can guess is: The GC makes a collection and calls my 
destructor and inside I do something and the GC calls a 
collection again recursively. But it seems a bit crazy, so I 
think it's not the case :D


Please help me solve this!

*I'm using LDC 1.6.0 Win64




Re: Function called twice

2019-08-02 Thread Simen Kjærås via Digitalmars-d-learn

On Friday, 2 August 2019 at 21:44:28 UTC, Jordan Wilson wrote:

Hello,

I don't quite understand why isEven is called twice in the 2nd 
example?


auto isEven(int n) {
n.writeln;
return (n % 2) == 0;
}

void main() {

auto z = [1,2,3];

// outputs 1 2 3
z.map!(a => tuple!("number")(a))
 .filter!(a => a.number.isEven)
 .array;

// outputs 1 2 2 3
z.map!(a => tuple!("number","iseven")(a, a.isEven))
 .filter!(a => a.iseven)
 .array;

return;
}


map doesn't memoize its front value 
(https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d#L604), so every time someone looks at it the mapping function needs to be called again. So in the second case, for each item first filter calls map.front which calls isEven, then if it matches the filter (so only the 2), array calls filter.front, which calls map.front, which calls isEven.


You can avoid this by eagerly iterating to an array:

z.map!(a => tuple!("number","iseven")(a, a.isEven))
.array // new!
.filter!(a => a.iseven)
.array;

I was also gonna suggest using std.functional.memoize to memoize 
the function in map, but apparently it doesn't like lambdas 
(https://issues.dlang.org/show_bug.cgi?id=20099).


--
  Simen


Re: Function called twice

2019-08-02 Thread Boris Carvajal via Digitalmars-d-learn

On Friday, 2 August 2019 at 21:44:28 UTC, Jordan Wilson wrote:

Hello,

I don't quite understand why isEven is called twice in the 2nd 
example?


auto isEven(int n) {
n.writeln;
return (n % 2) == 0;
}

void main() {

auto z = [1,2,3];

// outputs 1 2 3
z.map!(a => tuple!("number")(a))
 .filter!(a => a.number.isEven)
 .array;

// outputs 1 2 2 3
z.map!(a => tuple!("number","iseven")(a, a.isEven))
 .filter!(a => a.iseven)
 .array;

return;
}

Thanks,

Jordan


The way map is designed is to call its predicate on each front 
call and filter calls it twice with the number 2.

https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d#L604

You can use "cache" to avoid the double front call on any range.

z.map!(a => tuple!("number","iseven")(a, a.isEven))
 .cache
 .filter!(a => a.iseven)
 .array;



Re: Function called twice

2019-08-02 Thread Jordan Wilson via Digitalmars-d-learn

On Friday, 2 August 2019 at 22:35:53 UTC, Adam D. Ruppe wrote:

On Friday, 2 August 2019 at 21:44:28 UTC, Jordan Wilson wrote:

// outputs 1 2 2 3
z.map!(a => tuple!("number","iseven")(a, a.isEven))
 .filter!(a => a.iseven)
 .array;


I *think* what's happening here is first it calls map() first 
going into the filter... then it gets called again when it is 
being evaluated for the array.


So like basically consider if you had:

if(filter(a())
   array ~= a();


that kind of thing. I think anyway, I'm not entirely sure but 
it fits what I can see happening here.


but idk why it is actually doing this in the phobos 
implementation


In my real-world case "isEven" is a long running function. I'll 
put an .array after the map and see if it makes a difference.


Thanks,

Jordan


Re: Function called twice

2019-08-02 Thread Adam D. Ruppe via Digitalmars-d-learn

On Friday, 2 August 2019 at 21:44:28 UTC, Jordan Wilson wrote:

// outputs 1 2 2 3
z.map!(a => tuple!("number","iseven")(a, a.isEven))
 .filter!(a => a.iseven)
 .array;


I *think* what's happening here is first it calls map() first 
going into the filter... then it gets called again when it is 
being evaluated for the array.


So like basically consider if you had:

if(filter(a())
   array ~= a();


that kind of thing. I think anyway, I'm not entirely sure but it 
fits what I can see happening here.


but idk why it is actually doing this in the phobos implementation


Function called twice

2019-08-02 Thread Jordan Wilson via Digitalmars-d-learn

Hello,

I don't quite understand why isEven is called twice in the 2nd 
example?


auto isEven(int n) {
n.writeln;
return (n % 2) == 0;
}

void main() {

auto z = [1,2,3];

// outputs 1 2 3
z.map!(a => tuple!("number")(a))
 .filter!(a => a.number.isEven)
 .array;

// outputs 1 2 2 3
z.map!(a => tuple!("number","iseven")(a, a.isEven))
 .filter!(a => a.iseven)
 .array;

return;
}

Thanks,

Jordan


Re: How do I use mixin types?

2019-08-02 Thread Adam D. Ruppe via Digitalmars-d-learn

On Friday, 2 August 2019 at 21:10:08 UTC, Andrej wrote:

The D spec mentions something called mixin types:


This is brand new to the spec and hasn't yet been released in a 
compiler.


You can get a nightly build here 
https://dlang.org/changelog/pending.html to maybe try, but I 
don't think it will be in a proper release until ... my guess is 
Sept 1.


How do I use mixin types?

2019-08-02 Thread Andrej via Digitalmars-d-learn

The D spec mentions something called mixin types:

https://dlang.org/spec/grammar.html#MixinType
https://dlang.org/spec/type.html#mixin_types

If I'm understanding the grammar right, it means you can use a 
string mixin anywhere a Type would normally go, for example:



int func(mixin("int") x)
{
return x;
}


However, when I try to compile that fragment (using dmd 2.086.1), 
it fails with the following error:


.\mixintype.d(1): Error: basic type expected, not `mixin`

...and then a few more cascading errors as a result of it not 
understanding the mixin.


I've tried placing the mixin on the right hand side of an alias 
declaration, but that didn't work either.


I've found literally nothing about this feature online except for 
the official spec so I'm starting to question whether this is an 
actual language feature or not...


I'd really like it to exist, otherwise I'd need to use a regular 
mixin declaration to define the entire function.


Re: Help me decide D or C

2019-08-02 Thread Jon Degenhardt via Digitalmars-d-learn

On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote:
Should I go for C and then when I become a better programmer 
change to D?

Should I start with D right now?


In my view, the most important thing is the decision you've 
already made - to pick a programming language and learn it in a 
reasonable bit of depth. Which programming language you choose is 
less important. No matter which choice you make you'll have the 
opportunity to learn skills that will transfer to other 
programming languages.


As you can tell from the other responses, the pros and cons of a 
learning a specific language depend quite a bit on what you hope 
to get out of it, and are to a fair extent subjective. But both C 
and D provide meaningful opportunities to gain worthwhile 
experience.


A couple reasons for considering learning D over C are its 
support for functional programming and templates. These were also 
mentioned by a few other people. These are not really "beginner" 
topics, but as one moves past the beginner stage they are really 
quite valuable techniques to start mastering. For both D is the 
far better option, and it's not necessary to use either when 
starting out.


--Jon


1 new

2019-08-02 Thread jmh530 via Digitalmars-d-learn
When I navigate to https://forum.dlang.org/ I have a message that 
says "1 new reply" to "your posts." Normally, I click on that "1 
new reply" and find the post that's new, go to it, and the 
message disappears. However, it doesn't seem to go away anymore. 
I tried looking at many different old posts without luck. At one 
point it was up to "2 new replies," but I viewed that other post 
and it went back down to "1 new reply." Does anyone else have 
this?


Re: Help me decide D or C

2019-08-02 Thread berni via Digitalmars-d-learn

On Friday, 2 August 2019 at 14:05:20 UTC, SashaGreat wrote:

On Friday, 2 August 2019 at 12:28:45 UTC, berni wrote:

On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote:
Should I go for C and then when I become a better programmer 
change to D?

Should I start with D right now?


In my oppinion C should have been deprecated about 50 years 
ago ...


I stopped there. How could you have deprecated a language 50 
years ago since was first released in '72 (47 years ago).


Yes, that was intentional. What I wanted to say is, that I think, 
that it would have been better, if C was never invented at all... 
In that case, there would have been space for an other language 
for writing operating systems, without that much bugs in its 
design. (But one never knows afterwards...)




[OT] Re: Using Haskell for teaching [was: Help me decide D or C]

2019-08-02 Thread Russel Winder via Digitalmars-d-learn
On Fri, 2019-08-02 at 10:25 -0600, Jonathan M Davis via Digitalmars-d-learn
wrote:
> 
[…]
> My feeling is that functional languages are likely to be a very poor place
> for most folks to start learning, much as I think that they're great for
> someone to learn and work with at some point. I have heard of beginning
> programming classes using functional languages and having it go very well,
> but it seems hard to believe to me. Imperative programming can already be a
> lot for beginners, but most people really don't think even vaguely in a
> functional manner. Even simple recursion tends to be a bit of a mind-bender
> for people at first.
[…]

At UCL in the late 1980s and early 1990s, we used a functional programming
language in the first term and C++ in the second term for teaching
programming. Initially Scheme was the functional programming language but we
then switched to Miranda (which was a pre-cursor to Haskell).

This deep immersion in two totally different programming paradigms worked very
well. The mid/late 1990s mad rush to Java everywhere in teaching (of which I
was a part) was in hindsight madness (of a global sort). The move by many
institutions to using Python first and then Java rebalances somewhat but is
missing the point – it's about the paradigms. I have retrenched as a believer
in the Haskell/C++, or Prolog/Java, or some such. In the new era with new
undergraduates already knowing Scratch and Python, universities should really
go the whole hog in getting programming paradigms and programming as a skill
as well as knowledge, with all the tools,fair and square into the first year
curriculum. 

Of course I have been out of academia for 20 years, and am now out of
employment, so my views have no impact. :-)
 
-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part


Re: Help me decide D or C

2019-08-02 Thread Alexandre via Digitalmars-d-learn

On Friday, 2 August 2019 at 15:51:25 UTC, Russel Winder wrote:
On Fri, 2019-08-02 at 13:45 +, Alexandre via 
Digitalmars-d-learn wrote:



[…]
Could you elaborate more about C being a burden? I have read 
so many people saying C gives a great foundation and should be 
everyone's first language. Now I am confused.


C is a programming language created in the early 1970s to make 
writing UNIX easier. Early versions of UNIX (and Multics before 
it) were written in assembly language. Dennis Ritchie et al. 
wanted to use a programming language that had a higher level of 
abstraction than assembly language so as to make writing UNIX 
easier. BCPL gave many of the ideas for B which led to C, 
effectively a portable assembly language but with special eyes 
on the PDP-8, PDP-11, and later VAX-11 machine codes. C was 
hugely successful for writing operating systems because it was 
"close to the metal" and yet with better abstractions than 
assembly language. I spent many happy (and many unhappy) hours 
in the early 1980s writing device drivers for UNIX 6, UNIX 7, 
and BSD 4.0. C was the right tool for the job at hand at that 
time.


Many tools associated with UNIX were written in C, including 
the C compiler, since the only other option at the time in the 
UNIX context was assembly language. Already though there was 
the question: was C the right tool for the job of writing 
applications – as opposed to hardware controlling software. One 
could argue that "buffer overruns" was  clear evidence that C 
was the wrong tool for the job.


Unfortunately the obsession with C, even if it was not the 
right tool for the job at hand, had taken hold: if you didn't 
write your application in C you were somehow a second or third 
rate human being, let alone programmer.


Then came C++ (or then C with Classes) and the beginning of the 
rift between the C camp and the "we need a programming language 
with higher levels of abstraction" camp. I am sure many can 
write lots on the 1990s and 2000s and the various language 
wars, but here we are in 2010s entering the 2020s and we have 
D, Rust, Go, Java, Kotlin, Python, Ruby, C++, Lisp, Prolog, 
Erlang, etc. all of which have their problems, but all of which 
have their "sweet spots" for being the right tool for the job 
at hand. C is no longer the de facto standard language for 
writing all software. People are increasingly recognising that 
it is as if C were specifically created for writing software 
that controls hardware.


C still has a role in the world of programming, and it 
definitely has a status as one of the most important 
programming languages ever.


Moral of this story is that, for me, in 2019, if you are 
writing applications

software or software tools, C is not the right tool for the job.


Do you thing D would be the right tool for the job at this point 
for me? Assuming I have 2 goals in mind: 1) become a better 
programmer and 2) want to make fun writing software for myself 
and if possible show something I might be proud of.
I thought C would be a better choice for the 1), because everyone 
says it's great to see whats behind the hood and things like 
that. My experience with C btw is CS50 course, plus around 
200/300 pages of some books, still reading and a few toy 
projects. So, basically 0 knowledge. haha. But after reading your 
opinion, I guess C might not be the right tool for me, since I 
wont be doing any kind of thing related to hardware (I think).




I have receive so many good opinions so far. I realize there is 
no consensus what so ever. As I was suggested Haskell, Python, D, 
C etc. It's a good thing, but hard to make a decision.


Re: Why does choose not work here

2019-08-02 Thread berni via Digitalmars-d-learn

On Thursday, 1 August 2019 at 21:26:10 UTC, Matt wrote:

Anyone have any other thoughts?


I tried to simplify your example a little bit:

import std.stdio;
import std.range;
import std.algorithm;

auto myFilter(R1, R2)(R1 a, R2 b)
{
return a.filter!(c => c==b.front);
}

struct A
{
int[] starts;

auto intervalRange() @property
{
return starts;
}
}

auto uniqIntervalsA(A primary, A* previous) @property
{
return choose(previous is null,
  primary.intervalRange,
  primary.intervalRange.filter!(a => 
a==previous.intervalRange.front));

}

auto uniqIntervalsB(A primary, A* previous) @property
{
return choose(previous is null,
  primary.intervalRange,
  
primary.intervalRange.myFilter(previous.intervalRange));

}

unittest
{
auto a1 = A([1]);

writeln(uniqIntervalsA(a1,));
writeln(uniqIntervalsA(a1,null));
writeln(uniqIntervalsB(a1,));
writeln(uniqIntervalsB(a1,null));
}

The strange thing is, that even if you replace "return 
a.filter!(c => c==b.front);" by "return a.filter!(c => true);" 
the problem remains (but now you can use lazy). As I'm not an 
expert myself, I'm not sure how to analyze this. But I think, 
both parameters to "choose" are evaluated (that is they are not 
lazy), but "myFilter" uses it's parameter immediately to give "b" 
a value, while "filter" just hands in an anonymous function 
without using it ever.


Hope, this helps to get further down the way to a solution...


Re: Help me decide D or C

2019-08-02 Thread Jonathan M Davis via Digitalmars-d-learn
On Friday, August 2, 2019 10:13:04 AM MDT bachmeier via Digitalmars-d-learn 
wrote:
> On Thursday, 1 August 2019 at 22:36:06 UTC, Russel Winder wrote:
> > On Thu, 2019-08-01 at 14:49 +, bachmeier via
> > Digitalmars-d-learn wrote: […]
> >
> >> There's nothing wrong with Haskell if you want to take a deep
> >> dive into pure functional programming. I personally find
> >> Haskell to be more of a religion than a programming language.
> >> You can learn the same perspective from functional-first
> >> languages like Clojure, Scala, Ocaml, and F#.
> >
> > […]
> >
> > Whilst I agree that most "this is the one true programming
> > language" people are quasi-religious, programming languages are
> > not: Haskell is a just a lazy, pure functional programming
> > language, some adherents show quasi-religious fervour, just as
> > some adherents of C++, Java, C, Go, Rust, D, etc. do.
> >
> > I am not sure about F# (I do not know anything of it), but
> > Clojure, Scala, and OCaml are very different from Haskell for
> > various reasons, cf. lazy vs. eager, pure vs. impure. Haskell
> > is a programming language worth learning for all
> > programmers,along with Lisp, Prolog, and Erlang.
> >
> > I'll bet (but I have no experimental data, just a hypothesis)
> > that any D programmer that knows Haskell writes better D than a
> > D programmer who doesn't know Haskell.
>
> This is getting somewhat off the topic of this thread, so all
> I'll say is that I agree with the recommendation to learn
> Haskell, but I don't think a beginner would get enough exposure
> to various approaches to programming. I did not personally see
> large benefits from Haskell, but perhaps I should have stuck with
> it longer.

Using Haskell or other similar functional languages can be extremely
beneficial towards improving how good you are at recursion, and it can make
you much better at functional programming paradigms, because you really
don't have much choice when using a language like Haskell. For a couple of
years, Haskell was my go-to language for all of my side projects, and I got
much better at the functional side of things (e.g. when I first used D
templates, I had no problem with their functional nature to the point that I
didn't realize that they were functional in nature until I read an article
that compared Haskell to C++ templates). That being said, I'd _hate_ to use
Haskell for anything serious or for any large projects. It's just too
restrictive.

My feeling is that functional languages are likely to be a very poor place
for most folks to start learning, much as I think that they're great for
someone to learn and work with at some point. I have heard of beginning
programming classes using functional languages and having it go very well,
but it seems hard to believe to me. Imperative programming can already be a
lot for beginners, but most people really don't think even vaguely in a
functional manner. Even simple recursion tends to be a bit of a mind-bender
for people at first.

- Jonathan M Davis






Re: Help me decide D or C

2019-08-02 Thread bachmeier via Digitalmars-d-learn

On Thursday, 1 August 2019 at 22:36:06 UTC, Russel Winder wrote:
On Thu, 2019-08-01 at 14:49 +, bachmeier via 
Digitalmars-d-learn wrote: […]
There's nothing wrong with Haskell if you want to take a deep 
dive into pure functional programming. I personally find 
Haskell to be more of a religion than a programming language. 
You can learn the same perspective from functional-first 
languages like Clojure, Scala, Ocaml, and F#.

[…]

Whilst I agree that most "this is the one true programming 
language" people are quasi-religious, programming languages are 
not: Haskell is a just a lazy, pure functional programming 
language, some adherents show quasi-religious fervour, just as 
some adherents of C++, Java, C, Go, Rust, D, etc. do.


I am not sure about F# (I do not know anything of it), but 
Clojure, Scala, and OCaml are very different from Haskell for 
various reasons, cf. lazy vs. eager, pure vs. impure. Haskell 
is a programming language worth learning for all 
programmers,along with Lisp, Prolog, and Erlang.


I'll bet (but I have no experimental data, just a hypothesis) 
that any D programmer that knows Haskell writes better D than a 
D programmer who doesn't know Haskell.


This is getting somewhat off the topic of this thread, so all 
I'll say is that I agree with the recommendation to learn 
Haskell, but I don't think a beginner would get enough exposure 
to various approaches to programming. I did not personally see 
large benefits from Haskell, but perhaps I should have stuck with 
it longer.


Re: Help me decide D or C

2019-08-02 Thread bachmeier via Digitalmars-d-learn

On Friday, 2 August 2019 at 13:57:44 UTC, Bastiaan Veelo wrote:
On Thursday, 1 August 2019 at 20:02:08 UTC, Aurélien Plazzotta 
wrote:

[...]
But don't fool yourself, D is not for beginners. Ali Çehreli 
is a very skilled programmer, ergo, he can't reason like a 
new/starting programmer anymore, regardless of his patience 
and kindness.


I am sorry, but this is very strange reasoning. Would you 
recommend a book on programming written by someone who is not a 
skilled programmer himself in any language? I certainly would 
not.


Even stranger when you consider the earlier recommendation to

take pleasure in learning F*. It is a pure functional 
programming language based on logical-mathematical thought


Re: Help me decide D or C

2019-08-02 Thread Russel Winder via Digitalmars-d-learn
On Fri, 2019-08-02 at 13:45 +, Alexandre via Digitalmars-d-learn wrote:
> 
[…]
> Could you elaborate more about C being a burden? I have read so 
> many people saying C gives a great foundation and should be 
> everyone's first language. Now I am confused.

C is a programming language created in the early 1970s to make writing UNIX
easier. Early versions of UNIX (and Multics before it) were written in
assembly language. Dennis Ritchie et al. wanted to use a programming language
that had a higher level of abstraction than assembly language so as to make
writing UNIX easier. BCPL gave many of the ideas for B which led to C,
effectively a portable assembly language but with special eyes on the PDP-8,
PDP-11, and later VAX-11 machine codes. C was hugely successful for writing
operating systems because it was "close to the metal" and yet with better
abstractions than assembly language. I spent many happy (and many unhappy)
hours in the early 1980s writing device drivers for UNIX 6, UNIX 7, and BSD
4.0. C was the right tool for the job at hand at that time.

Many tools associated with UNIX were written in C, including the C compiler,
since the only other option at the time in the UNIX context was assembly
language. Already though there was the question: was C the right tool for the
job of writing applications – as opposed to hardware controlling software. One
could argue that "buffer overruns" was  clear evidence that C was the wrong
tool for the job.

Unfortunately the obsession with C, even if it was not the right tool for the
job at hand, had taken hold: if you didn't write your application in C you
were somehow a second or third rate human being, let alone programmer.

Then came C++ (or then C with Classes) and the beginning of the rift between
the C camp and the "we need a programming language with higher levels of
abstraction" camp. I am sure many can write lots on the 1990s and 2000s and
the various language wars, but here we are in 2010s entering the 2020s and we
have D, Rust, Go, Java, Kotlin, Python, Ruby, C++, Lisp, Prolog, Erlang, etc.
all of which have their problems, but all of which have their "sweet spots"
for being the right tool for the job at hand. C is no longer the de facto
standard language for writing all software. People are increasingly
recognising that it is as if C were specifically created for writing software
that controls hardware. 

C still has a role in the world of programming, and it definitely has a status
as one of the most important programming languages ever.

Moral of this story is that, for me, in 2019, if you are writing applications
software or software tools, C is not the right tool for the job.
 
-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part


Re: Help me decide D or C

2019-08-02 Thread Bastiaan Veelo via Digitalmars-d-learn

On Friday, 2 August 2019 at 13:45:17 UTC, Alexandre wrote:

On Friday, 2 August 2019 at 12:30:44 UTC, berni wrote:

On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote:

[...]


In my oppinion C should have been deprecated about 50 years 
ago and it's not worth while to learn it if you are not 
interested in the history of programming or you have to learn 
it, because you need to maintain software which is allready 
written in C. But that's my oppinion; others may have a 
different sight.


[...]


Could you elaborate more about C being a burden? I have read so 
many people saying C gives a great foundation and should be 
everyone's first language. Now I am confused.


One example is this recent post: 
https://forum.dlang.org/post/yjgkatpbkdyyksldg...@forum.dlang.org


“[...] recently all the problems I am having with D are because D 
is actually superior to C and some assumptions I still have 
because of C should be uninstalled from my brain.”


If you plan on ending up with D anyway, I think that learning C 
first is an unnecessary detour and can be counter productive in 
some ways. And if your objective is to have fun, I would 
recommend against C (except for a masochistic kind of fun).


Don’t take the detour, take the D tour! :-)

Bastiaan.


Re: Help me decide D or C

2019-08-02 Thread SashaGreat via Digitalmars-d-learn

On Friday, 2 August 2019 at 12:28:45 UTC, berni wrote:

On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote:
Should I go for C and then when I become a better programmer 
change to D?

Should I start with D right now?


In my oppinion C should have been deprecated about 50 years ago 
...


I stopped there. How could you have deprecated a language 50 
years ago since was first released in '72 (47 years ago).


C like it or not is still highly used today (Kernel, LIB, 
Embedded Systems).


If it was so terrible as you and others are saying it would be 
damned a long time ago.


It has flaws?

Sure, but like C++, D, Java, Go, Python has it owns flaws too and 
they all came later.


Sasha.


Re: Help me decide D or C

2019-08-02 Thread Bastiaan Veelo via Digitalmars-d-learn
On Thursday, 1 August 2019 at 20:02:08 UTC, Aurélien Plazzotta 
wrote:

[...]
But don't fool yourself, D is not for beginners. Ali Çehreli is 
a very skilled programmer, ergo, he can't reason like a 
new/starting programmer anymore, regardless of his patience and 
kindness.


I am sorry, but this is very strange reasoning. Would you 
recommend a book on programming written by someone who is not a 
skilled programmer himself in any language? I certainly would not.


Besides, the OP has already expressed his appreciation for Ali’s 
writing.


Bastiaan.



Re: Help me decide D or C

2019-08-02 Thread Alexandre via Digitalmars-d-learn

On Friday, 2 August 2019 at 12:30:44 UTC, berni wrote:

On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote:

[...]


In my oppinion C should have been deprecated about 50 years ago 
and it's not worth while to learn it if you are not interested 
in the history of programming or you have to learn it, because 
you need to maintain software which is allready written in C. 
But that's my oppinion; others may have a different sight.


[...]


Could you elaborate more about C being a burden? I have read so 
many people saying C gives a great foundation and should be 
everyone's first language. Now I am confused.


Re: Help me decide D or C

2019-08-02 Thread Daniel Kozak via Digitalmars-d-learn
On Fri, Aug 2, 2019 at 2:30 PM berni via Digitalmars-d-learn
 wrote:
> ...
> I would even go further and state, that learning C first will
> become a burden instead of a help.
>

Yes, I agree with this. It is same as with C++. Many people starts
with C and then learn C++. Which is really not a good idea.


Re: Help me decide D or C

2019-08-02 Thread berni via Digitalmars-d-learn

On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote:
Should I go for C and then when I become a better programmer 
change to D?

Should I start with D right now?


In my oppinion C should have been deprecated about 50 years ago 
and it's not worth while to learn it if you are not interested in 
the history of programming or you have to learn it, because you 
need to maintain software which is allready written in C. But 
that's my oppinion; others may have a different sight.


I would recommend to start immediately with D (using the book of 
Ali, which has allready been mentioned). When you've got mastered 
D you will not have any problems switching to an other language. 
And you don't need to know everything about D to write programs. 
For example you do not need to use templates in the beginning. 
You might find out a strange looking syntax for type conversion 
"to!string(17)" with this exclamation mark in between, which you 
can just accept and us as is, without having to understand what 
it's good for.


I would even go further and state, that learning C first will 
become a burden instead of a help.






Re: Help me decide D or C

2019-08-02 Thread berni via Digitalmars-d-learn

On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote:
Should I go for C and then when I become a better programmer 
change to D?

Should I start with D right now?


In my oppinion C should have been deprecated about 50 years ago 
and it's not worth while to learn it if you are not interested in 
the history of programming or you have to learn it, because you 
need to maintain software which is allready written in C. But 
that's my oppinion; others may have a different sight.


I would recommend to start immediately with D (using the book of 
Ali, which has allready been mentioned). When you've got mastered 
D you will not have any problems switching to an other language. 
And you don't need to know everything about D to write programs. 
For example you do not need to use templates in the beginning. 
You might find out a strange looking syntax for type conversion 
"to!string(17)" with this exclamation mark in between, which you 
can just accept and us as is, without having to understand what 
it's good for.


I would even go further and state, that learning C first will 
become a burden instead of a help.






Re: Help me decide D or C

2019-08-02 Thread Guillaume Piolat via Digitalmars-d-learn

On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote:


Should I go for C and then when I become a better programmer 
change to D?

Should I start with D right now?



D and C++ (and probably other languages) inherit features of C 
such as operator precendence, integer promotion, and a few 
things. So learning these specific points of C will pay dividends.


However, I don't see any other reason - apart from platform 
support maybe - to bother with C when D is available.





Re: Help me decide D or C

2019-08-02 Thread IGotD- via Digitalmars-d-learn

On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote:

Hi everyone,

I would like an honest opinion.
I have a beginner level (able to do very small programs) in a 
few languages  such as python, go, C, guile(scheme) and common 
lisp. I want to pick a language and go deep with it and focus 
on only one for at least the next 2 years or so.


Should I go for C and then when I become a better programmer 
change to D?

Should I start with D right now?

The reason I am considering starting with C: since I am a 
beginner, obvious I will need lots of books, tutorials, videos 
etc. And I believe C would have more resources and maybe a low 
level to help with programming in general. And, when I need a 
more powerful language, I would than learn D. Since you know 
the good and the ugly of the D programming language I wonder, 
what you would think would be the best to do right now?


Thank you for your help!


It depends what you want to do.

C is a good language for low level, embedded programming. For 
"higher" level programming like web clients/servers, text 
processing, programs with graphical user interface then C is just 
awful because it has fewer built in primitives and libraries. 
Also with more complicated program C in general requires more 
boiler plate.


Then we have C++ but in general it has the same problems as I 
mentioned with C but programming is slightly more convenient as 
it has classes, exceptions and some more powerful libraries due 
to templates, operator overloading such things.


D is somewhere in the middle between Java and C++. Syntax is much 
better and intuitive than C++. Thanks to that it is more inspired 
by Java, the libraries are in general more convenient to use and 
cleaner.


I'd say D is a good choice for learning programming as it sits in 
the high seat of low level and high level. No, other language 
combines that as good as D I think.


Also if you start with D you can easily go to C++ or Java.

I'd say start with D and then learn C++ because it would be 
interesting to hear from a person who learn D first, thinks of 
C++.




Blog Post #0058: Cairo Rectangles

2019-08-02 Thread Ron Tarrant via Digitalmars-d-learn
Continuing on with Cairo, this is a look at the variations and 
permutations of drawing rectangles and you'll find it here: 
https://gtkdcoding.com/2019/08/02/0058-cairo-ii-rectangles.html




Re: Help me decide D or C

2019-08-02 Thread Tony via Digitalmars-d-learn

On Wednesday, 31 July 2019 at 22:30:52 UTC, Alexandre wrote:


My goals:

1) Improve as a programmer
2) Have fun doing programs

That's it basically. I am planning to study all "free" time I 
have. I am doing basically this since last year.


Are you only considering D and C or just mentioning them in this 
forum? The interpreted dynamically-typed languages like Python 
are considered easier to use and have the largest amount of 
functionality in their libraries.


If it is just down to D or C, then definitely D. C would be at or 
near the bottom in terms of a language to have fun doing general 
programming and learning.