Re: A reason to choose D over Go
On Friday, 27 March 2015 at 14:21:18 UTC, Shammah Chancellor wrote: D is a superset of go's functionality aside from the structural typing (which in my opinion is a huge fail for a variety of reasons you will see if you try to use it for anything extensive). If you don't want to learn about templates and metaprogramming, then don't. I fail to understand why having extra features is a deterrant? -Shammah That's what I thought for a long time, and I still think that it is a valid approach, but it should be noted that more features makes reading and understanding other's code more difficult. 1/ if you don't know templates, then reading a code making use of it needs a long time to identify the construct, read about it, understand it and then apply this new knowledge to the original piece of code. The identification part is important, how often when learning a language did you found a weird syntax that you just could'nt identify because it was generic enough not to get any useful results in a web search? 2/ more paradigms allow people to write different solutions for a same problem. Of course, that's the whole point of accepting different paradigms, but it makes it difficult to have a uniformed programming style. If you take a language that emphasis having one good, elegant, performant way to do things (like python) then the code I write will be very similar to the code you would have written. Of course there are divergences but there is one style that is said to be good and sticking to it means that nobody will have problem understanding what I'm writting. A language that famously took the other path and decided that it should allow programmers to solve the same problem in as many ways as possible is perl. And if perl is often praised for its expressiveness, it is disturbing to see that even perlers are often having a hard time deciphering other's code.
Re: A reason to choose D over Go
I was recently told by a commercial D user, that using D helps them to more easily identify good programmers. It would be nice, if not just D users had this attitude :-) It's also a bit like that for Scala when companies look for Java people. Alas, Scala is a bit overloaded ...
Re: A reason to choose D over Go
On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote: On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote: On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. I agree, at some point I learned that there is a huge cultural distinction between C and C++ programmers. yes, the other main distinction are the people who correctly put the * next to the type because it's part of the type, or the wrong people who put it next to the variable name because they're heathens +1
Re: A reason to choose D over Go
On 2015-03-27 19:27:37 +, Martin Nowak said: On Friday, 27 March 2015 at 19:00:16 UTC, Chris wrote: Also, and this counts for something I think, Go is a trendy language right now, so when it comes to recruiting, I think having Go as a critical part of Repustate’s tech stack will help. Stop the world, I wanna get out! I was recently told by a commercial D user, that using D helps them to more easily identify good programmers. Every programmer I know who was worth their salt was at least interested in D. -S.
Re: A reason to choose D over Go
On 2015-03-25 10:17:00 +, Bienlein said: I recently made a pull request for a go tool and spent about half an hour trying to find some function to test whether an array contains a particular element. There are libraries for this like gen: http://clipperhouse.github.io/gen. But it also suffers from the absence of generics. trust me, from an undecided but experienced developer's perspective there are so many reasons to choose D over Go. on the otherhand same person has a lot more reasons to choose Go over D. I earn my pay with Java development. In my spare time I learn some Scala hoping there might be some work for me with Scala in the future. Then I need to become familiar with all kinds of new frameworks, tools, libraries and systems that continue to pop up every year in the JVM eco system. In the end there is not much time left for playing with a systems language. As Go is very effortless it could be a good compromise here. I have thrown it away and refetched it due to lack of alternatives several times. I would like to play with D, but it has as step a learning curve as Scala. If you don't have a background in C or C++ the learning curve is even steeper. So it depends a lot from where you are coming. i'm writing a very long blog post about this. if anyone's interested, i can happily share the draft with them. Please drop a comment in this thread or somewhere when it is published. Cheers, Bienlein D is a superset of go's functionality aside from the structural typing (which in my opinion is a huge fail for a variety of reasons you will see if you try to use it for anything extensive). If you don't want to learn about templates and metaprogramming, then don't. I fail to understand why having extra features is a deterrant? -Shammah
Re: A reason to choose D over Go
On Wednesday, 25 March 2015 at 15:36:16 UTC, Idan Arye wrote: On Wednesday, 25 March 2015 at 10:17:01 UTC, Bienlein wrote: I recently made a pull request for a go tool and spent about half an hour trying to find some function to test whether an array contains a particular element. There are libraries for this like gen: http://clipperhouse.github.io/gen. But it also suffers from the absence of generics. trust me, from an undecided but experienced developer's perspective there are so many reasons to choose D over Go. on the otherhand same person has a lot more reasons to choose Go over D. I earn my pay with Java development. In my spare time I learn some Scala hoping there might be some work for me with Scala in the future. Then I need to become familiar with all kinds of new frameworks, tools, libraries and systems that continue to pop up every year in the JVM eco system. In the end there is not much time left for playing with a systems language. As Go is very effortless it could be a good compromise here. I have thrown it away and refetched it due to lack of alternatives several times. I would like to play with D, but it has as step a learning curve as Scala. If you don't have a background in C or C++ the learning curve is even steeper. So it depends a lot from where you are coming. My case is the opposite - Go's easy learning curve is the exact thing that drove me away from it. While Go's simplicity makes it easy to learn - it also makes it uninteresting to learn. I like to learn new languages that introduce interesting concepts, because interesting concepts are interesting, and because they can change the way you program even in languages that don't support them directly. I'm currently trying to learn Rust, and while it's far from trivial to wrap your mind around it's concept of ownership, I feel that once I do it I can emerge a better programmer - so learning Rust will benefit me even if I never use Rust in actual projects. Go, on the other hand, doesn't introduce any interesting concepts(more-elegant-C is far from being interesting). I don't care for just learning another set of syntax and another standard library - that knowledge won't have any effect on the way I'm thinking. As long as I don't have a specific project I need to use Go for - learning it is just a waste of time. True. D has changed my way of thinking in other languages too. I sometimes find myself implementing (at least trying to) D concepts in other languages. Go doesn't seem worth the trouble. Also, if it's so primitive and easy to learn, you don't need to bother learning it, you can just dip in when you need it for some reason.
Re: A reason to choose D over Go
On Friday, 27 March 2015 at 19:00:16 UTC, Chris wrote: Also, and this counts for something I think, Go is a trendy language right now, so when it comes to recruiting, I think having Go as a critical part of Repustate’s tech stack will help. Stop the world, I wanna get out! I was recently told by a commercial D user, that using D helps them to more easily identify good programmers.
Re: A reason to choose D over Go
On Friday, 27 March 2015 at 19:27:38 UTC, Martin Nowak wrote: On Friday, 27 March 2015 at 19:00:16 UTC, Chris wrote: Also, and this counts for something I think, Go is a trendy language right now, so when it comes to recruiting, I think having Go as a critical part of Repustate’s tech stack will help. Stop the world, I wanna get out! I was recently told by a commercial D user, that using D helps them to more easily identify good programmers. It would be nice, if not just D users had this attitude :-)
Re: A reason to choose D over Go
On Saturday, 21 March 2015 at 22:16:10 UTC, Martin Nowak wrote: This blog post describes what to consider when switching from python to go. http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/#tips It's very interesting, because the long list of things to give up for more efficient go code reads like an argumentation against choosing go from a D perspective. And given that D is on par with Python's expressiveness, we should really emphasize this aspect. I recently made a pull request for a go tool and spent about half an hour trying to find some function to test whether an array contains a particular element. I also asked on #go-nuts to confirm I didn't miss anything, but you're really supposed to write an explicit loop. https://github.com/buger/gor/pull/149/files#diff-b8b346beabeabdf0fca6f0b6893ce82bR42 That's what you would write in other languages. ```py if chunked in request.transfer_encodings: return ``` ```ruby return if request.transfer_encodings.include? 'chunked' ``` ```d if (request.transferEncodings.canFind(chunked)) return; ``` ```c++ const auto arr = request.transfer_encodings; if (find(arr.begin(), arr.end(), string(chunked)) != arr.end()) return; ``` There exists some functionality for sorted arrays (only int, float, and string), but that isn't applicable here. http://golang.org/pkg/sort/ While go will hardly ever have good support for algorithms, because of the lack of overloads and generics, they also choose against adding such trivial, but often needed, algorithms to the basic types. With a functional programming (or C++ algo) background, I find this very hard to get used to. Repeatedly writing out such trivial code often mixes different levels of abstraction and is one of the reasons why go code is so noisy, manual error code handling being another one. So it's basically like JavaScript? You have to re-invent the wheel over and over again. From the blog post: Also, and this counts for something I think, Go is a trendy language right now, so when it comes to recruiting, I think having Go as a critical part of Repustate’s tech stack will help. Stop the world, I wanna get out!
Re: A reason to choose D over Go
On Saturday, 21 March 2015 at 23:14:58 UTC, Ola Fosheim Grøstad
wrote:
This is a funny workaround:
http://bouk.co/blog/idiomatic-generics-in-go/
And someone found a hole to implement it:
https://www.reddit.com/r/golang/comments/2hw356/idiomatic_generics_in_go/ckwpfms
The interpretation of the ImportPath is implementation-dependent
but it is typically a substring of the full file name of the
compiled package and may be relative to a repository of installed
packages. -- Go Spec
import (
templates.Map{int, string}
)
Hahahaha.
Re: A reason to choose D over Go
On Thursday, 26 March 2015 at 18:33:17 UTC, Jesse Phillips wrote:
import (
templates.Map{int, string}
)
Hahahaha.
It is crazy stuff like that that makes fringe languages more fun
to read about than the big serious ones. ;)
Re: A reason to choose D over Go
I recently made a pull request for a go tool and spent about half an hour trying to find some function to test whether an array contains a particular element. There are libraries for this like gen: http://clipperhouse.github.io/gen. But it also suffers from the absence of generics. trust me, from an undecided but experienced developer's perspective there are so many reasons to choose D over Go. on the otherhand same person has a lot more reasons to choose Go over D. I earn my pay with Java development. In my spare time I learn some Scala hoping there might be some work for me with Scala in the future. Then I need to become familiar with all kinds of new frameworks, tools, libraries and systems that continue to pop up every year in the JVM eco system. In the end there is not much time left for playing with a systems language. As Go is very effortless it could be a good compromise here. I have thrown it away and refetched it due to lack of alternatives several times. I would like to play with D, but it has as step a learning curve as Scala. If you don't have a background in C or C++ the learning curve is even steeper. So it depends a lot from where you are coming. i'm writing a very long blog post about this. if anyone's interested, i can happily share the draft with them. Please drop a comment in this thread or somewhere when it is published. Cheers, Bienlein
Re: A reason to choose D over Go
On Wednesday, 25 March 2015 at 10:17:01 UTC, Bienlein wrote: I recently made a pull request for a go tool and spent about half an hour trying to find some function to test whether an array contains a particular element. There are libraries for this like gen: http://clipperhouse.github.io/gen. But it also suffers from the absence of generics. trust me, from an undecided but experienced developer's perspective there are so many reasons to choose D over Go. on the otherhand same person has a lot more reasons to choose Go over D. I earn my pay with Java development. In my spare time I learn some Scala hoping there might be some work for me with Scala in the future. Then I need to become familiar with all kinds of new frameworks, tools, libraries and systems that continue to pop up every year in the JVM eco system. In the end there is not much time left for playing with a systems language. As Go is very effortless it could be a good compromise here. I have thrown it away and refetched it due to lack of alternatives several times. I would like to play with D, but it has as step a learning curve as Scala. If you don't have a background in C or C++ the learning curve is even steeper. So it depends a lot from where you are coming. My case is the opposite - Go's easy learning curve is the exact thing that drove me away from it. While Go's simplicity makes it easy to learn - it also makes it uninteresting to learn. I like to learn new languages that introduce interesting concepts, because interesting concepts are interesting, and because they can change the way you program even in languages that don't support them directly. I'm currently trying to learn Rust, and while it's far from trivial to wrap your mind around it's concept of ownership, I feel that once I do it I can emerge a better programmer - so learning Rust will benefit me even if I never use Rust in actual projects. Go, on the other hand, doesn't introduce any interesting concepts(more-elegant-C is far from being interesting). I don't care for just learning another set of syntax and another standard library - that knowledge won't have any effect on the way I'm thinking. As long as I don't have a specific project I need to use Go for - learning it is just a waste of time.
Re: A reason to choose D over Go
I earn my pay with Java development. In my spare time I learn some Scala hoping there might be some work for me with Scala in the future. Then I need to become familiar with all kinds of new frameworks, tools, libraries and systems that continue to pop up every year in the JVM eco system. In the end there is not much time left for playing with a systems language. As Go is very effortless it could be a good compromise here. I have thrown it away and refetched it due to lack of alternatives several times. I would like to play with D, but it has as step a learning curve as Scala. If you don't have a background in C or C++ the learning curve is even steeper. So it depends a lot from where you are coming. I have never used Scala, never written in C++, and haven't done much C programming in about twenty years (and only occasional VBA for Excel programming in between). I don't learn as quickly today as when a child. But I was able to learn enough D to be productive in my domain in a few months, and found it easier to learn than Python. So I haven't personally found the learning curve to be steep in the sense of learning enough to be reasonably productive. The metaprogramming perhaps, but you can do a lot without being a ninja there if your orientation is just being able to solve the problems you have in a small to medium project. Laeeth
Re: A reason to choose D over Go
On Wednesday, 25 March 2015 at 17:21:43 UTC, Laeeth Isharc wrote: I earn my pay with Java development. In my spare time I learn some Scala hoping there might be some work for me with Scala in the future. Then I need to become familiar with all kinds of new frameworks, tools, libraries and systems that continue to pop up every year in the JVM eco system. In the end there is not much time left for playing with a systems language. As Go is very effortless it could be a good compromise here. I have thrown it away and refetched it due to lack of alternatives several times. I would like to play with D, but it has as step a learning curve as Scala. If you don't have a background in C or C++ the learning curve is even steeper. So it depends a lot from where you are coming. I have never used Scala, never written in C++, and haven't done much C programming in about twenty years (and only occasional VBA for Excel programming in between). I don't learn as quickly today as when a child. But I was able to learn enough D to be productive in my domain in a few months, and found it easier to learn than Python. So I haven't personally found the learning curve to be steep in the sense of learning enough to be reasonably productive. The metaprogramming perhaps, but you can do a lot without being a ninja there if your orientation is just being able to solve the problems you have in a small to medium project. Laeeth There is something about languages that is very personal, though. D just seemed right aesthetically. One is going to find it easier to become an expert on a composer - say Beethoven, if he speaks to something in your soul, than if you simply can't stand his music. (And there are many gradations in between). It is an unfashionable perspective, but I think this is true of programmimg languages too. People have different aesthetic and emotional organisations, and the appeal of different languages will not be the same to every person, holding ability constant.
Re: A reason to choose D over Go
On Sunday, 22 March 2015 at 20:35:31 UTC, Mengu wrote: trust me, from an undecided but experienced developer's perspective there are so many reasons to choose D over Go. on the otherhand same person has a lot more reasons to choose Go over D. i'm writing a very long blog post about this. if anyone's interested, i can happily share the draft with them. Pretty interested in that, please shot me a mail.
Re: A reason to choose D over Go
On Sunday, March 22, 2015 02:32:36 deadalnix via Digitalmars-d wrote: On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote: On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote: On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. I agree, at some point I learned that there is a huge cultural distinction between C and C++ programmers. yes, the other main distinction are the people who correctly put the * next to the type because it's part of the type, or the wrong people who put it next to the variable name because they're heathens What is the type of b here ? int* a, b; Which is one reason never to declare multiple variables on the same line in C/C++. I never understood why C/C++ made it so that the * went with the variable rather than being treated like part of the type, since in reality, the * is part of the type. I'm definitely glad that D fixed that and made it so that the a and b in your example are both pointers. But much as I hate it when folks put the * next to the variable name in C/C++ instead of putting it with the rest of the type, your example shows exactly why many people put it with the variable name. - Jonathan M Davis
Re: A reason to choose D over Go
On Saturday, 21 March 2015 at 22:16:10 UTC, Martin Nowak wrote: This blog post describes what to consider when switching from python to go. http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/#tips It's very interesting, because the long list of things to give up for more efficient go code reads like an argumentation against choosing go from a D perspective. And given that D is on par with Python's expressiveness, we should really emphasize this aspect. I recently made a pull request for a go tool and spent about half an hour trying to find some function to test whether an array contains a particular element. I also asked on #go-nuts to confirm I didn't miss anything, but you're really supposed to write an explicit loop. https://github.com/buger/gor/pull/149/files#diff-b8b346beabeabdf0fca6f0b6893ce82bR42 That's what you would write in other languages. ```py if chunked in request.transfer_encodings: return ``` ```ruby return if request.transfer_encodings.include? 'chunked' ``` ```d if (request.transferEncodings.canFind(chunked)) return; ``` ```c++ const auto arr = request.transfer_encodings; if (find(arr.begin(), arr.end(), string(chunked)) != arr.end()) return; ``` There exists some functionality for sorted arrays (only int, float, and string), but that isn't applicable here. http://golang.org/pkg/sort/ While go will hardly ever have good support for algorithms, because of the lack of overloads and generics, they also choose against adding such trivial, but often needed, algorithms to the basic types. With a functional programming (or C++ algo) background, I find this very hard to get used to. Repeatedly writing out such trivial code often mixes different levels of abstraction and is one of the reasons why go code is so noisy, manual error code handling being another one. trust me, from an undecided but experienced developer's perspective there are so many reasons to choose D over Go. on the otherhand same person has a lot more reasons to choose Go over D. i'm writing a very long blog post about this. if anyone's interested, i can happily share the draft with them.
Re: A reason to choose D over Go
weaselcat weasel...@gmail.com wrote: On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote: On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. I agree, at some point I learned that there is a huge cultural distinction between C and C++ programmers. yes, the other main distinction are the people who correctly put the * next to the type because it's part of the type, or the wrong people who put it next to the variable name because they're heathens One could argue that in the declaration: int *a; the type of *a is int. So it's not a pointer type but a dereference operator. That actually similar to how patterns work in modern programming languages. Tobi
Re: A reason to choose D over Go
This is a funny workaround: http://bouk.co/blog/idiomatic-generics-in-go/
A reason to choose D over Go
This blog post describes what to consider when switching from python to go. http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/#tips It's very interesting, because the long list of things to give up for more efficient go code reads like an argumentation against choosing go from a D perspective. And given that D is on par with Python's expressiveness, we should really emphasize this aspect. I recently made a pull request for a go tool and spent about half an hour trying to find some function to test whether an array contains a particular element. I also asked on #go-nuts to confirm I didn't miss anything, but you're really supposed to write an explicit loop. https://github.com/buger/gor/pull/149/files#diff-b8b346beabeabdf0fca6f0b6893ce82bR42 That's what you would write in other languages. ```py if chunked in request.transfer_encodings: return ``` ```ruby return if request.transfer_encodings.include? 'chunked' ``` ```d if (request.transferEncodings.canFind(chunked)) return; ``` ```c++ const auto arr = request.transfer_encodings; if (find(arr.begin(), arr.end(), string(chunked)) != arr.end()) return; ``` There exists some functionality for sorted arrays (only int, float, and string), but that isn't applicable here. http://golang.org/pkg/sort/ While go will hardly ever have good support for algorithms, because of the lack of overloads and generics, they also choose against adding such trivial, but often needed, algorithms to the basic types. With a functional programming (or C++ algo) background, I find this very hard to get used to. Repeatedly writing out such trivial code often mixes different levels of abstraction and is one of the reasons why go code is so noisy, manual error code handling being another one.
Re: A reason to choose D over Go
The moment I realised that Go requires you to write loops was the moment I decided we were done. I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. On Saturday, 21 March 2015 at 22:16:10 UTC, Martin Nowak wrote: This blog post describes what to consider when switching from python to go. http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/#tips It's very interesting, because the long list of things to give up for more efficient go code reads like an argumentation against choosing go from a D perspective. And given that D is on par with Python's expressiveness, we should really emphasize this aspect. I recently made a pull request for a go tool and spent about half an hour trying to find some function to test whether an array contains a particular element. I also asked on #go-nuts to confirm I didn't miss anything, but you're really supposed to write an explicit loop. https://github.com/buger/gor/pull/149/files#diff-b8b346beabeabdf0fca6f0b6893ce82bR42 That's what you would write in other languages. ```py if chunked in request.transfer_encodings: return ``` ```ruby return if request.transfer_encodings.include? 'chunked' ``` ```d if (request.transferEncodings.canFind(chunked)) return; ``` ```c++ const auto arr = request.transfer_encodings; if (find(arr.begin(), arr.end(), string(chunked)) != arr.end()) return; ``` There exists some functionality for sorted arrays (only int, float, and string), but that isn't applicable here. http://golang.org/pkg/sort/ While go will hardly ever have good support for algorithms, because of the lack of overloads and generics, they also choose against adding such trivial, but often needed, algorithms to the basic types. With a functional programming (or C++ algo) background, I find this very hard to get used to. Repeatedly writing out such trivial code often mixes different levels of abstraction and is one of the reasons why go code is so noisy, manual error code handling being another one.
Re: A reason to choose D over Go
On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote: On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. I agree, at some point I learned that there is a huge cultural distinction between C and C++ programmers. yes, the other main distinction are the people who correctly put the * next to the type because it's part of the type, or the wrong people who put it next to the variable name because they're heathens
Re: A reason to choose D over Go
On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. I agree, at some point I learned that there is a huge cultural distinction between C and C++ programmers.
Re: A reason to choose D over Go
On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote: On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote: On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. I agree, at some point I learned that there is a huge cultural distinction between C and C++ programmers. yes, the other main distinction are the people who correctly put the * next to the type because it's part of the type, or the wrong people who put it next to the variable name because they're heathens What is the type of b here ? int* a, b;
Re: A reason to choose D over Go
On Sunday, 22 March 2015 at 02:32:38 UTC, deadalnix wrote: On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote: On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote: On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. I agree, at some point I learned that there is a huge cultural distinction between C and C++ programmers. yes, the other main distinction are the people who correctly put the * next to the type because it's part of the type, or the wrong people who put it next to the variable name because they're heathens What is the type of b here ? int* a, b; int* because I don't use a language that's ruined by C baggage.
Re: A reason to choose D over Go
On Sunday, 22 March 2015 at 02:36:03 UTC, weaselcat wrote: On Sunday, 22 March 2015 at 02:32:38 UTC, deadalnix wrote: On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote: On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote: On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. I agree, at some point I learned that there is a huge cultural distinction between C and C++ programmers. yes, the other main distinction are the people who correctly put the * next to the type because it's part of the type, or the wrong people who put it next to the variable name because they're heathens What is the type of b here ? int* a, b; int* because I don't use a language that's ruined by C baggage. You answer a comment about, quoting C and C++ programmers. If you don't understand what you are answering to, you probably shouldn't.
Re: A reason to choose D over Go
On Sunday, 22 March 2015 at 04:53:06 UTC, deadalnix wrote: On Sunday, 22 March 2015 at 02:36:03 UTC, weaselcat wrote: On Sunday, 22 March 2015 at 02:32:38 UTC, deadalnix wrote: On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote: On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote: On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. I agree, at some point I learned that there is a huge cultural distinction between C and C++ programmers. yes, the other main distinction are the people who correctly put the * next to the type because it's part of the type, or the wrong people who put it next to the variable name because they're heathens What is the type of b here ? int* a, b; int* because I don't use a language that's ruined by C baggage. You answer a comment about, quoting C and C++ programmers. If you don't understand what you are answering to, you probably shouldn't. yes, and I answered it with respect to D programmers. the correct answer for C++ is: if you submit that as a PR, I'm going to hit you.
