Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better C – A subset of D Programming Language

dlang.org

Post reply on HN
Print view View original

281–290 of 360 posts

Re: Better C – A subset of D Programming Language

#281

Post by kreco »

snazz wrote: post #260
kreco wrote: post #250

Earlier quoted context omitted.

Thanks for your comment. It's pretty normal to face this downvotes when talking about language. And my phrasing was not the most kind of all. It's just the CS community, at some point when you are writing languages you tend to try to outsmart the language you are fixing by creating overly complex behavior. Over-engineering is every single new languages. Even Zig fails to do better than C, I think it's syntactically a…

Do you not like those because they're unfamiliar? What about the syntax indicates over-engineering? Here's what I see in your example: - @ indicates built-in function, which avoids namespace collisions. - Optional types via the ?, which solves the null pointer problem. - Real iterators, which are less error-prone and nicer to read than traditional for loops in a lot of common applications. - The || syntax is better t…

Thanks for spending your time explaining this. I think a lof people will understand those lines better.

I actually already knew everything. I watched closely the development of Zig, and just give up when I realized all those decisions where made carelessly in my view or I just simply disagree with the direction of the syntax.

Since you took your time I will take mine to address what I don't like:

- There is no way to write "int" by default. I understand why. But I don't agree.

- struct and enum statements (within braces) are separated by a comma which is inconsistent with statements in function separated with ",". In my view expect a difference between parameters and statements. parameters (a,b,c) statement {a;b;c}

- You have to type "var" or "const" everywhere, but not in struct statement and enum statement. Sometimes it's like a "def" sometimes not.

- You have to type const when importing module:

  const std = @import("std"); // Why ? Why should I specify const, this should be inferred. Same when I define a struct.
- the "undefined" keyword when it means "uninitialized" even in the documentation.

  var my_var: i32 = undefined;
- The worst, no default values for struct.

- The list of keywords is insane: errdefer, allowzero, orelse, unreachable, anyerror

- About iterator I was doing well with:

  while(get_next(context,  &item)) { /* ... */ }
It's like everything has been carefully design to be even less readable than C code. I have the feeling that the syntax help more the compiler than de developer.

I wish I could bet thousands of dollars that there will be only one compiler in the whole life of Zig language (also because it relies way too much to LLVM).

Re: Better C – A subset of D Programming Language

#282

Post by jane_red »

takeda wrote: post #254
arunc wrote: post #76

Earlier quoted context omitted.

Vim vs emacs, auto inference vs explicit, I don't think it will ever end. :)

I don't know D, but after reading more comments looks like auto is also compensating for poor type system. For example functions that accept arguments of many types apparently need to be declared that are returning auto. At least that's what I understood.

Scala has a strong type system and when working with it on a daily basis I was not programming, I was thinking about types and fighting with the compiler. And that is the language which has a pretty decent IDE plugin. When I moved to D, it felt like a breathe of fresh air to me. Therefore, the whole talk above about auto and types looks like subjective nitpicking.

In practice though, D codes fast and runs fast, as promised on the official site.

Re: Better C – A subset of D Programming Language

#283

Post by e12e »

elcritch wrote: post #85
kqr wrote: post #35

This is a great idea. I maintain that Ada is a better "better C" than any of the alternatives I've looked into, but it has an obvious big hurdle: while it has approximately the same use cases as C, it is completely different in terms of looks and handling. One of the strong points of D is that it still seems very much like C. Very good call to emphasise this.

I’ve always liked the idea of Ada, but never had a place to use it. Though someone on HN pointed out that NVidia was using Spark for secure code sections. Quite interesting! Personally while D seems a great tool, I really keep running into situations where a language that lives on top of C/C++ is useful. So I’ve been trying out Nim for those use case, using the ARC GC which appears to work well for embedded. It’s det…

> I really keep running into situations where a language that lives on top of C/C++ is useful. > the biggest advantage is being able to directly interface with any C or C++ natively. D/Rust both seem to have difficulty being 100% onboard with C++

I thought one of the centerpieces of D was seamless c++ interop? Where does it fall down?

Re: Better C – A subset of D Programming Language

#284

Post by jane_red »

arunc wrote: post #212

For me the single best feature that stands out in D is the uniform member access using dot. - Want to access member in a aggregate (class/struct)? Use . - Want to access member in pointer to an aggregate? Use . - Want to access member in a module? Use . - Want to access reference (not free standing)? Use . This makes switching between different implementations pretty easy. Coupled with UFCS, this is pretty fantastic!

I can strongly relate to that. You can write a custom "fill" method for your array and just do "arrray.fill", bam! It just works. You want numpy "zeros"?

Just do a template

void zeros(T)(ref T arr) { arr.each!"a = 0"; }

someArr.zeros;

Re: Better C – A subset of D Programming Language

#285

Post by strbean »

pjmlp wrote: post #242
Koshkin wrote: post #236

Earlier quoted context omitted.

Unfair comparison: Turbo Pascal 7 is more like C++20.

Not really, hence why I mentioned 1992. C has had plenty of time to catch up, but apparently it wasn't something that WG14 cared about. And it is not like many aren't actually coding in GCC C, Clang C, TI C, xlc C, aC C and so on. Which even with those C extensions fail on the security story.

At university, my classes in C required using C89. The rationale given by the professor was that he wanted us prepared for industry, and if you learn to stick to C89 you will be able to write C for any job out there. I argued that C99 block scoped variables free up stack space (pretty silly argument but true), he wasn't buying it.

I think this kind of thinking is very common across the C community.

Re: Better C – A subset of D Programming Language

#286

Post by throwaway17_17 »

exiled13 wrote: post #222
WalterBright wrote: post #37

Earlier quoted context omitted.

D also now supports Ownership/Borrowing (experimental) on a per-function basis, meaning it can be added incrementally to an existing program.

D's borrow checker fails in comparison to Rust's. It serves very little purpose and provides almost no guarantees. These issues have been brought up multiple times but they are brushed aside with ignorant responses like "I've been told my entire career what I'm doing will fail but I continue to do it anyways".

What is the difference between the two?

Re: Better C – A subset of D Programming Language

#289

Post by snazz »

kreco wrote: post #281
snazz wrote: post #260

Earlier quoted context omitted.

Do you not like those because they're unfamiliar? What about the syntax indicates over-engineering? Here's what I see in your example: - @ indicates built-in function, which avoids namespace collisions. - Optional types via the ?, which solves the null pointer problem. - Real iterators, which are less error-prone and nicer to read than traditional for loops in a lot of common applications. - The || syntax is better t…

Thanks for spending your time explaining this. I think a lof people will understand those lines better. I actually already knew everything. I watched closely the development of Zig, and just give up when I realized all those decisions where made carelessly in my view or I just simply disagree with the direction of the syntax. Since you took your time I will take mine to address what I don't like: - There is no way to…

Thanks for replying! Most of what you wrote makes reasonable sense to me. I guess that a lot of the syntax decisions are subjective. Even if I don’t necessarily agree with all of them, I can appreciate your viewpoints better now.

Re: Better C – A subset of D Programming Language

#290

Post by arunc »

colonwqbang wrote: post #267

The chosen example (printf) doesn't make D look very good compared to C. If I modify the example to include a simple type error: printf("Hello %s", 123); Then the D version will still happily compile without warnings and will segfault. Compiling with GCC -Wall -Werror, the type error is easily caught by the compiler.

Use dmd master and you will have printf/scanf format argument validation [0].

[0] https://github.com/dlang/dmd/pull/10852

Post reply on HN