I constantly feel like inferior languages are picked up, while superior languages are discarded. It's almost as if the universe had a law: "inferior technology is always preferred no matter how hard you seethe". Examples: * Python preferred over Ruby * TypeScript preferred over Dart or even JavaScript (which is fine and, as a bonus, doesn't require compilation step like TS) * Go is preferred over Crystal and D. While…
Programming in D: Tutorial and Reference
51–60 of 134 posts
Re: Programming in D: Tutorial and Reference
#52Earlier quoted context omitted.
> Python preferred over Ruby ... Perhaps what you're describing is having a niche opinion. If you had some opinions, like a preference for "Everything must be done in as many ways as possible with funky characters" or "I hate indentation", it would certainly seem that the world is against you. But, perhaps, you just really smart and can remember the intention of all the complicated code you wrote a year ago, so you d…
> "Everything must be done in as many ways as possible with funky characters" Are you sure you're not talking about Perl here? Because there are very few "funky characters" in Ruby and code written in it tends to be very readable, more so than Python in many cases. I agree with OP. While Python is not a bad language, Ruby is a better language in general, and I'm reminded of it every time I have to work in Python (whi…
Re: Programming in D: Tutorial and Reference
#53I constantly feel like inferior languages are picked up, while superior languages are discarded. It's almost as if the universe had a law: "inferior technology is always preferred no matter how hard you seethe". Examples: * Python preferred over Ruby * TypeScript preferred over Dart or even JavaScript (which is fine and, as a bonus, doesn't require compilation step like TS) * Go is preferred over Crystal and D. While…
Also all languages you mentioned support complex code and OOP.
Re: Programming in D: Tutorial and Reference
#54Earlier quoted context omitted.
> "Everything must be done in as many ways as possible with funky characters" Are you sure you're not talking about Perl here? Because there are very few "funky characters" in Ruby and code written in it tends to be very readable, more so than Python in many cases. I agree with OP. While Python is not a bad language, Ruby is a better language in general, and I'm reminded of it every time I have to work in Python (whi…
To a beginner who is used to ordinary imperative languages, that Ruby line is extremely difficult to understand. Is `.filter` a method or a property of `xs`? Is `{ |x| x.odd? }` an argument to a method or just a statement that comes after `xs.filter`? If it is passed to `.filter`, why does it not have parentheses around it but the `", "` passed to `join` does? This all makes sense to a person who knows the language a…
xs.filter(x => x & 1).sort().join(", ") // JavaScript
xs & filter odd & sort & map show & intercalate ", " -- Haskell
Python seems to be the odd one out. Imo, its list comprehensions are confusing as hell to "newcomers". For example, when a list comprehension has multiple `for`s, what order are they nested in?Re: Programming in D: Tutorial and Reference
#55Earlier quoted context omitted.
The only difficulty in Ruby code is the block notation. Even then, it is very similar to constructs in JavaScript, Go, D and a number of other languages -- the only difference form JS would be that instead of `(x) => ...` you write `{ |x| ... }`. Questions such as > why does it not have parentheses around it but the `", "` passed to `join` does? would be exactly the same for JavaScript, Go or D. Ruby has the best syn…
I don't know much Ruby outside of a few toy examples I wrote a long time ago. For most languages, there would be parentheses around objects you pass to functions, like `.filter({|x| x.odd? })`. This lends some consistency and makes it easy (for me at least) to understand that an anonymous function is passed to `filter`. Just separating it using spaces feels like Bash, something I find difficult to write anything slig…
Re: Programming in D: Tutorial and Reference
#56Slightly off topic: Is D a good language for creating tiny windows or Linux executables? There is an upcoming game jam (4mb jam 2025) which gives extra points for game submissions 0: https://gist.github.com/ske2004/336d8cce8cd9db59d61ceb13c1ed...
Yes. Just use the “better C” mode
Re: Programming in D: Tutorial and Reference
#57I constantly feel like inferior languages are picked up, while superior languages are discarded. It's almost as if the universe had a law: "inferior technology is always preferred no matter how hard you seethe". Examples: * Python preferred over Ruby * TypeScript preferred over Dart or even JavaScript (which is fine and, as a bonus, doesn't require compilation step like TS) * Go is preferred over Crystal and D. While…
Re: Programming in D: Tutorial and Reference
#58Earlier quoted context omitted.
Mike Shah has been using D for teaching software engineering at Northeastern University and Yale. Here is his DLang playlist: https://www.youtube.com/playlist?list=PLvv0ScY6vfd9Fso-3cB4C...
We have also been using D for computer graphics and game programming as of this year! :D
Re: Programming in D: Tutorial and Reference
#59Earlier quoted context omitted.
I don't know much Ruby outside of a few toy examples I wrote a long time ago. For most languages, there would be parentheses around objects you pass to functions, like `.filter({|x| x.odd? })`. This lends some consistency and makes it easy (for me at least) to understand that an anonymous function is passed to `filter`. Just separating it using spaces feels like Bash, something I find difficult to write anything slig…
Lua, Haskell, ML, plenty of other languages where one-argument functions don't need parentheses. I think it makes a lot of code more readable.
Re: Programming in D: Tutorial and Reference
#60Earlier quoted context omitted.
Lua, Haskell, ML, plenty of other languages where one-argument functions don't need parentheses. I think it makes a lot of code more readable.
All not-exactly-popular languages.