The sound dampening pad does not dampen switch and keycap noise.
56 karma · joined March 20, 2012
Maybe in a functional programming language like Haskell. But not in C++.
That's exactly:
> give all of those functions different names.
And they will realize that even that has quirks.
Some might see the need for C libraries as evil and unnecessary (I personally don't), but it's the situation we're in.
As an example, instead of starting another desktop project (lxde, razor-qt, lxqt), some could have contributed to or collaborated with xfce.
> Nobody needs that many desktops, especially when nearly all of them are clones of each other in either GTK or Qt and 95% of the apps duplicate each others' functionality.
In a way like lxde, razor-qt, lxqt in relation to xfce.
Seems like you've contributed quite a bit to the fragmentation, coming back and preaching collaboration will at best only fix part of the problem.
I completely agree with everything you point out. The argument I am bringing up is not about implementation, it's about "if they didn't use C, they would have less (security) problems": No.
C is the way it is towards secure coding because there are compromises to satisfy other dimensions. <Fancy new language that promises to solve all of C's problems> is either making huge sacrifices in these other dimensions or is at best an experiment.
We understand C's weak points so well (due to being widespread, battle tested, really simple, or what have you), that most of the time it's safer (read: more secure) to tread dangerous well-understood territories carefully than uncharted ones only promising to be safe.
Is HN still really up for that argument? Yes, we know the downsides of C. But the upside is that _we know the downsides of C_.
Constantly complaining about C isn't going to get anyone anywhere. It's been shown over and over again that secure C coding is possible and doable and feasible and exists in the real world. Some of the most secure software is written in C, and that's not attributed to enough fingers banging at a keyboard over a C program, but because C forces the programmer that _wants_ to write a secure program think about all the issues, the universe and everything.
So please, pave the road and show us the safer OpenSSL-rust you have. Until then good luck and thank you for your feedback.
This is very true and funny only when read as a sarcastic comment.
Care to elaborate on that?
Does this make things like "const int * const x" (in C syntax) pointless in Rust?
Does that mean that in Rust I can only pass to a function an immutable reference to a mutable object, but not a mutable reference to an immutable object?
Also, out of curiosity, how would something like a recv() call into the middle of an array (buffer) look like in rust? Something like "recv(sock_fd, buf + 5 * sizeof(char), buf_len - 5 * sizeof(char), 0)"?
Regarding Haskell, I used LYAH and the standard library documentation.
I agree that Haskell is not easy to learn and that the libraries require a lot of foundation before becoming understandable and/or usable (eg, Monoids -> Applicatives/Monads vs. "I just want to read the contents of this file into a string"). The language "proper" is built on extremely simple and straightforward concepts.
echo "print(3)" > boot.jl
julia --compile=all -O --inline=yes --check-bounds=no --output-o foo.o
I don't think that C stays alive because people just automatically rejected anything else. There is something to C that I appreciate extremely, and that is the clarity and simple semantics: there is not much hiding and unintentional obfuscation that one can cause when writing C code.
Maybe safety and simplicity are mutually exclusive if speed and fine-grained control over memory are the main goals.
For Modula, the tools and documentation are not being updated anymore, I could not find a programming environment for eg., emacs and on armv6.
Free Pascal and Lazarus are great, until I realized there were no resources to learn modern pascal from. The emacs mode is too basic and doesn't take any advantage of things offered by fpc. But I have to admit, I've never seen anything as good as Lazarus before.
D is more like a C++ successor that's aiming at Java than a successor to C. It is complex and does not seem to be making any effort in unifying its concepts: in the same spirit of C++.
Cyclone is definitely interesting, but unmaintained and not exactly simple, similarly to Rust but with a C-like syntax.
Julia crashes all the time with segmentation faults, sorry, the quality of Julia is super low. I would not use it for anything serious. It has great ideas though.
OCaml is super complex with its syntax and semantics.
I love Haskell, which makes great efforts to unify its concepts: the language is super simple (its implementation can be arbitrarily complicated). Haskell is where I go to write beautiful things. Fast (like, systems programming fast) Haskell code is ugly and unmaintainable and defeats the purpose of choosing Haskell in the first place.
I'll be taking a look at the rest! Thanks!
I hope I am making any sense... Please tell me if I should try to rephrase, or if I am in need of clarification on the subject.
(BTW, this is also something I really dislike about C++, two function calls that look exactly the same, foo(x) and bar(x), could either be pass by value or pass by reference: you have to go dig up the function signatures to figure that out).
- Compiled, type-safe and available for armv6.
- Simple semantics: Rust and Ada are complex (C++-ish) and it gets hard to limit the number of memory allocations/accesses as well as data copies going on.
- Tooling and discoverability: Man pages and Emacs with a few modes that are easy to setup beats anything I've tried so far.
I understand that C has shortcomings when it comes to safety/security and even lacks features that would make programming certain things easier, but what do you suggest I use when I want to write a UNIX daemon that needs to transfer a boatload of data from disk over the network and vice-versa?
I personally like it, I find it to be clear and concise, a little tedious but at the price of giving me fine grained control over the data in memory: I just have to be careful with that.
This talk was amazing, I was overwhelmed by the amount of work going into C++. The problem is that it is already an abysmally complex language (to me) and it doesn't look like anything is getting simpler. It's as if you had to be there from the start to have a full image of how the language grew and truly understand the interplay between all the "features", otherwise it's too late to become an expert, and in some cases even too late to become comfortable writing good maintainable code in C++.
Unfortunately nothing comes close to its level of "practical usefulness" in all dimensions (expressiveness, reasonable speed, ecosystem, etc...). I personally just stick to C because things are simple to understand and I just live with its shortcomings.
I've never worked with Pascal, and I've been looking for an alternative to C that solves some of the issues I'm having without sacrificing too many of its advantages. Since fpc is available for armv6, I am wondering if someone could give me advice on whether moving this project to Pascal would be beneficial, especially compared to the following points:
- A proper module system, without having to keep .h and .c files in sync when the interfaces aren't stable yet. I am currently using makeheaders to make things less annoying for me.
- Compiler warnings, cppcheck and scan-build offer me great feedback. Emacs integration of these tools is priceless.
- The ability to do things like recv() into the middle of a buffer. That is just too efficient to let go of. I think this is something many people overlook when comparing C to other programming languages, many times you can turn O(2n) into O(n) by taking advantage of this. Not theoretically different, but in practice it can pay off.
- Emacs integration and support. Nice to have would be support for auto-completion, static analysis, etc...
- Documentation. Man 2, 3 and 3p are priceless. Emacs man integration is great.
- Number types that are exactly the same across architectures. eg, I've had issues because off_t was ulong on one machine and ulonglong on the other.
- Memory management, error handling and everything you need to do that has nothing to do with the task at hand. It gets old quickly.
- Optionally high-level, I am comfortable working with pointers and addressing memory directly, but sometimes I look for elegance where I know performance is not going to be affected too much (ie, the trade-off is acceptable). This also means that when I'm working with higher-level constructs, I'd like to have easy access to the inner workings so that I can make such a judgement myself (either through documentation or other means).
- I don't care too much about compilation speed.
- Easy semantics and simplicity of things. I really don't think I can put that into words, it's better understood through experience. But this is one of the biggest reasons I stick with C rather than C++ or Rust.
- The availability of a widely approved guide that doesn't go into the very basics of programming to explain the language (maybe some sort of Pascal for C people kind of thing).
- There are probably a few more points I could talk about but can't think of right now. I could write them down some time later if anyone is interested.
Thank you in advance, I would really appreciate if anybody can help me with these points, I'm looking for new adventures :)
This sounds really strange to me. So may I ask why? I find that recursion - most of the time - helps shorten and clarify the code. Also, doesn't recursion make induction proofs trivial?