www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How I use D

reply Cym13 <cpicard purrfect.fr> writes:
The original "Phobos is cool" thread encouraged me to share my 
experience.

D has been one of my two main languages for about 5 years now. I 
use it almost daily in my work where it has proved very useful. 
Yet I don't think a case such as mine is discussed often so I 
thought I would take the time to explain how and why I use D. I 
don't expect anything in return, but I wonder how many users have 
a similar use of the language and whether this user base is 
significant enough to warrant consideration.

But first of all, why should you care?

You probably shouldn't. I'm not a software developer, my 
company's business doesn't rely on D in any way, I'll never write 
a killer app or case study and even if I were to share a library 
it probably wouldn't be maintained more than a week. I'm not 
someone that'll bring much value back in the language.

I'm a security consultant. My job is to find security issues and 
exploit them. I'm sure most of you know about pentesters yet my 
job goes a bit beyond common penetration testing. I review 
websites and networks but also attack electronic devices, perform 
malware analysis, source code review, cryptographic review, human 
manipulation, lockpicking... Anything goes.

In that context I very often need to write dedicated tools. I 
don't have the luxury of time: since most missions take about a 
week I feel lucky if I get 2 days to write an exploit. This means 
that I need to prototype a solution very quickly. For that, the 
goto language in my field is Python (Go is coming big recently). 
Python is my other language of predilection and fast scripting is 
where it absolutely shines and given its large library support 
(both standard and community based) it is often the right tool 
for the job. However I often end up needing more performances or 
low level access and optimizing Python is hard.

For example when trying to exploit a tight race condition I need 
all the speed I can get, especially when that race condition 
happens in a chip on which I'm directly connected. Similarily for 
things like bruteforcing running 10% faster may be the difference 
between finding an access in time or not.

The difference with D is that I can start very scripty, using no 
explicit type, then adding details in once I have a strong 
skeleton. I know that style is often dismissed by more industrial 
users but it's one of the core reasons why I use D.

I use almost exclusively UFCS function chains when prototyping 
because they fit the way I think perfectly. UFCS is absolutely a 
killer feature for me from a design perspective. If I use 
something else it is either because I'm optimizing (I found that 
basic for loops often yield better performances than long 
templated UFCS chains) or because I'm porting another program to 
D.

Since I don't choose the technologies I'm facing I end up 
constantly butting heads against new formats or protocols. In 
these cases I often port part of a parsing library to D or use a 
C one directly if available.

D is perfect to use C libraries or port libraries from other 
languages.

I rarely get enough time to port a full library but the fact that 
D supports all paradigms really shines there since it enables me 
to port programs without rethinking their architecture. It's 
rarely optimal but it's a huge time saver as a first step.

I also get to use that at a low level. For example the other day 
I was studying a ransomware. I needed to do some statistics over 
a large amount of files, started decompiling the malware code by 
hand translating it into C-style D, then hit a function that was 
not fun to reverse (often the case in cryptographic code). I took 
the disassembly, stuck it into an asm{} statement, tweaked it 
just enough to get it working and continued decompiling the rest 
without needing to worry about that function anymore.

I could have done it in another way, but this meant that I didn't 
need to change language at any time, it was all in D, I could 
optimize it all as needed at the end. This is especially 
important since I need to balance this low-level code with the 
high-level contexts in which they are found (and said context 
rarely makes it easy for me).

There are some tools that I use often and wrote myself in D 
(generally variants of "we need to try every element of this list 
as quickly as possible"). In general it is painless and 
efficient. I've even had a few surprises of code that I 
prototyped in D, reformated in C-style D for performance, 
translated in C for even more performance, discovered that pure C 
was slower than my C-style DMD generated code (?) so rolled back 
to D.

The only time where I had some issues were that time I wrote a 
Windows trojan in D. I needed to do some pretty convoluted stuff 
to load my code in just the right way to avoid antiviruses and it 
wasn't fun to do it in D.  Cross-compiling this proved another 
hurdle. It would have been easier in C++ directly. But I can't 
very well blame anyone not to make malware development easier and 
none of the issues I had should impact normal development.

Most of the code I write exploits a specific cryptographic 
mistake, buffer overflow or race condition for a specific client 
so I have nothing left to publish. As I said at the beginning, 
even though I write D code daily I am just not working on 
projects that are likely to ever bring back to the community. 
And, for all the code I write, I'm not a developper. I wouldn't 
know how to manage a project that lasts more than 3 days 
honnestly. That doesn't mean that I'm not serious about code 
quality (I spend days reviewing code and explaining to 
programmers how to make it better after all) but I don't 
contribute code to open-source projects. I'm just a selfish user 
minding his own business.

As for issues... (What? It wouldn't be a correct forum post 
without issue...)

The low number of native libraries is not ideal. Yes, I can use a 
C library or port it from another language but I've generally got 
less than two days to work on a project. Any time spent on this 
is time not spent on actually solving the problem.

For the same reason I am a huge advocate of battery-included 
stdlib. I know many are of the opinion of moving as much as 
possible from Phobos into dub.  For me any library that isn't in 
dub is one more library I have to evaluate, try, keep track of 
when they update. It's lost time. Huge projects can have a 
mindset of "we'll manage our own version anyway" but my projects 
are written in a few days and are useful a week or two at most. 
So go Phobos, go! We also need lots of libraries but that is the 
kind of things that is built upon a strong standard library, not 
at its expense.

Then there's the omnipresent negativity of a huge chunk of the 
community...  it's rough. I used to read the forums daily until I 
noticed that it stressed me a lot, made me feel angry and sad and 
that it wasn't the place I wanted to be. Now I mostly keep an eye 
on Announce. I have no idea how this can be fixed though so I'll 
leave it at that. I completely assume the irony of posting this 
here.

All in all I've tried hard to find a better language than D for 
my work, but its design choices make it a really good fit for my 
purpose. The main reason why I still use lots of Python is 
because of its library support and because I can expect my 
coworkers and clients to be able to run it without issue or 
hour-long explainations. I hope it stays that way even though I 
understand why most trends I see on the forum target more 
"industrial" users (by which I mean working on month or year-long 
software development projects in a professionnal setting). I have 
no expectations from that post, but I wonder how many others use 
D everyday at work in a similar fashion.
Jun 29 2020
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:

 The original "Phobos is cool" thread encouraged me to share my 
 experience.

 [...]


Thank you for sharing, that's refreshing!
Jun 29 2020
prev sibling next sibling parent reply Robert Schadek <rschadek symmetryinvestments.com> writes:
On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:

 The original "Phobos is cool" thread encouraged me to share my 
 experience.


Happy to read this.

I love phobos, and think it should grow and include more stuff.

What libs are you missing?
Jun 29 2020
parent reply Cym13 <cpicard purrfect.fr> writes:
On Monday, 29 June 2020 at 11:02:47 UTC, Robert Schadek wrote:

 On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:

 The original "Phobos is cool" thread encouraged me to share my 
 experience.


 Happy to read this.

 I love phobos, and think it should grow and include more stuff.

 What libs are you missing?


It's hard to pin point. As I explained I don't know from one week 
to the other whether I'll be working on an AS/400, a new 
connected lock, some bank's website in Java or a company network 
with 250k+ different machines.

I don't need 10 XML libraries, but I need 10 libraries parsing 10 
different formats. As much as possible. Formats and protocols are 
the most important for me since it's the first step to be able to 
talk to the equipment. Anything goes really.

The last I used Python was to parse a huge amount of raw Windows 
logs. The format isn't complex, I could have written a parser in 
D, but it was already there in Python so I used that. No regret, 
I like Python, but it made the choice that easy.

Dear reader, if you happen to work with a strange format that you 
think nobody has any use of but have a working parser then please 
upload it somewhere. I'm pretty sure it'll come in handy someday.
Jun 29 2020
parent reply kdmult <kdmult ya.ru> writes:
On Monday, 29 June 2020 at 13:03:27 UTC, Cym13 wrote:

 I don't need 10 XML libraries, but I need 10 libraries parsing 
 10 different formats. As much as possible. Formats and 
 protocols are the most important for me since it's the first 
 step to be able to talk to the equipment. Anything goes really.

 The last I used Python was to parse a huge amount of raw 
 Windows logs. The format isn't complex, I could have written a 
 parser in D, but it was already there in Python so I used that. 
 No regret, I like Python, but it made the choice that easy.

 Dear reader, if you happen to work with a strange format that 
 you think nobody has any use of but have a working parser then 
 please upload it somewhere. I'm pretty sure it'll come in handy 
 someday.


Maybe https://kaitai.io/ will be useful to you.
Jul 01 2020
parent reply JN <666total wp.pl> writes:
On Wednesday, 1 July 2020 at 10:27:21 UTC, kdmult wrote:

 Maybe https://kaitai.io/ will be useful to you.


Looks very similar to Google's Protocol Buffers. What is the main 
benefit of kaitai over protobuf?
Jul 01 2020
next sibling parent David Gileadi <gileadisNOSPM gmail.com> writes:
On 7/1/20 12:35 PM, JN wrote:

 On Wednesday, 1 July 2020 at 10:27:21 UTC, kdmult wrote:

 Maybe https://kaitai.io/ will be useful to you.


 
 Looks very similar to Google's Protocol Buffers. What is the main 
 benefit of kaitai over protobuf?


I was curious too. From their FAQ [1]:


 In short: these projects and Kaitai Struct solve completely different problems.


There follows an explanation that points out how Kaitai Struct is 
designed to handle existing binary formats like .gif, .wav or .zip.


 So, to summarize:
 
 * "Have data in memory, need binary protocol" ⇒ use Protobuf & company
 * "Have binary protocol, need data in memory" ⇒ use Kaitai Struct


[1]: http://doc.kaitai.io/faq.html#vs-protobuf
Jul 01 2020
prev sibling next sibling parent kdmult <kdmult ya.ru> writes:
On Wednesday, 1 July 2020 at 19:35:26 UTC, JN wrote:

 On Wednesday, 1 July 2020 at 10:27:21 UTC, kdmult wrote:

 Maybe https://kaitai.io/ will be useful to you.


 Looks very similar to Google's Protocol Buffers. What is the 
 main benefit of kaitai over protobuf?


Perhaps their "Format Gallery" [1] or IDE [2].

[1] https://formats.kaitai.io/
[2] https://ide.kaitai.io/
Jul 01 2020
prev sibling parent reply Les De Ridder <les lesderid.net> writes:
On Wednesday, 1 July 2020 at 19:35:26 UTC, JN wrote:

 On Wednesday, 1 July 2020 at 10:27:21 UTC, kdmult wrote:

 Maybe https://kaitai.io/ will be useful to you.


 Looks very similar to Google's Protocol Buffers. What is the 
 main benefit of kaitai over protobuf?


If you've worked with Protobuf you will know it's hard to specify
certain things, e.g. relationships between values and types. I 
assume
Kaitai is better at this.

For example, in Protobuf you can't really specify that the value 
of a
field will determine the type of the next field. It expects you 
to just
use something like a field for the type id, and a dynamic/byte 
array
field for the payload, to then do the type casting in application 
code.

For things like container file formats this makes Protobuf 
insufficient,
but for its main purpose, defining binary wire protocols, it's 
not as
much of an issue.
Jul 02 2020
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 2 July 2020 at 12:59:59 UTC, Les De Ridder wrote:

 For example, in Protobuf you can't really specify that the 
 value of a
 field will determine the type of the next field. It expects you 
 to just
 use something like a field for the type id, and a dynamic/byte 
 array
 field for the payload, to then do the type casting in 
 application code.

 For things like container file formats this makes Protobuf 
 insufficient,
 but for its main purpose, defining binary wire protocols, it's 
 not as
 much of an issue.


I'm trying to figure out how to ask this clarifying question. I 
have not done much with protobuf usage but do agree it isn't 
really meant for file storage.

I did a parser for open street maps[1] years ago. They utilized 
protobuf to define the file format of the inner protobuf.

When you say you need a byte array I don't understand why you 
would not just fill a field with the type you want. But like I 
said it was years ago and I do not remember if osm would clarify 
that for me.




1. 
https://github.com/JesseKPhillips/libosm/blob/master/examples/dump/source/app.d
Jul 02 2020
prev sibling next sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:

 I'm a security consultant. My job is to find security issues 
 and exploit them. I'm sure most of you know about pentesters 
 yet my job goes a bit beyond common penetration testing. I 
 review websites and networks but also attack electronic 
 devices, perform malware analysis, source code review, 
 cryptographic review, human manipulation, lockpicking... 
 Anything goes.



Super interesting thanks!
Jun 29 2020
parent reply Guillaume Piolat <first.name gmail.com> writes:
On Monday, 29 June 2020 at 11:18:03 UTC, Guillaume Piolat wrote:

 On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:

 I'm a security consultant. My job is to find security issues 
 and exploit them. I'm sure most of you know about pentesters 
 yet my job goes a bit beyond common penetration testing. I 
 review websites and networks but also attack electronic 
 devices, perform malware analysis, source code review, 
 cryptographic review, human manipulation, lockpicking... 
 Anything goes.



 Super interesting thanks!


I'll bite:

I've been defending:
    - unsafe by default,
    - throw by default,
    - impure by default,
    - mutable by default

for years. To me those defaults are the right ones, and it warms 
me up that, as it seems, your D usage would be made _almost 
impossible_ if the permissive default changed to a strict one.

I've been in a similar situation where you have to create an 
internal tool as fast as possible because of limited political 
support, and all those features  - that are completely rational 
and acceptable in the right context - may reveal a liability in 
the trenches.

So I hope people will keep the important use cases of _bad 
programs_, may I say in mind when improving D.
Jun 29 2020
next sibling parent Cym13 <cpicard purrfect.fr> writes:
On Monday, 29 June 2020 at 12:18:02 UTC, Guillaume Piolat wrote:

 I'll bite:

 I've been defending:
    - unsafe by default,
    - throw by default,
    - impure by default,
    - mutable by default

 for years. To me those defaults are the right ones, and it 
 warms me up that, as it seems, your D usage would be made 
 _almost impossible_ if the permissive default changed to a 
 strict one.

 I've been in a similar situation where you have to create an 
 internal tool as fast as possible because of limited political 
 support, and all those features  - that are completely rational 
 and acceptable in the right context - may reveal a liability in 
 the trenches.

 So I hope people will keep the important use cases of _bad 
 programs_, may I say in mind when improving D.


I have mixed feelings about that. On one hand I absolutely agree 
with you, if these features were in place D would probably not be 
nearly as useful to me as it is now.

On the other hand, I spend my days exploiting security issues and 
I think that these features would be effective to fight real bugs 
that have real consequences. I don't want to be suject to these 
limitations, but if more people were subjected to them I would 
have a harder time finding bugs which is good.

It wouldn't solve all issues of course (most issues are at a much 
higher level such as forgetting to protect a webpage with 
authentication) but it would help.

(Even if I'd be stuck)
Jun 29 2020
prev sibling parent Cym13 <cpicard purrfect.fr> writes:
On Monday, 29 June 2020 at 12:18:02 UTC, Guillaume Piolat wrote:

 I'll bite:

 I've been defending:
    - unsafe by default,
    - throw by default,
    - impure by default,
    - mutable by default

 for years. To me those defaults are the right ones, and it 
 warms me up that, as it seems, your D usage would be made 
 _almost impossible_ if the permissive default changed to a 
 strict one.

 I've been in a similar situation where you have to create an 
 internal tool as fast as possible because of limited political 
 support, and all those features  - that are completely rational 
 and acceptable in the right context - may reveal a liability in 
 the trenches.

 So I hope people will keep the important use cases of _bad 
 programs_, may I say in mind when improving D.


This is absolutely true. These are the reason why D is useful to 
me.

That said, I have mixed feelings since it's also true that, 
should these features be introduced by default, they would help 
with many bugs I see that cause security issues. As much as I 
like my job I would be happier if it weren't needed.

It wouldn't fix everything since the most common issues are at a 
much higher level (such as forgetting to protect a web page with 
authentication). It would help with memory corruptions and 
possibly race conditions since it would incentivise safer use of 
multithreading.

I'd be stuck though. Please don't. I don't want to write Go :p
Jun 29 2020
prev sibling next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:

 The original "Phobos is cool" thread encouraged me to share my 
 experience.

 [...]


Interesting and thank you for it. This could be a nice blog post, 
imho.
Jun 29 2020
prev sibling next sibling parent matheus <matheus gmail.com> writes:
On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:

 I'm a security consultant. My job is to find security issues 
 and exploit them. I'm sure most of you know about pentesters 
 yet my job goes a bit beyond common penetration testing. I 
 review websites and networks but also attack electronic 
 devices, perform malware analysis, source code review, 
 cryptographic review, human manipulation, lockpicking... 
 Anything goes.


It would be cool to see a blog post about this.

Matheus.
Jun 29 2020
prev sibling next sibling parent reply Mathias LANG <geod24 gmail.com> writes:
On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:

 The original "Phobos is cool" thread encouraged me to share my 
 experience.


Thanks a lot for sharing ! It's great to see a balanced post by a 
serious user.

You mentioned a few times that you don't bring much value back to 
the language. I don't really think that matters, as it's just 
natural that most people use tools without contributing to them, 
even in OSS. As someone having invested a ridiculous amount of my 
time in D, I surely don't blame anyone for not choosing the same 
path. But if you even mentioned D to a couple of your colleagues, 
that's a good contribution, in my book.


 The difference with D is that I can start very scripty, using 
 no explicit type, then adding details in once I have a strong 
 skeleton. I know that style is often dismissed by more 
 industrial users but it's one of the core reasons why I use D.


At one of the DConf, there was a panel asking: "What do you love 
about D ?"
Suggestions were made, and people voted, unfortunately I cannot 
seem to find the talk anymore. If memory serves me well, what 
made it to the top of the list was "Fast prototyping". And as an 
industry user (and a programmer by trade), I find the same 
advantages apply: We're working on a blockchain project, and the 
ability to prototype quickly, and iterate through multiple ideas 
/ improvements without too much trouble is amazing.
I'm curious, given your use case, how did you feel about  safe by 
default ?


 The only time where I had some issues were that time I wrote a 
 Windows trojan in D. I needed to do some pretty convoluted 
 stuff to load my code in just the right way to avoid 
 antiviruses and it wasn't fun to do it in D.  Cross-compiling 
 this proved another hurdle. It would have been easier in C++ 
 directly. But I can't very well blame anyone not to make 
 malware development easier and none of the issues I had should 
 impact normal development.


If I understand correctly, you're using Linux + DMD ? Have you 
tried LDC ? It should make those use cases much easier (past the 
initial getting used to it, but you can just `alias dmd = ldmd2`).


 The low number of native libraries is not ideal. Yes, I can use 
 a C library or port it from another language but I've generally 
 got less than two days to work on a project. Any time spent on 
 this is time not spent on actually solving the problem.


Have you tried https://github.com/jacob-carlborg/dstep ? Did you 
encounter any issue ?


 For the same reason I am a huge advocate of battery-included 
 stdlib. I know many are of the opinion of moving as much as 
 possible from Phobos into dub.  For me any library that isn't 
 in dub is one more library I have to evaluate, try, keep track 
 of when they update. It's lost time. Huge projects can have a 
 mindset of "we'll manage our own version anyway" but my 
 projects are written in a few days and are useful a week or two 
 at most. So go Phobos, go! We also need lots of libraries but 
 that is the kind of things that is built upon a strong standard 
 library, not at its expense.


Out of curiosity, if you have used Go extensively, was the 
solution they came up with (Github URL) good enough for you use 
case ?
Jun 29 2020
parent Cym13 <cpicard purrfect.fr> writes:
On Monday, 29 June 2020 at 12:47:00 UTC, Mathias LANG wrote:

 I'm curious, given your use case, how did you feel about  safe 
 by default ?


As explained in another post (twice actually, my mistake), I 
can't be against it as a security professional because code 
safety has real security consequences. But it would make my life 
harder. How much depends on how it would be implemented.


 If I understand correctly, you're using Linux + DMD ? Have you 
 tried LDC ? It should make those use cases much easier (past 
 the initial getting used to it, but you can just `alias dmd = 
 ldmd2`).


I used dmd, ldc and gdc in that order of frequency, on Linux and 
sometimes Windows. I prefer cross-compiling though, I don't like 
the windows workflow but I think it says more about me than D.


 Have you tried https://github.com/jacob-carlborg/dstep ? Did 
 you encounter any issue ?


I've never had a case where dstep proved useful to me. I 
generally have too much tweaking to make afterward. I stopped 
trying, I either write a few signatures manually or use dpp 
(thanks Atila btw).


 Out of curiosity, if you have used Go extensively, was the 
 solution they came up with (Github URL) good enough for you use 
 case ?


I have used Go just enough to know that it's not for me. The 
github url system introduced more security issues than its worth 
IMHO, but I say that from an external point of view so I won't 
comment any further on the topic.
Jun 29 2020
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:

 But first of all, why should you care?


This is a refreshing read that could believe coming right from 
the D blog. Not only that, it also is a piece of information how 
the language really works out in practice.


 You probably shouldn't. I'm not a software developer, my 
 company's business doesn't rely on D in any way, I'll never 
 write a killer app or case study and even if I were to share a 
 library it probably wouldn't be maintained more than a week. 
 I'm not someone that'll bring much value back in the language.


I do remember that you have many times helped people at the Learn 
forum. That already counts as bringing value.


 I'm a security consultant. My job is to find security issues 
 and exploit them. I'm sure most of you know about pentesters 
 yet my job goes a bit beyond common penetration testing. I 
 review websites and networks but also attack electronic 
 devices, perform malware analysis, source code review, 
 cryptographic review, human manipulation, lockpicking... 
 Anything goes.


Cool! If you someday want to write about code security to the D 
blog, I'd likely read it many times over.


 The difference with D is that I can start very scripty, using 
 no explicit type, then adding details in once I have a strong 
 skeleton. I know that style is often dismissed by more 
 industrial users but it's one of the core reasons why I use D.


Huh? I thought that your way is exactly the recommended practice. 
You're essentially doing prototyping before coding the final 
product, only in much smaller scale.


 But I can't very well blame anyone not to make malware 
 development easier and none of the issues I had should impact 
 normal development.


I do consider it a plus for a programming language if it's easy 
to write malware in it. Not only it helps whitehats like you, it 
also teaches regular programmers to think like hackers and thus 
secure their code better.


 I'm just a selfish user minding his own business.


So are we everyone from some perspective. Even if one contributes 
to open-source, there's got to be something one skimps on. Do we 
donate money to good causes? Do we keep our common-interest 
skills up (first aid, swimming, disaster survival etc)? Do we do 
any voluntary job for our hometowns? Do we look after our 
neighbours? For all of thing like these, there are some who can 
answer yes, but no-one contributes for the common good in every 
area of life.


 Then there's the omnipresent negativity of a huge chunk of the 
 community...  it's rough. I used to read the forums daily until 
 I noticed that it stressed me a lot, made me feel angry and sad 
 and that it wasn't the place I wanted to be. Now I mostly keep 
 an eye on Announce.


Understandable. If one is feeling angry, staying out is the the 
correct thing. That way it does not add up to the negativity.


 I hope it stays that way even though I understand why most 
 trends I see on the forum target more "industrial" users (by 
 which I mean working on month or year-long software development 
 projects in a professionnal setting). I have no expectations 
 from that post, but I wonder how many others use D everyday at 
 work in a similar fashion.


Your way of use is IMO just as important as the large-scale way. 
D is officially trying to be a scripting language among it's 
other merits, which means that you're using it just as it's meant 
to be.

And you are not alone. While I do long-term projects, there is 
use for scripting every now and then. I transitioned from Windows 
to Linux an year ago, but I still have not learned to do anything 
complex with Unix scripts. So when there's mass file handling to 
be done, I'm likely to roll a D script. Also I did succesfully 
use the D compiler as a simulator for a school assignment that 
wasn't even intended for programmers.
Jun 29 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jun 29, 2020 at 07:13:23PM +0000, Dukc via Digitalmars-d wrote:

 On Monday, 29 June 2020 at 09:09:14 UTC, Cym13 wrote:


[...]

 Your way of use is IMO just as important as the large-scale way. D is
 officially trying to be a scripting language among it's other merits,
 which means that you're using it just as it's meant to be.


I've found IME that D is very amenable both to scripting-like tasks and
larger scale applications.  In fact, it can easily start out as a
throwaway script that morphs itself over time into something more
permanent.  D has that rare balance between easy enough for scripting
tasks, and powerful enough to tackle larger-scale applications -- and
providing the expressiveness for a pretty smooth to transition from one
to another.



 And you are not alone. While I do long-term projects, there is use for
 scripting every now and then. I transitioned from Windows to Linux an
 year ago, but I still have not learned to do anything complex with
 Unix scripts.  So when there's mass file handling to be done, I'm
 likely to roll a D script. Also I did succesfully use the D compiler
 as a simulator for a school assignment that wasn't even intended for
 programmers.


I consider myself a Linux veteran (I live on the command-line, avoid
GUIs like the plague), and I've to say, except for the simplest of
scripting tasks, I would not use shell scripts. The syntax is full of
inconsistencies and gotchas, and the shell is overly-eager to expand
things leading to Leaning Toothpick Syndrome (you have to escape the
escape character, often many times).

For anything more complex, D's std.process r0x0rs the boat. I highly
recommend it.


T

-- 
One reason that few people are aware there are programs running the internet is
that they never crash in any significant way: the free software underlying the
internet is reliable to the point of invisibility. -- Glyn Moody, from the
article "Giving it all away"
Jun 29 2020
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Monday, 29 June 2020 at 19:39:19 UTC, H. S. Teoh wrote:

 For anything more complex, D's std.process r0x0rs the boat. I 
 highly recommend it.


 T


This is what I needed to remember for the phobos is awesome post. 
std.process and even std.path are absolute perfections.

In college we had some assignments in Python where process pipe 
manipulation was required. This was before std.process and Python 
set the bar high for this. And when it was added, it met those 
expectations.

Today, Python feels like such an old language. I can see through 
all the cruft why people have said it is an easy language. I also 
get why Go has been seen as a python replacement.
Jul 02 2020
prev sibling next sibling parent reply oddp <oddp posteo.de> writes:
 I've tried hard to find a better language than D for my work


Didn't want to derail the forum discussion, thus an off-list message:

What's your take on nim then? Some stuff regarding your post:

- python-esque syntax with d-like performance, lower mem footprint
- also solid type inference story
- semi-realtime gc (and more); all around better than d's gc options
- UFCS
- similar compile-time execution capabilities, hygienic macros
- inline asm statements
- directly include c and cpp headers via pragmas, since nim compiles to c or cpp
- large stdlib; more data structures, parseutils, etc.
   (although nothing as fleshed out as std.algorithm)
- safer defaults, inspired by ada; static verification in the works
- community of similar size and as many third-party libs, it seems

Currently looking at both d and nim myself.
Jun 29 2020
parent Cym13 <cpicard openmailbox.org> writes:
On Monday, 29 June 2020 at 19:28:58 UTC, oddp wrote:

 Didn't want to derail the forum discussion, thus an off-list 
 message:

 What's your take on nim then? Some stuff regarding your post:

 - python-esque syntax with d-like performance, lower mem 
 footprint
 - also solid type inference story
 - semi-realtime gc (and more); all around better than d's gc 
 options
 - UFCS
 - similar compile-time execution capabilities, hygienic macros
 - inline asm statements
 - directly include c and cpp headers via pragmas, since nim 
 compiles to c or cpp
 - large stdlib; more data structures, parseutils, etc.
   (although nothing as fleshed out as std.algorithm)
 - safer defaults, inspired by ada; static verification in the 
 works
 - community of similar size and as many third-party libs, it 
 seems

 Currently looking at both d and nim myself.


I know of Nim but haven't given it a try for the moment so I'll 
reserve my judgement. From what I see though, it's basically D 
with python syntax. I like D, so I'm pretty sure I would like Nim 
too and it's my backup plan if D takes my toys away someday, but 
I don't need another D just for the pythony gimmick (for all the 
love I have of python).

At the moment I just don't see what it brings to the table that 
could benefit me so I'd rather stick with the more mature 
language of the two. Yet, as mentionned, it's not a language I 
have tried thoroughly so take that with a grain of salt.
Jun 29 2020
prev sibling parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2020-06-29 09:09:14 +0000, Cym13 said:


 For the same reason I am a huge advocate of battery-included stdlib. I 
 know many are of the opinion of moving as much as possible from Phobos 
 into dub.  For me any library that isn't in dub is one more library I 
 have to evaluate, try, keep track of when they update. It's lost time.


That's a very important point.

Most companies I know are using a language with batteries included 
(even if it's not optimal), to reduce operational hassles. Minimum but 
powerful libs... External dependencies are the Corona-Virus of software 
development...

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Jun 30 2020