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

Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

cl.cam.ac.uk

Post reply on HN
Print view View original

131–140 of 253 posts

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#131

Post by Koshkin »

WalterBright wrote: post #112
pcwalton wrote: post #7

This is another article overanalyzing the success of C, when in fact the reason for the success of C is very simple and obvious: Unix was free and in a lucky position in 1973; Unix got popular; C is the language of Unix; therefore C got popular. There is no inherent benefit in C that, for example, a somewhat modified version of Pascal or Algol wouldn't have inherited. And these kinds of articles always ignore the fac…

C got popular because it turned out to be ideally suited for DOS, which was by far the dominant target for programmers for over a decade. For example, C could deal with near/far pointers. No other language could. Early C implementations were also usable on DOS, early [other language] implementations were unbelievable unusable, and believe me I tried. There were many diverse, usable, and cheap C implementations availa…

The popularity of C had absolutely nothing to do with DOS. The most popular languages on early PCs were BASIC and Pascal. The popularity of C is linked to UNIX, from where it was brought to DOS. The far/near pointers did not play especially well with C view of pointers as integers of some fixed size. The 32-bit flat memory model made C programming somewhat closer to what it used to be in UNIX.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#132

Post by flukus »

burntsushi wrote: post #102
flukus wrote: post #100

Earlier quoted context omitted.

> I'm glad you like your package manager. Most programmers, including me, don't want to have to deal with it when the goal is simply to put a Rust project together. This is the same attitude that makes electron so attractive. As a user, I don't care what makes your life easier as a developer, I care that I'm getting a more bloated and less secure result. This is an awful attitude that's creeped into software developm…

> As a user, I don't care what makes your life easier as a developer You should. The easier my life is, the faster I can fix bugs and put out new releases.

I'm dealing with the result of this attitude on my phone right now. The end result is I can't even install your app because I'm out of space on my phone. I'm out of space because every other app maker favored developer productivity over being conservative with users resources.

It's a tragedy of the commons.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#133

Post by Const-me »

kibwen wrote: post #92
Const-me wrote: post #54

Earlier quoted context omitted.

> Graph in Rust: https://github.com/bluss/petgraph Thousands lines of code. Large amount of that is unsafe rust, even C++ is safer than that :-) > SIMD in Rust: http://huonw.github.io/blog/2015/08/simd-in-rust/ (yes, still in nightly) It was already “still in nightly” a year ago. Also it’s harder to do integer math with it, because type safety: very often, even consecutive instructions interpret these __m128i registe…

> Thousands lines of code. Have you taken a look at petgraph? It does quite a lot of things. The same functionality in C would be thousands of lines as well. > It was already “still in nightly” a year ago. SIMD is in Rust nightly not because it's immature, but because the Rust developers would rather design a portable interface than quickly standardize a nonportable one. Given that AFAIK neither the C nor C++ specifi…

> neither the C nor C++ specifications include provisions for SIMD and all support is compiler-specific

The support is portable across compilers. You #include , and you’ll get these SIMD intrinsics as documented on intel.com.

BTW, OpenMP isn’t in the C++ language spec either, doesn’t prevents it from working on most compilers and platforms.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#134

Post by Const-me »

burntsushi wrote: post #115
Const-me wrote: post #106

Earlier quoted context omitted.

> then use unsafe/raw pointers Even if I manage to extract an unsafe pointer from that Rust collection, I don’t know for how long will it work. For C++ collections, iterator invalidation rules tell me that.

You'd have to box your values. And if you didn't want to do that, then I'd just used the indexing method mentioned elsewhere in this thread. I've used such things in performance critical code.

> the indexing method mentioned elsewhere in this thread

https://news.ycombinator.com/item?id=15180649

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#135

Post by Nomentatus »

burntsushi wrote: post #102
flukus wrote: post #100

Earlier quoted context omitted.

> I'm glad you like your package manager. Most programmers, including me, don't want to have to deal with it when the goal is simply to put a Rust project together. This is the same attitude that makes electron so attractive. As a user, I don't care what makes your life easier as a developer, I care that I'm getting a more bloated and less secure result. This is an awful attitude that's creeped into software developm…

> As a user, I don't care what makes your life easier as a developer You should. The easier my life is, the faster I can fix bugs and put out new releases.

I've previously suggested here that OSes and OS manufacturers should test and rate apps for tightness, and punish apps that aren't tight by handing them fewer resources - running them noticeably slower.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#136

Post by Koshkin »

pcwalton wrote: post #67
kahlonel wrote: post #61

Earlier quoted context omitted.

Did you even the read the article? How are you comparing JS, Python (or any language "gaining popularity" in your metrics) to C, when the author clearly describes the set of problems only solvable in C?

The point is that those problems are (a) not only solvable in C; (b) not problems that most programmers need to solve. That is why C and C++ are declining in usage.

Are they, really?

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#137

Post by WalterBright »

Koshkin wrote: post #131
WalterBright wrote: post #112

Earlier quoted context omitted.

C got popular because it turned out to be ideally suited for DOS, which was by far the dominant target for programmers for over a decade. For example, C could deal with near/far pointers. No other language could. Early C implementations were also usable on DOS, early [other language] implementations were unbelievable unusable, and believe me I tried. There were many diverse, usable, and cheap C implementations availa…

The popularity of C had absolutely nothing to do with DOS. The most popular languages on early PCs were BASIC and Pascal. The popularity of C is linked to UNIX, from where it was brought to DOS. The far/near pointers did not play especially well with C view of pointers as integers of some fixed size. The 32-bit flat memory model made C programming somewhat closer to what it used to be in UNIX.

> The popularity of C had absolutely nothing to do with DOS.

You might want to read popular programming magazines from the early 80s, and the attention given to C on DOS. (It was enormous.) At one time, I counted 30 C compilers available for DOS. What other platform came remotely close to that?

> The most popular languages on early PCs were BASIC and Pascal.

BASIC was indeed popular, but generally not for professional programming. Pascal had nowhere near the penetration of C in the early days (1982, 1983, etc.). Microsoft Pascal 1.0 was unusable, the top C compiler was Lattice C.

> The popularity of C is linked to UNIX, from where it was brought to DOS.

Unix was nowhere remotely as popular as DOS.

> The far/near pointers did not play especially well with C view of pointers as integers of some fixed size.

As a DOS C compiler writer, I can attest that near/far mapped very well onto C semantics. The C Standard in 1989 was very careful to not upset that.

> The 32-bit flat memory model made C programming somewhat closer to what it used to be in UNIX.

That was much later. But since you brought it up (!), 32 bit DOS extenders were in wide use on DOS, and were programmed with C. I don't recall Pascal ever existing on them, but perhaps I misremember. C was also popular on the 16 bit DOS extenders, I don't remember Pascal on those, either.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#138

Post by Const-me »

oconnor663 wrote: post #123
Const-me wrote: post #110

Earlier quoted context omitted.

> I think you can always use unsafe to get access to a raw pointer I’m not sure about that. Also I don’t know for how long will it work, C++ has iterator invalidation rules. > you need someway to express ownership between both data structures Not every relation is ownership. Graph modes don’t own each other, an external index doesn’t own the indexed items, etc.

I'm really not sure, but I think there's a miscommunication about raw pointers in this thread. I think other folks are suggesting that you can solve the container composition problems you're talking about by inserting raw pointers into a HashMap. But I think you're reading that as obtaining raw pointers to the storage that a HashMap owns, which is why you're worried about iterator invalidation rules and stuff like th…

To create an external index for the existing collection, I need to get pointer of the item stored in that existing collection, compute a key, and put both into the HashMap

So, I need to do both. And also, I need to know when these pointer expire so I can rebuild my index when it happens.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#139

Post by Const-me »

cesarb wrote: post #129
Const-me wrote: post #106

Earlier quoted context omitted.

> then use unsafe/raw pointers Even if I manage to extract an unsafe pointer from that Rust collection, I don’t know for how long will it work. For C++ collections, iterator invalidation rules tell me that.

> Even if I manage to extract an unsafe pointer from that Rust collection, It's easy, just get the & or &mut to the value (as if you were acessing it), and cast it to respectively * const or * mut. > I don’t know for how long will it work. For C++ collections, iterator invalidation rules tell me that. It's the same in Rust. Whenever the iterator would be invalidated in C++, the pointer you stashed above might point t…

> keeping the values in a Box > for keeping a value in more than one collection would be to use a Rc

Indeed, both methods are simple and elegant ways to approach the problems.

The bad thing with both of them is performance.

Box means when I need to iterate through all values in a collection, I’ll get random memory access for each item. Rc is even worse, not only it’s RAM read latency per item, also ref.counting overhead per item (AFAIK even when reading stuff).

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#140

Post by Const-me »

cesarb wrote: post #103
Const-me wrote: post #74

Earlier quoted context omitted.

> There's a third kind, which uses indexes into arrays containing the nodes and edges Pointers are still faster. Also with arrays it’s expensive to reduce RAM usage after a lot of nodes were removed. > Can any of these protect against the scenario where a block of memory is freed, allocated again for another purpose, but still accessed through the old dangling pointer? No 100% guarantee, but AFAIR CRT debug heap take…

> Pointers are still faster. Depending on cache effects, indexes might or might not be faster than pointers. With indexes into an array, the nodes or edges will be sequential in memory, which depending on their size and access patterns might increase the cache hit rate. Furthermore, while pointers will always be 8 or 4 bytes, indexes can be as small as 2 or even 1 byte for smaller graphs (reducing structure sizes and…

https://news.ycombinator.com/item?id=15180649
Post reply on HN