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
101–110 of 134 posts
Re: Programming in D: Tutorial and Reference
#102Earlier quoted context omitted.
What pains me in Python adoption, beyond its use as Perl replacement, is that we have so much better dynamic languages with advanced JIT implementations, but have to reach out writing extensions in native languages instead. At least Python as DSL for GPU JIT compilers is a thing now. Yes, I know about PyPy in the corner looking for attention.
> we have so much better dynamic languages with advanced JIT implementations What are some of these better languages that you're referring to? (The usual dynamic language JITs I hear people praise are LuaJIT and Chez. And V8. And the JVM?)
Re: Programming in D: Tutorial and Reference
#103Re: Programming in D: Tutorial and Reference
#104Earlier quoted context omitted.
> we have so much better dynamic languages with advanced JIT implementations What are some of these better languages that you're referring to? (The usual dynamic language JITs I hear people praise are LuaJIT and Chez. And V8. And the JVM?)
Even Ruby has JIT now
Re: Programming in D: Tutorial and Reference
#105Re: Programming in D: Tutorial and Reference
#106Earlier quoted context omitted.
>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? The order is mentioned right in the docs, for Python 3: https://docs.python.org/3/tutorial/datastructures.html#list-... >Note how the order of the for and if statements is the same in both these snippets. And it is mentioned…
"RTFM" could excuse literally any syntax decision in any language. The hostility in your response to "lazy or stupid" devs is really funny given what a bad response it is.
Re: Programming in D: Tutorial and Reference
#107Re: Programming in D: Tutorial and Reference
#108Re: Programming in D: Tutorial and Reference
#109Really wanted to like Dlang but I just did not have a good time with it. One of my projects has a really simple server written in nodejs that's basically (in terms of complexity) just an auth'd chatroom, and I wanted to switch it from using raw tcp sockets to websockets. And since the server is so simple, why not refactor it to another language and see if there's no some performance gains from that? I ended up doing…
Hi there. I'm the serverino's author. Could you please explain better what's wrong with it? It could be useful to improve newcomers experience. How did you choose serverino over other frameworks?
Re: Programming in D: Tutorial and Reference
#110Earlier quoted context omitted.
Hi there. I'm the serverino's author. Could you please explain better what's wrong with it? It could be useful to improve newcomers experience. How did you choose serverino over other frameworks?
Oh the issue isn't with serverino itself but with the lack of tooling-support for the language features that serverino makes heavy use of. And while serverino is open source, so one can ultimately view its source code, not having access to modern IDE type inspection adds a lot of unnecessary friction.