On Friday, June 10, 2016 02:38:28 Ola Fosheim Grøstad via Digitalmars-d wrote:
> On Thursday, 9 June 2016 at 21:54:05 UTC, Jack Stouffer wrote:
> > On Thursday, 9 June 2016 at 21:46:28 UTC, Walter Bright wrote:
> >> Programming is a mix of engineering and craft. There are people who do research into programming theory, and those are computer scientists. I'm not one of them. Andrei is.
> >
> > Unfortunately, the term "software engineer" is a LOT less popular than "computer scientist".
>
> How so? I only hear people use the term "programmer" or "informatics".

I assume that you're not from the US?

In the US at least, professional programmers are almost always referred to officially as software engineers (though they use the term programmers informally all the time), whereas the terms computer science and computer scientist are generally reserved for academics. And while the term informatics (or very similar terms) are used in several other languages/countries, I've never heard the term used in the US except to mention that some other languages/countries use the term informatics for computer science, and I'm willing to bet that relatively few programmers in the US have ever even heard the term informatics.

- Jonathan M Davis

On Thursday, 9 June 2016 at 16:44:23 UTC, Yura wrote:
> 4) The C language is well tested and rock solid stable.

loooooool.

On Friday, 10 June 2016 at 06:25:55 UTC, ketmar wrote:
> On Thursday, 9 June 2016 at 16:44:23 UTC, Yura wrote:
>> 4) The C language is well tested and rock solid stable.
>
> loooooool.

ah, sorry, let me explain myself. i hit ALOT of gcc bugs in my life. and i never fixed any of them myself, 'cause gcc is very huge, and i don't feel that it worth it. even with bugs that blocked my work i used workarounds and hand-written asm.

i hit some bugs in D too. curiously, it comparable with gcc in numbers (maybe this tells us something, and maybe it is just a coincidence). some of them i was able not only report, but fix. usually, official fix comes later, and was better than mine hacky patch, but hey... DMD compiler is less complex than gcc, *alot* less complex.

now, why i loled: i thinked about what you wrote, and found that gcc bugs blocks my work/pet projects more often than dmd bugs. it may sounds strange, but dmd bug is usually either fixed fast enough (and building new dmd+druntime+phobos from sources takes less than two minutes on my PC), or i know a workaround.

contrary to that, even if gcc bug was fixed fast (and usually they don't), rebuilding gcc takes 20‒30 minutes. and most of the time i can't even understand what fix does, due to huge and unknown codebase.

so no, C languange is not "rock solid stable". it just has alot less features, and if you will use the same feature set in DMD, you will hardly hit a bug too.

On Friday, 10 June 2016 at 05:37:37 UTC, Jonathan M Davis wrote:
> I assume that you're not from the US?

Right, I am in Oslo (Norway).

> In the US at least, professional programmers are almost always referred to officially as software engineers (though they use the term programmers informally all the time), whereas the terms computer science and computer scientist are generally reserved for academics

Well, I don't know what is "official". Some norwegian companies seem to use convoluted "international business" terminology for everything, which is just weird and "snobbish". I think "system developer" ("systemutvikler") is the broad general term here.

So you can be an "informatiker" (broad term for your education) with an education in the fields of "computer science" and "software engineering", and work in the role of a "system developer".

If you have a bachelor that fulfills the requirements for starting on a comp.sci. master then you are a computer scientist, but if you have a bachelor that doesn't and focus more on practical computing then you are a software engineer?

You can have an education that is all about discrete math and still be a computer scientist. You couldn't then say you have a bachelor in software engineering, as it would be wrong. Likewise, you can have a bachelor in software engineering and barely know anything about complexity theory.


> And while the term informatics (or very similar terms) are used in several other languages/countries, I've never heard the term used in the US except to mention that some other languages/countries use the term informatics for computer science, and I'm willing to bet that relatively few programmers in the US have ever even heard the term informatics.

Yes, but it makes sense to distinguish between "computer science" (the timeless math and concepts behind computing) and "software engineering" (contemporary development methodology and practice). Although I think an education should cover both. "Informatics" just covers it all (as an educational field).

On Friday, 10 June 2016 at 06:37:08 UTC, ketmar wrote:
> On Friday, 10 June 2016 at 06:25:55 UTC, ketmar wrote:
>> On Thursday, 9 June 2016 at 16:44:23 UTC, Yura wrote:
>>> 4) The C language is well tested and rock solid stable.
>>
>> loooooool.
>
> ah, sorry, let me explain myself. i hit ALOT of gcc bugs in my life. and i never fixed any of them myself, 'cause gcc is very huge, and i don't feel that it worth it. even with bugs that blocked my work i used workarounds and hand-written asm.
>
> i hit some bugs in D too. curiously, it comparable with gcc in numbers (maybe this tells us something, and maybe it is just a coincidence). some of them i was able not only report, but fix. usually, official fix comes later, and was better than mine hacky patch, but hey... DMD compiler is less complex than gcc, *alot* less complex.
>
> now, why i loled: i thinked about what you wrote, and found that gcc bugs blocks my work/pet projects more often than dmd bugs. it may sounds strange, but dmd bug is usually either fixed fast enough (and building new dmd+druntime+phobos from sources takes less than two minutes on my PC), or i know a workaround.
>
> contrary to that, even if gcc bug was fixed fast (and usually they don't), rebuilding gcc takes 20‒30 minutes. and most of the time i can't even understand what fix does, due to huge and unknown codebase.
>
> so no, C languange is not "rock solid stable". it just has alot less features, and if you will use the same feature set in DMD, you will hardly hit a bug too.

Thanks all of you for the constructive discussion, I am a chemist studying the programming by myself since I need it to explore chemistry at the molecular level and to check my chemical ideas. The professional software engineer(SE)/computer scientist(CS) would do the job much faster, and the resulting code would look much better - but, to do that you need to explain all the chemistry behind to SE/CS which would be tricky, and the most important (drastic) approximations come exactly from chemistry - not from the particular language. I hope you excuse me for the long introduction. In my area there are 3 languages dominating: Python, Fortran and C/C++. The first is easy (many libraries are available), but might be very slow. Fortran is used by the old professors, tons of libraries, but is not used outside of academia - and this stops young people from studying it because everyone at some point may quit an academia. C and C++ perhaps dominate the field, but especially the second one is very tough for people coming from non-IT background.

I believe D has very high chances to be competitive in this field. Regarding the GC, I will try to check it when I have some time, but since most of the codes are written in non-GC languages (https://en.wikipedia.org/wiki/List_of_quantum_chemistry_and_solid-state_physics_software), something tells me that GC would slow you down because in this field people are fighting for every percent of the performance (many simulations are running for weeks). Another point is to link the libraries, with my poor background in IT, even to link the C library to the C code is a challenge, and something tells me that to link it to D would be even more challenging => to make linking the C libraries as easy as possible (Fortran or C++ libraries are not as important) and to have active support forum when you can as for help in linking the libraries to your D code would be helpful. As people have this support, then they are confident to start their new projects in D. Then, at the conferences/ in the scientific papers people can advertise and promote the language, which is more user friendly than C, Fortran and C++ and is modern enough.
However, perhaps, only enthusiasm is not sufficient for all this, you need the sponsors... I agree the C subset for sure guarantees (almost) absence of bugs.
Another things where I do almost all my mistakes is: array bounding/calling the memory which was free => the result is undefined behavior. If I remember correctly the D is better with that respect?
Anyway, super easy way to use all C libraries + super active support would clearly help to increase D popularity/adoption. All other point I raised are perhaps not that important.

On Friday, 10 June 2016 at 08:29:50 UTC, Yura wrote:
> something tells me that GC would slow you down
> because in this field people are fighting for every
> percent of the performance (many simulations are
> running for weeks).

yes, GC will have an effect for such things. but then, people fighting for performance will resort to "dirty tricks" in any language, i believe, and in D it is not that hard to avoid GC (i'm doing something like that in my videogame and sound engines). but the great thing — at least for me — that you can easily prototype your solution with GC, debug it, and then gradually replace data structures with other data structures that does manual memory management. this way you can debug your data structures and algorithms independently.

of course, it is possible in C and C++ too, but i found that with D it is somewhat easier.

> Another point is to link the libraries, with my poor
> background in IT, even to link the C library to the
> C code is a challenge, and something tells me that
> to link it to D would be even more challenging

i found that D is better here too, it just require some... discipline. thanks to UFCS, one can write D code that *looks* like OOP, but actualy only using structs and free functions. this way you can use `export(C)` on your public API, and still use `myvar.myfunc()` syntax in D, but have C-ready `myfunc(&myvar)` syntax to export. also, with some CTFE magic one can even generate such wrappers in compile time.

> Another things where I do almost all my mistakes is: array bounding/calling the memory which was free => the result is undefined behavior. If I remember correctly the D is better with that respect?

yes. with GC, you won't hit "use after free" error. and D does bound checking on array access (this can be turned off once you debugged your code), so you will get a stack trace on RangeError.

> Anyway, super easy way to use all C libraries + super active support would clearly help to increase D popularity/adoption.

and as for C libraries... i'm actively using alot of C libs in my D projects, and most of the time i do wrappers for them with sed. ;-) i.e. i'm just taking C header file, run some regular expression replaces on it, and then do some manual cleanup. that is, even without specialized tools one is able to produce a wrapper with very small time and effort investement.

tbh, i even translated some C libraries to D mostly with sed. for example, enet and libotr.

On Thursday, 9 June 2016 at 16:44:23 UTC, Yura wrote:
> Hello,
>
> I have to stress I am beginner in programming, mainly interested in number crunching in academia (at least so far). I started to write a small project in D, but had to switch to C for few reasons:
>
> 1) Importance for my CV. I know Python, if I add also C - it sounds, and could be useful since the C language is, apart from the other reasons, is popular and could help me wit the future job, both in academia and industry, since there are many C/C++ projects.

I wouldn't worry too much about the CV. Maybe in a year or two companies will demand you know Ruby or Javascript :) Once you know who to program it's not so hard to pick up other languages. The basic concepts of handling / mapping data are always the same (hash tables, arrays ...)

> 2) The libraries - in the scientific world you can find practically everything which has already been coded in C, => many C libraries. To link it to be used within D code requires some work/efforts, and since I am not that confident in my IT skills, I decided that C code calling C libraries is much safer.

It's a piece of cake most of the time, it's really easy.[1] When I first tried it, I couldn't believe that it was _that_ simple. I use some C code too in one of my projects and it's easy to either call individual C functions or, if needs be, you can turn a C header file into a D interface file with only a few changes (they will almost look identical).

There is absolutely no reason not to use D because of existing C libraries. The seamless interfacing to C is one of D's major advantages. In this way you can write elegant D code and still take advantage of the plethora of C libraries that are available.

Here are examples of porting C libraries that have D interfaces:

https://github.com/D-Programming-Deimos?page=1

If you need help, you can always ask on the forum. Nobody will bite you :-)

There are even D frameworks that enable you to interact with Python [2] and Lua. I'd say give it a shot.

[1] http://dlang.org/spec/interfaceToC.html
[2] https://github.com/ariovistus/pyd

Other links:

http://dlang.org/ctod.html

http://dlang.org/articles.html


> 3) For C - a lot of tutorials, everything has been explained at stack overflow many times, huge community of people. E.g. you want to use OpenMP, Open MPI - everything is there, explained many times, etc.
>
> 4) The C language is well tested and rock solid stable. However, if you encounter a potential bug in D, I am not sure how long would it take to fix.
>
> 5) Garbage collector - it will slow my number crunching down.

You should test it first, gut feeling is not a proof. If it really does slow down your code, write GC free code, as ketmar suggested. You can always ask on the .learn forum.

> Please, do not take it as criticism, I like D language, I tried it before C and I find it much much easier, and user friendly. I feel it is more similar to Python. On the other hand C++ is too complex for me, and D would be the perfect option for the scientific community, if the above points would be fixed somehow..
>
> Best luck with your work!

And also, always use ldc or gdc, once your project is ready to go. dmd generated code is slow as it is only a reference compiler.

http://dlang.org/download.html

On Friday, 10 June 2016 at 09:35:32 UTC, Chris wrote:
> And also, always use ldc or gdc, once your project is ready to go. dmd generated code is slow as it is only a reference compiler.

but not *dog* *slow*. ;-) if one don't really need to squeeze every possible cycle out of CPU, DMD-generated code is more than acceptable. i, for example, managed to make my scripting language almost as efficient with DMD -O as Lua with gcc -O3. ;-)

On Friday, 10 June 2016 at 09:46:11 UTC, ketmar wrote:
> On Friday, 10 June 2016 at 09:35:32 UTC, Chris wrote:
>> And also, always use ldc or gdc, once your project is ready to go. dmd generated code is slow as it is only a reference compiler.
>
> but not *dog* *slow*. ;-) if one don't really need to squeeze every possible cycle out of CPU, DMD-generated code is more than acceptable. i, for example, managed to make my scripting language almost as efficient with DMD -O as Lua with gcc -O3. ;-)

No not slow slow. Even in debugging mode it produces acceptable results for testing.

A scripting language based on D? Is it open source? I've always dreamt of something like that.