D is one better than C, but K goes all the way to 11.
(This is a slightly funnier joke than it may appear at first glance, because as well as being the name of another programming language K is in fact the 11th letter of the alphabet.)
D as a Better C
61–70 of 193 posts
Re: D as a Better C
#62Earlier quoted context omitted.
>Nim, Dart, and C as a comparison) Could I ask about your thoughts regarding Go (which has much less syntax and fewer features than all of the above). Have you looked into it?
Yeah. It should have been in that list, actually. I wanted to like Go. It seems simple (which is what I like so much about Clojure), but honestly, I found it to be frustrating for all the standard reasons the Go team is tired of hearing (e.g. no generics, error handling littering my code and obscuring intent, etc). In fact, I think Go doesn't quite deserve the reputation it has as being a simple language. It's a fami…
EDIT: this is getting downvotes for some reason even though it's just addressed to OP. OP, you could email me at the link on my profile if you didn't want to answer here. I'm not on the Go team or anything, just curious.
---
Thanks for your answers!
So I know you don't want to rehash what's easy to find elsewhere, but your perspective is different because you wrote a Clojure interpreter. It's not the same as what I can find from people who just use languages.
You just list:
>(e.g. no generics, error handling littering my code and obscuring intent, etc).
But could you flesh out this litany of complaints, even if it's common? I just want to know your version of that list, without the 'etc'. It's not going to be the same as other people's - different things will bother you or come to mind for you. I'm trying to understand these from your perspective and background. (which is unusual.)
Secondly, you write "but that's not the same thing as being simple". I don't really understand. Here on HN, people say you can pick up Go in an "afternoon" and become proficient in "a week".
You write that it is not simple but I don't know what you mean in specific, even when you write as a "Go n00b". This reply will be particularly interesting to me, because, since you've literally written an interpreter, compared to an average user, everything is simple for you.
Like, think of a standard designer who has first dabbled in Javascript and for some reason picks up Go. Whatever isn't "simple" for them would ordinarily be super-simple for you. So what's not "simple" for you is like obscure string physics to a person who is barely a programmer at all. I'm really curious what parts you didn't find simple.
Thank you.
Re: D as a Better C
#63Earlier quoted context omitted.
The better Python market isn't an easy one to crack because its a bit crowded. Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Python itself is improving rapidly, for example with the addition of Type Hints. Its pretty difficult to be a better Python in 2017. The better C market, on the other hand, hasn't seen any real…
I really really don't been to pile on Python... but every time I've had to interact with it I've been shocked at how slow it is compared with C or C++. I tend to write scientific code to process datasets in the range on 10Gb, for simple operations Python code can take hours as opposed to just taking minutes or seconds in C. I'm sure it's possible to write more highly optimized code in Python, but it never seems to be…
[deleted]
Re: D as a Better C
#64Why remove RAII? It's not fundamentally incompatible with "Better C" semantics, especially if there are no exceptions.
RAII requires exceptions to be correct. I hesitate to say it it has RAII otherwise. Exceptions have two issues: 1. D exceptions currently require the GC. There is a Pull Request to fix that, but it isn't incorporated yet. 2. More problematic is the Dwarf exception handling mechanism requires a language specific "personality" handler. This is supplied by the D runtime library. Trying to trick the C runtime library one…
> RAII requires exceptions to be correct.
I'm not exactly sure what you mean here, but all I really want is guaranteed destructors. Can we just have those?
Re: D as a Better C
#65Earlier quoted context omitted.
The better Python market isn't an easy one to crack because its a bit crowded. Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Python itself is improving rapidly, for example with the addition of Type Hints. Its pretty difficult to be a better Python in 2017. The better C market, on the other hand, hasn't seen any real…
And on embedded even C++ hardly managed to overtake C. https://youtu.be/D7Sd8A6_fYU
[deleted]
Re: D as a Better C
#66Why remove RAII? It's not fundamentally incompatible with "Better C" semantics, especially if there are no exceptions.
RAII requires exceptions to be correct. I hesitate to say it it has RAII otherwise. Exceptions have two issues: 1. D exceptions currently require the GC. There is a Pull Request to fix that, but it isn't incorporated yet. 2. More problematic is the Dwarf exception handling mechanism requires a language specific "personality" handler. This is supplied by the D runtime library. Trying to trick the C runtime library one…
Why does RAII require exceptions? RAII is routinely used in C++ with -fno-exceptions.
Re: D as a Better C
#67I tinkered with D a bit (along with Nim, Dart, and C as a comparison) while writing a Clojure interpreter. D seems to be a nice language, but I found the editor integration wasn't the best. I also found it annoying that the docs used `auto` all the time, so you could never figure out the right type annotations for their APIs (e.g. I want to call the foo API and return its value from my method, but the docs all use `a…
(Disclaimer: one of the Nim core devs here) Happy to see you paint Nim in a (sort of) positive light, I hope I can help with this one negative. > I liked Nim better in almost every way but one: the compiler was fickle and would just fail silently sometimes. Can you give some examples and elaborate on what you mean by "fail silently"? Did you at least get a segfault?
Unfortunately, I don't have any examples off-hand. It was a month ago. I'll see if I can dig the repo back up and reproduce the error.
As for how it failed, it did not segfault. It just stopped and dumped me back out on the terminal with no output at all.
(I'm on OSX 10.12.6.)
Re: D as a Better C
#68Earlier quoted context omitted.
Python is interpreted, C and C++ are compiled. They target different niches. Python is more focused on ease of use than performance. Usually when writing scientific code in Python you're going to want to at the very least use numpy. It wraps various C functions for many time consuming tasks. To get the most out of numpy you're going to have to vectorize you're code, as python's looping constructs are notoriously slow…
This seems like it would be great for a list comprehension. I believe the main appeal to using comprehensions is that it speeds up the iteration process at run time so wouldn't a list comprehension be just as useful here if not more so then?. You could also use the functools and itertools library for really fast iterations, possibly, depending on what it is you are trying to achieve. If you are specifically talking l…
But would that be faster than numpy? numpy in typical setup would use SIMD or other math kernel (mkl, blas, etc).
Re: D as a Better C
#69Earlier quoted context omitted.
You can easily get best of both worlds with Lisp derived languages.
It's been my understanding that Lisp and its relatives aren't designed to compete against C for speed either. Is this wrong?
C was designed on a PDP-11, a computer much more powerful than the mainframes where Lisp was already running since 10 years, so Lisp implementations were already quite good for most tasks by then.
While C designers were trying to create UNIX at AT&T, Xerox PARC was busy creating Smalltalk, Interlisp-D and Mesa/Cedar.
Other companies were creating Genera and the Connection Machine,
In the end Worse is Better won, because the machines were too expensive for most pockets, normal developers could not grasp Lisp, mismanagement from those companies and UNIX was kind of cheap when comparing prices, with source code available almost for free (AT&T was prevented from selling it early on).
Re: D as a Better C
#70I have really been enjoying working with Rust lately. I also enjoyed working with Go prior to that. Maybe I will give D a try too, see if I have similar luck.
I can find things I like and dislike about each of the new languages I try, but it kind of feels like there are a glut of options for me right now, and each one has held mostly positive surprises. Good problem to have: too many new languages that don't give me a headache, hard to choose.