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

Obvious things C should do

digitalmars.com

Post reply on HN
Print view View original

151–160 of 310 posts

Re: Obvious things C should do

#151

Post by nindalf »

TheNewAndy wrote: post #134
kouteiheika wrote: post #125

Earlier quoted context omitted.

> I’m with parent - what if you don’t have the tool? The "what if you don't have the tool" situation never happens in case of Rust. If you have the compiler you have the tool, because it's always included with the compiler. This isn't some third party tool that you install manually; it's arguably part of the language. > What if there’s a syntax error in some implementation or dependency such that the tool chokes earl…

"Never" is a big call. In this specific case, your tool requires a web browser (though I'm assuming that there is a non-web browser form of what is being sold here). Maybe you are in a situation where you only have terminal access to the machine. Maybe you are on your phone just browsing github looking for a library to use I'm sure people can continue to imagine more examples. It is entirely possible that we have dif…

> I’m sure people can continue to imagine more examples

Hopefully they’ll imagine more compelling examples.

If the hypothetical person’s phone is capable of browsing GitHub, I don’t see why they can’t also browse docs.rs. It renders well on small screens. That’s not a hypothetical, I’ve actually read the docs for libraries on my phone.

Re: Obvious things C should do

#153

Post by sim7c00 »

josephg wrote: post #147
tpoacher wrote: post #135

Earlier quoted context omitted.

I'll second this in Java land. I much prefer reading the sources directly than javadocs. Though jshell also comes in handy.

I have the same experience a lot of the time with 3rd party rust crates. Doc.rs is amazing - but it’s rare that I’ll use a library without, at some point, hitting view source.

for most rust ive done (not tons) the docs were very basic as onky auto generated with minimal content. totally useless, have to read sources to find out what is in there. auto documentation to me ia just ti satisfy people who need to tick all of these boxes and want to do with minimal effort. has dox has tests etc. such artitude never leads to quality.

Re: Obvious things C should do

#154

Post by trenchgun »

TheNewAndy wrote: post #72

Header files are one of the things I miss the most about languages that aren't C. Having a very clear distinction between public and private, and interface and implementation is one of my favourite things about C code (at least the way I write it). Being able to just read through a library's .h files to know how to use it is really nice. Typically, my .h files don't really look like my .c files because all the docume…

OCaml .mli interface files are the same, but better.

Re: Obvious things C should do

#155

Post by d0mine »

chii wrote: post #119
kstenerud wrote: post #94

Compile time unit tests are as bad of an idea as "unused import/variable/result" errors (rather than warnings). They're "nanny features" that take control away from the developer and inevitably cause you to jump through bureaucratic hoops just to get your work done. These kinds of build-failing tests are great for your "I think I'm finished now" build, but not for your "I'm in the middle of something" builds (which a…

> These kinds of build-failing tests are great for your "I think I'm finished now" build, but not for your "I'm in the middle of something" builds i tend to disagree. If you tried to express some thought but the compile time tests tells you you're wrong, you might actually just have an incomplete thought, or have not thought through all of the consequences of said expression. It's basically what type-checking is in h…

Test-driven development has its uses. But it is wrong to make it mandatory. I myself run static checks/unit tests almost all of the time. Still it is useful to skip them from time to time and just run the code to see the results (make it work before you make it "right" according to some linters rules).

Re: Obvious things C should do

#156

Post by Dylan16807 »

EuAndreh wrote: post #70
WalterBright wrote: post #47

Earlier quoted context omitted.

> forward declaration requirement enables a single-pass compiler to emit code on-the-fly. True, I know all about that. My Zortech C and C++ compiler was one pass (after the multiple preprocessing passes). The ground up ImportC C compiler completed a couple years ago has a separate parse pass. So I well know the tradeoffs. The parser being stand-alone means it is much simpler to understand and unittest. I found no adv…

> The parser being stand-alone means it is much simpler to understand and unittest. Stand-aloneness and single-passness are orthogonal. > I found no advantage to a single pass compiler. It isn't any faster. A gigantic advantage: a single-pass-compilable language is simpler. By definition. Implementations may or may not be simpler or faster. > C++ doesn't allow forward declarations either. Well, that's not what I mean…

> A gigantic advantage: a single-pass-compilable language is simpler. By definition.

That's only "by definition" if you take a language that needs multiple passes, then remove the features that need multiple passes, and don't replace them with anything else to compensate.

The "by definition simpler" version of C would not only disallow forward references, it would have no forward declarations either. As-is, forward declarations add some complexity of their own.

(Also, if you can figure out a way to emit jump instructions in a single pass, you can probably figure out a way to call unknown functions in a single pass.)

Re: Obvious things C should do

#157

Post by kouteiheika »

jmb99 wrote: post #140
kouteiheika wrote: post #125

Earlier quoted context omitted.

> I’m with parent - what if you don’t have the tool? The "what if you don't have the tool" situation never happens in case of Rust. If you have the compiler you have the tool, because it's always included with the compiler. This isn't some third party tool that you install manually; it's arguably part of the language. > What if there’s a syntax error in some implementation or dependency such that the tool chokes earl…

> The "what if you don't have the tool" situation never happens in case of Rust. So it’s built into GitLab and GitHub? BitBucket? How easy is it to use on windows (i.e. is it is easy as opening a .h in notepad and reading it)? How easy is it to use from a command line environment with vim or emacs bindings? I could go on. “Never” is doing a lot of heavy lifting in your assertion. I shouldn’t have to install a toolcha…

> So it’s built into GitLab and GitHub? BitBucket?

No. It's built into the toolchain which every Rust developer has installed.

> How easy is it to use on windows (i.e. is it is easy as opening a .h in notepad and reading it)?

A easy as on Linux or macOS from my experience.

> How easy is it to use from a command line environment with vim or emacs bindings?

Not sure I understand the question; use how exactly? You either have a binding which runs `cargo doc` and opens the docs for you, or you use an LSP server and a plugin for your editor in which case the docs are integrated into your editor.

> I shouldn’t have to install a toolchain (let alone rely on a web browser) to read API documentation.

If you want you can just read the source code, just as you do for any other language, because the docs are right there in the sources.

For publicly available libraries you can also type in `https://docs.rs/$name_of_library` in your web browser to open the docs. Any library available through crates.io (so 99.9% of what people use) have docs available there, so even if you don't have the toolchain installed/are on your phone you can still browse through the docs.

I know what you're going to say - what if you don't have the toolchain installed and the library is not public? Or, worse, you're using a 30 year old machine that doesn't have a web browser available?! Well, sure, tough luck, then you need to do it the old school way and browse the sources.

You can always find a corner case of "what if...?", but I find that totally unconvincing. Making the 99.9% case harder (when you have a web browser and a toolchain installed, etc.) to make the 0.1% case (when you don't) easier is a bad tradeoff.

Re: Obvious things C should do

#158

Post by pjmlp »

nox101 wrote: post #146
kouteiheika wrote: post #99

Earlier quoted context omitted.

> Header files are one of the things I miss the most about languages that aren't C. Having a very clear distinction between public and private, and interface and implementation is one of my favourite things about C code (at least the way I write it). I always found this argument baffling, because the way some other language solve this problem is with tooling, which is a much better way to do it in my opinion. Take Ru…

Sounds like COM/DCOM from ~1995. Every API had a public interface including a description. You could open the DCOM Inspector, browse all the APIs, and see the type signature of every function and its docs.

Still is COM from 2025, given its relevance on Windows, even more since Vista, as all Longhorn ideas were remade in COM.

However the tooling experience is pretty much ~1995, with the difference IDL is at version 3.0.

Re: Obvious things C should do

#159

Post by mtlmtlmtlmtl »

kouteiheika wrote: post #138
TheNewAndy wrote: post #113

Earlier quoted context omitted.

This is probably something where it comes down to preference and familiarity. I would much prefer a simple text file for documentation that I can grep, open in my text editor, modify easily without switching context (oh, I should have been more explicit in the documentation I wrote - let me just fix that now), etc. All the features you mentioned "nice interface, fully searchable API interface, whole public API" are e…

> All the features you mentioned "nice interface, fully searchable API interface, whole public API" are exactly what you get if you open a well written header file in any old text editor. No, you can't, and it's not even close. You have a header file that's 2000 lines of code, and you have a function which uses type X. You want to see the definition of type X. How do you quickly jump to its definition with your "any…

Most decent text editors support something like go to definition. Your entire comment seems to be based on the idea that text editors only support basic search, which is simply false.

Personally I'm quite content with both experiences. But it really is just a matter of preference.

Re: Obvious things C should do

#160

Post by pjmlp »

TheNewAndy wrote: post #72

Header files are one of the things I miss the most about languages that aren't C. Having a very clear distinction between public and private, and interface and implementation is one of my favourite things about C code (at least the way I write it). Being able to just read through a library's .h files to know how to use it is really nice. Typically, my .h files don't really look like my .c files because all the docume…

Available in most compiled module languages, either separately, Modula-2, Modula-3, Ada, Standard ML, Caml Light, OCaml, F#, D.

Or it can be generated either as text, or graphical tooling, Object Pascal, D, Haskell, Java, C#, F#, Swift, Go, Rust.

All with stronger typing, faster compilation (Rust and Swift toolchain still need some work), proper namespacing.

Unfortunately C tooling has always been more primitive than what was happening outside Bell Labs, and had AT&T been allowed to take commercial advantage, history would be much different, instead we got free lemons, instead of nice juicy oranges.

At least they did come up with TypeScript for C, and it nowadays supports proper modules, alongside bounds checked collection types.

Post reply on HN