Re: What is the Philosophy of D?
On Wednesday, 25 October 2017 at 18:12:23 UTC, Ola Fosheim Grøstad wrote: Actually, I think D has put way too much emphasis on C compatibility. That's an area where Rust got something right by not trying to be a C superset a priori. Personally, I think D's emphasis on C compatability is one of its primary strengths. C still rules the world, and does so for a good reason. Programmers like the freedom that C provides. Systems programming languages need the freedom that C provides. Many 'new' languages simply wan't to take it away. They just don't get it. The only reason I like D, is because it doesn't focus on jettisoning the freedom of C, but rather offers you ways to do C like stuff, safer and better...and throws in a lot more too...it's not an easy balance to get, but it does it really well. It is essentially the C++ we should have had. The world needs D, much more than it needs Rust.( the writing is already on the wall for Rust .. IMHO). I notice that D is not even listed on stack overflows 2017 'developers most loved languages': https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted It's not because programmers don't like it. They just don't know about it..yet ;-) Once the word really gets out though, it will be D's ecosystem that will decide its path forward...
Re: What is the Philosophy of D?
On Thursday, 19 October 2017 at 13:09:25 UTC, Dukc wrote: Perhaps. Well, contrasted to .Net and JVM standard libraries then? When it comes to imperative languages I certainly think the libraries/frameworks will discourage some programming styles. Some parts of the D standard library also assume that you follow a particular style. Nothing wrong with it. It is different to reason about programs that combine many different styles. In some ways that has been a problem in C++. Libraries being wildly different in style. Which they now try to correct by having central guidelines and narrow down the "idiomatic" styles in the new additions to the C++ standard library… In most regards they are very different, yes. But the similarity is that like C++/D, Forth is designed with many different programming styles in mind, instead of paving way primarily for one certain way of working. Hm, I don't see the connection. Forth was designed to run on an 8-bit CPU, basically providing a simple memory-compact representation for controlling hardware. I think Forth encourages a rather peculiar way of programming, but maybe you are thinking about some modern dialect. Of course D is very close philosophically to C++, that's what gave it the name in the first place! The main difference is that there's no burden of backwards compatibilty with C/C++, and as proven it's enough of difference for many. Actually, I think D has put way too much emphasis on C compatibility. That's an area where Rust got something right by not trying to be a C superset a priori.
Re: What is the Philosophy of D?
Combine C and Java.
Re: What is the Philosophy of D?
On Wednesday, 18 October 2017 at 13:26:52 UTC, Ali wrote:
C#, without the runtime
void main()
{
assert("C#, without the runtime" == "D"); // assertion
failure to stderr
}
Re: What is the Philosophy of D?
On Wednesday, 18 October 2017 at 12:25:57 UTC, Ola Fosheim Grøstad wrote: I don't think C# force you to use object oriented modelling? Clearly the GC and the standard library skews what you end up doing. Perhaps. Well, contrasted to .Net and JVM standard libraries then? Ironically there is a plethora of ways to do the same thing in Python, but I guess the StackOverflow discussions tends to be about what the proper way is. So discussions about idiomatic Python is mostly cultural and not so much the language itself. There is also quite a bit of discussion about what is idiomatic D in these forums. So not all that different. Might be, I have used python hardly at all so can't be sure. C++ and Forth are examples of languages which share that philosophy of D. I don't see how Forth is comparable. Forth is essentially a minimalistic VM. So I think Lisp would be a better pairing for Forth. Both are at the other side of the spectrum of C++/D. In most regards they are very different, yes. But the similarity is that like C++/D, Forth is designed with many different programming styles in mind, instead of paving way primarily for one certain way of working. Probably Lisp too but I know too little of it to confirm. I don't think there is much of a clear philosophy behind D: C++ with GC, a slightly less verbose syntax, minus templating and some other things, then a bit of Java/C#, and finally a slightly different version of templating added. The standard library borrows conceptually from C++ and Python. How is the philosophy different from C++, except the GC which is a library feature in C++? The core language design and the production backend is essentially the same. D doesn't have enough libraries to distinguish itself culturally from the C-family either, so… Of course D is very close philosophically to C++, that's what gave it the name in the first place! The main difference is that there's no burden of backwards compatibilty with C/C++, and as proven it's enough of difference for many.
Re: What is the Philosophy of D?
On Wednesday, 18 October 2017 at 13:26:52 UTC, Ali wrote: On Wednesday, 18 October 2017 at 12:40:07 UTC, Andrea Fontana wrote: On Monday, 16 October 2017 at 21:04:15 UTC, Moritz Maxeiner wrote: "Get it done, but also right" Just D it C#, without the runtime inspired by the post by satoshi's two cents post And without Microsoft, I hope.
Re: What is the Philosophy of D?
On Wednesday, 18 October 2017 at 12:40:07 UTC, Andrea Fontana wrote: On Monday, 16 October 2017 at 21:04:15 UTC, Moritz Maxeiner wrote: "Get it done, but also right" Just D it C#, without the runtime inspired by the post by satoshi's two cents post
Re: What is the Philosophy of D?
On Monday, 16 October 2017 at 13:22:12 UTC, Ali wrote: So if I may ... the current philosophy of D enthusiasts should be "write code, not blogs" Haha... :)
Re: What is the Philosophy of D?
On Monday, 16 October 2017 at 21:04:15 UTC, Moritz Maxeiner wrote: "Get it done, but also right" Just D it
Re: What is the Philosophy of D?
On Tuesday, 17 October 2017 at 09:24:39 UTC, Dukc wrote: This is in contrast to Java and C# which almost force you to use object-oriented styles I don't think C# force you to use object oriented modelling? Clearly the GC and the standard library skews what you end up doing. and Python whose philosophy is "there should be one, and preferably only one clear way to do a thing". Ironically there is a plethora of ways to do the same thing in Python, but I guess the StackOverflow discussions tends to be about what the proper way is. So discussions about idiomatic Python is mostly cultural and not so much the language itself. There is also quite a bit of discussion about what is idiomatic D in these forums. So not all that different. C++ and Forth are examples of languages which share that philosophy of D. I don't see how Forth is comparable. Forth is essentially a minimalistic VM. So I think Lisp would be a better pairing for Forth. Both are at the other side of the spectrum of C++/D. I don't think there is much of a clear philosophy behind D: C++ with GC, a slightly less verbose syntax, minus templating and some other things, then a bit of Java/C#, and finally a slightly different version of templating added. The standard library borrows conceptually from C++ and Python. How is the philosophy different from C++, except the GC which is a library feature in C++? The core language design and the production backend is essentially the same. D doesn't have enough libraries to distinguish itself culturally from the C-family either, so…
Re: What is the Philosophy of D?
On Wednesday, 18 October 2017 at 00:05:06 UTC, codephantom wrote: Again, philosophy != religion. Why do these terms get confused so much? I didn't mean they would be. I think that "D is not a religion" means that whatever philosophy it has it is not cast in stone. Not that it has no philosophy. Like you said, a certain kind of freedom is probably 1# in D philosophy but that does not mean it's the only part. Other thinkgs I could think of for example: -Let the programmer take charge, but make sure he's aware of it when doing so. -In "normal" code, first safety, then correctness, then performance, then expressiveness. Allow the user to shuffle this order but don't encourage it. -Don't strive for absolute minimalism, but aim for, in Alexandrescus words, "power-to-weight-ratio".
Re: What is the Philosophy of D?
On Tuesday, 17 October 2017 at 09:24:39 UTC, Dukc wrote: On Monday, 16 October 2017 at 00:25:32 UTC, codephantom wrote: Is philosophy not important? I think that if somebody wants to nail down a philosophy for D, the main page puts it well: "The best paradigm is to not impose something at the expense of others". I also heard that long ago there was a phrase "D is not a religion". I wasn't myself here then but it still describes D alot. Well, I quess other phrases could also be included it, like "ultimate performance must be attainable, but if the way for it is otherwise undesirable it should be explicit" but the point is that D tries to let you to program in any style it technically can. With that "technically can" I mean that it does not support logic programming for example because it would require too great a rework on implementation and language spec. This is in contrast to Java and C# which almost force you to use object-oriented styles, and Python whose philosophy is "there should be one, and preferably only one clear way to do a thing". C++ and Forth are examples of languages which share that philosophy of D. Again, philosophy != religion. Why do these terms get confused so much? One tries to make sense of things using 'reason', the other does not (i.e religion is based on faith - which you can't reason about). Religion can be imposed, philosophy cannot be imposed - because one is always free to reason about it. The philosophy of unix is to have a minimalist, modular approach to software development (even if that's not always the case - because it can't be imposed). The philosophy of C is that the programmer knows best (even if that's not always the case - because it can't be imposed). GPL is more a religion that a philosophy - because it seeks to always impose (oopsshould I have said that...) The D language certainly does *not* have a religion, but it does have a philosophywhether it knows it or not... In my efforts trying to 'make sense' of the D language, I can't help but think that its philosophy almost certainly incorporates the concept of: "freedom ~ for programmers". Hey...perhaps that's it! (even if that's not always the case - because it can't be imposed).
Re: What is the Philosophy of D?
On Monday, 16 October 2017 at 00:25:32 UTC, codephantom wrote: Is philosophy not important? I think that if somebody wants to nail down a philosophy for D, the main page puts it well: "The best paradigm is to not impose something at the expense of others". I also heard that long ago there was a phrase "D is not a religion". I wasn't myself here then but it still describes D alot. Well, I quess other phrases could also be included it, like "ultimate performance must be attainable, but if the way for it is otherwise undesirable it should be explicit" but the point is that D tries to let you to program in any style it technically can. With that "technically can" I mean that it does not support logic programming for example because it would require too great a rework on implementation and language spec. This is in contrast to Java and C# which almost force you to use object-oriented styles, and Python whose philosophy is "there should be one, and preferably only one clear way to do a thing". C++ and Forth are examples of languages which share that philosophy of D.
Re: What is the Philosophy of D?
codephantom wrote: I take it from your story, that one could say the philosophy of D, is: 'Do it your way'. and "have fun" too. this is important.
Re: What is the Philosophy of D?
On Monday, 16 October 2017 at 13:56:34 UTC, skymuse wrote: ...Let me tell you why I choose D. D gave me the freedom to code the way I wanted to, Go forced me to think "simply". D gave me every feature possible to solve my problem, Go took them away. D allowed me to program in a style that matched the problem at hand, Go forced me to follow only one style. Are you seeing the pattern? When you religiously follow a philosophy, you're limited to only solving problems that play well with that philosophy. Don't confuse religion and philosophy. One is a dynamic const, the other is purely dynamic ;-) I take it from your story, that one could say the philosophy of D, is: 'Do it your way'. That sounds like a great philosophy! And it certainly fits with my understanding of the capabilities of D, and perhaps is indicative of the spirit in which D came about ;-)
Re: What is the Philosophy of D?
On Monday, 16 October 2017 at 00:25:32 UTC, codephantom wrote: D's overview page says "It doesn't come with an overriding philosophy." Is philosophy not important? I'd like to argue, that the problem of focusing on getting the job done quickly and reliably, does *not* leave behind maintainable, easy to understand code, but rather it leads to unintended outcomes ... If the philosophy of C, is 'the programmer is in charge', what might the philosophy of D be? e.g. Maximum precision in expression, perhaps? "Get it done, but also right"
Re: What is the Philosophy of D?
On Monday, 16 October 2017 at 00:25:32 UTC, codephantom wrote: D's overview page says "It doesn't come with an overriding philosophy." Is philosophy not important? I'd like to argue, that the problem of focusing on getting the job done quickly and reliably, does *not* leave behind maintainable, easy to understand code, but rather it leads to unintended outcomes ... If the philosophy of C, is 'the programmer is in charge', what might the philosophy of D be? e.g. Maximum precision in expression, perhaps? I believe D not having a philosophy was very important when I ported all my projects from python to D. Let me explain. I had a very important project that I've been using everyday for two-three years, written in python, and I grew tired of the negative effects of interpreted languages. I needed to take a risk and perform a complete rewrite to counter the issues. My new language needed to excel in the following categories for the rewrite to be successful: performance, testing, and learning curve. The candidates were Rust, Go, Haskell, Swift, and of course D. Rust had a difficult learning curve and it was not easy to port Python code to Rust, therefore that language was ignored. Haskell stuck to the philosophy of a purely functional language, which made the learning curve dramatic and I had to ignore this language. Swift seemed to be focus more on cocoa apps over command line apps, so I ignored this language as well. This left me with Go and D, both languages that solved my requirements. Let me tell you why I choose D. D gave me the freedom to code the way I wanted to, Go forced me to think "simply". D gave me every feature possible to solve my problem, Go took them away. D allowed me to program in a style that matched the problem at hand, Go forced me to follow only one style. Are you seeing the pattern? When you religiously follow a philosophy, you're limited to only solving problems that play well with that philosophy.
Re: What is the Philosophy of D?
On Monday, 16 October 2017 at 00:25:32 UTC, codephantom wrote: D's overview page says "It doesn't come with an overriding philosophy." Then this is exactly, its philosophy Some of the nicer comments I read about D, and one reason why it still stand a chance against other more hyped language such as Rust ... is that D doesn't force any style of programming on you, I understand that some people, like to keep an eye or have a view, of the strategic (long term) advantages of a language , and there is nothing really wrong with that But, D ... isn't missing any long term vision, it has many, and its makers are lacking in the vision department... D just need developers to take advantages of it, on the short term ... to use it now So if I may ... the current philosophy of D enthusiasts should be "write code, not blogs"
Re: What is the Philosophy of D?
On Monday, 16 October 2017 at 00:25:32 UTC, codephantom wrote: D's overview page says "It doesn't come with an overriding philosophy." Is philosophy not important? I'd like to argue, that the problem of focusing on getting the job done quickly and reliably, does *not* leave behind maintainable, easy to understand code, but rather it leads to unintended outcomes ... If the philosophy of C, is 'the programmer is in charge', what might the philosophy of D be? e.g. Maximum precision in expression, perhaps? The frontpage says "It combines efficiency, control and modeling power with safety and programmer productivity." The three big words are: Convenience, Power, Efficiency. What are the "philosophies" we are talking about? Probably the usual paradigms, like object-oriented, functional, etc. D supports them, but none of them is overriding or dominant. Maximum safety is another philosophy. D allows you to enhance safety (@safe) or diminish it (inline assembly).
Re: What is the Philosophy of D?
On Monday, 16 October 2017 at 00:25:32 UTC, codephantom wrote: D's overview page says "It doesn't come with an overriding philosophy." Is philosophy not important? I'd like to argue, that the problem of focusing on getting the job done quickly and reliably, does *not* leave behind maintainable, easy to understand code, but rather it leads to unintended outcomes ... If the philosophy of C, is 'the programmer is in charge', what might the philosophy of D be? e.g. Maximum precision in expression, perhaps? It's not very catchy, but I would say "Genercity, productivity and performance all at once".
Re: What is the Philosophy of D?
codephantom wrote: If the philosophy of C, is 'the programmer is in charge', what might the philosophy of D be? fast. safe. reliable. choose any three of 'em.
What is the Philosophy of D?
D's overview page says "It doesn't come with an overriding philosophy." Is philosophy not important? I'd like to argue, that the problem of focusing on getting the job done quickly and reliably, does *not* leave behind maintainable, easy to understand code, but rather it leads to unintended outcomes ... If the philosophy of C, is 'the programmer is in charge', what might the philosophy of D be? e.g. Maximum precision in expression, perhaps?
