New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
He wants democracy, you can have it, no problem.
Are you ok ?
Everyone using cpanel so like... half of the internet at least
@Neoon you're such a waste of time. Bait, bait, more bait and some bait after that... yawn
When I am a waste of time, why do you write a comment to lemme know?
I mean you just wasted your time as you said, go and do something useful.
ok.
Well, there is always a tiny amount of hope that people might care once being made aware of something. I admit the way i worded it doesn't help but hey nobody is perfect i guess. In any case i think you have way more potentional than what you are displaying here and if telling you this was a waste of time so be it.
I’m glad we can all find common ground on that.
That was a theory and you have taken it out of context, congrats.
I do not really care, about opinions from other people, about myself.
The definition of something usefull, always differs.
Not going to argue about this. Doing your own thing is good and of course useful is subjective. What baffles me is that i can't see what's in it for you. Sure, you can manipulate people into acting a certain way. Usualy in an iritated manner. I see how this might be an interesting experience at first but how is this useful to anyone in the long run?
Actually i wouldn't mind discussing the odd political topic you touch and see if something interesting comes up but this really isn't the place for it. It would just end in name calling and a huge clusterfuck besides it's not possible to know if you are serious or just hoping to stir up shit (not necesarily with me) and that's the real problem. It's not even getting to the point where what i think about you or your positions matters. There won't be any exchange of ideas since you are likely just playing a game and i usually wont risk to waste my time on it. In my opinion that's sad and useless but of course you are free to differ.
What's your operating system written in?
Classical clueless flameboy question.
All major OSs have 2 things in common: They are written in C and they have plenty of bugs, no matter how many years even very good developers work on them (and on getting the bugs out).
C is wildly unsafe.
C++ has all of C's dangers, plus crappy design and much insanity that makes it the worst programming language of all time.
There are workarounds for a lot of this (in C, any way)...e.g., valgrind, wrapping pointers, error checking, ifdeffing and typing everything, etc. but it's trying to keep the drunk on his feet. C is as wild west as you can get.
At least it's statically typed.
Couldn't agree more. C is great
Well, kinda ...
"int" basically says that it's a machine dependent number of bits that are supposed to represent an integer number.
Now, to be fair, it's gotten better, there are (u)int[8,16,32,64]_t types which are *much much better* but which are sadly little used and any given compiler may deal with them pretty much any way it likes (and casting, e.g. to/from pointers fucks up a lot too). And, frankly, I've seen *very very few* professional C developers even in quite big projects; most hardly know about e.g. the less common gcc pragmas, there a gazillion of parameters and single assignment vars that aren't const'ed, etc.
Looking at 1 off errors the sad truth is that those could be easily avoided by proper arrays containing their length and offering something like "High" and "Low" (Pascal) or "'Last" and "'First" (Ada). Add in "for in" loops and whole (major) classes of errors can be avoided.
As @raindog308 correctly mentions the really ugly problem is that C is ambivalently defined which means that one can not create proper static verifiers. At least until now not even when having the full compile cycle under control, as is the case with LLVM, proper verification can be done, which very unfortunately also means that we can't have tools checking large code bodies; about the best we can have is tools that look for specific problems and attract a testers attention who must then "by hand" look at them and decide/make changes.
Looking at the other side (early development) we could make ACSL annotations and use Frama-C. Unfortunately that requires not only another additional toolchain with lots of intricacies but is also generally cumbersome and requiring lots of knowledge and expertise (e.g. cvc4 or alt-ergo or ...? math, FOL, H3, ...) plus almost always quite some work by hand within Frama-C - which probably explains why that route is taken by very few. Moreover, there isn't a consistent flow; The code is one thing and ACSL is another thing (from the compilers view just comments that are thrown away early on).
As Ada is usually considered to be very complicated and pervert I usually suggest to use good old Pascal (well, not really old, not anymore). It gets quite close to something like Ada (without Spark) but is freely available, relatively wide spread and easy. It's a bit meager on the hard core formal side bit still with all the built in and almost "invisible" (not demanding anything from the developer, no math required, etc) safety features (e.g. type refinements, array control, etc) I consider it a quite nice compromise that allows to create dimensionally safer code than C.
Trust you to return with a lowball remark to a simple question. You're good at pointing out the fault in things, but apparently after almost 50 years of the language, there isn't a popular OS that isn't written in C.
Try offering something constructive instead of the ivory tower i know best routine.
I apologize. As you just demonstrated I should have said "clueless flameboy with reading difficulties".
No your post(s) are quite clear. A slight on the C language and some rambling whataboutery about other languages, with a smattering of "here's what I remember about C"
Do the developers a favour and divulge what language they should rewrite it in.
@ricardo
At this point I end the non-discussion with you as you lack even the minimum required understanding.
Yeah there probably is nothing that'll stop you spouting egotistical nonsense, this much is true.
Exactly. The fixed size types are godsent. Beyond cases where some (cough cough) api more or less forces me i can count the times where i actually use int, long, short and friends easily on one hand. Not sure whats to big problem with pointers but i am usualy not casting odd sizes to pointers (if really needed there's always uintptr_t or at least size_t) or just do arithmetic.
Yeah, writing good C requires pedantic attention to detail. Even after about 15 years of C and actually liking the language a lot i am still occationally guilty of the above (usually in the form of ill-fix-the-declaration-when-it-works which of course is often all but forgotten by then).
Tbh i'd treat any for loop referencing a literal maximum array index with extreme suspicion. Sure it might be the best solution in just that case but usually i'd expect a define or at least some kind of abstraction based on sizeof.
Interesting. So are there any recent developments regarding pascal? If so got any pointers? Might be tempted to see if it still feels familiar. I have to admit i have hardly any memory of its syntax anymore beyond a vague image of begin/end blocks. It being safer than C isn't much of a suprise though. I mean really what isn't? That constant feeling of walking on eggshells is what gives C it's certain charm imo.
Not actually true, but depends on "popular".
Both the IBM Mainframe and the iSeries (aka AS/400) are not written in C. z/OS (IBM Mainframe) has many C utilities but the core isn't C. iSeries is not based on C at all. These are massive, multi-billion-dollar markets processing trillions of dollars in transactions annually.
But yes, of course, C underlies Linux, *BSD, Android, iOS, Windows, etc.
@raindog308 ... sure, maybe we could just agree that there's a reason it's stuck around for 50 years and that each language offers greater freedoms or risks however you look at it.
I mean, it's easy to point the flaws of any language. Not so easy to offer something better, though.
Considering all the great software written in C, it's a bit pretentious just to write it off as some kind of inferior language without some sound alternative. My point, is all
Well, to be fair i'd go as far as saying i love C and i tend to agree with him as in C being pretty much the best tool available to shoot yourself in the foot with. Not that you absolutly have to but it easily happens without intend and when it happens it's often not just a tiny hole but where's-my-left-leg-from-the-knee-downwards-???.
@mksh indeed, I've wrote a wee bit and use higher level languages. With great power, great responsibility and all that. If I need memory management and performance, I'll go with C. Perhaps suitable alternatives are available.
It's easy to make over simplified arguments for one language or the other.
With C it's easy to shoot yourself in the foot, it's also easy to write some wrappers or use (relatively) proven libraries. You can use higher level languages and take the leap that other people's code will work. I know I do, libcurl is great, used it for years.
There isn't a language written by the God's that's powerful, foolproof and 100% bug free... so I ask for the better alternative. There isn't one.
Personally, my favourite bit of software is Google. Originally written in C (including a custom OS), with their Pagerank algo (in C, FWIW) revolutionised the way the world's information is organised.
Anyways, bug in software as per the OP. Why aren't there alternatives in other languages? Answers on a postcard.
There are tons unless you're writing device drivers or near-assembly optimizations.
In the 80s, I wrote end user applications in C. No one does that today. Because all the languages that came after C are safer, faster, etc.
There is zero reason Exim must be written in C. Zero. The reason it's written in C is that it's 20+ years old. It would be a safer, less bug-prone application if it was written in another language. It would have been developed faster and easier if it had been written in another language.
It's impossible for a programming language to save you from telling it the wrong thing to do. But ironically, the far larger set of off-by-one errors (for loops, array indexes, etc.) is fixed in other languages. The for loop, for example, is specifically engineered in Swift, golang, etc. to avoid C's pitfalls.
C's bracketless if statements are removed in other languages as well because they cause bugs. The entire massive headache of malloc and memory management is removed in many languages. Etc. Programming has moved on from 1970.
Yes. I also love C, mostly for nostalgia. Just finished reading this not long ago.
In the realm of computability, that's a very small surface area though, surely? I would take the leap of faith that there are sound reasons for those other languages you allude to.
It could be written in any language, question is which one and why?
Easily replicable, right? I confess I'm not as old (no offence) and experienced (I was a kid in the 80s), but I'm pretty confident someone has a library in C similar to the behaviours of [whatever beneficial arrangement you believe is best]
I'd agree it's moved on and having [someone or something else] manage things for you is nice and often beneficial.
Do you think C is archaic?
My take (admittedly I try and break it down into the simplest terms) is that you either take performance or convenience to your desired blend.
Hey, i am not trashing C. Imo it's beautiful, elegant and simple while being extremly powerful. @bsdguys main gripe seems to be the impossibility of static analysis which is admittedly somewhat over my head but given Cs tendency of nasty fuckups i see how one would want a bit more than just a safety net.
You sadly can't always rely on nice and clean libraries. How about some generic linked lists, hashmaps, fifos (aka message queues), dynamic arrays and so on. Throw in some optional thread safety, variable memory allocation strategies and a bunch of other gimmicks + optimization on top of it. Sure you are going to get it to work but i'd be impressed if you could just look at the result and honestly say "i can follow the logic for all the 100s of code paths from start to finish and i an sure this code is working as intended".
Not at all being a Pascal guru, as I use Ada for serious work and (Free)Pascal only for utilities, front-ends and such I don't feel well positioned to elaborate much about it, but I can say that it has references ("well managed pointers") since an eternity. From what I know there are also ways to use "real" pointers but I can't tell much about that as those cases are very rare in the scenarios in which I use Pascal and I have to confess that I then simply do those routines in C (FreePascals FFI is quite OK).
Having worked in C for decades and even teached it I do love it; that's not the question. The issue why I left it for all professional work is that in my field C simply is the bloody most inefficient way to develop in. The problem is that exactly what makes us love C is suddenly all dead wrong and dangerous when you need reliable and safe code, when it's not about having fun when coding but about proper engineering and being able to prove that the code works and works reliably, safely, and as specified. That's where ACSL plus separation logic which requires yet more and different tools enter the game and you soon can't but see that that way of working is utterly inefficient, riddled, and still with some dark corners.
Pascal, I feel, is a good and reasonable answer. It's really easy, it's even fun (as a gazillion of Delphi hobby programmers demonstrate) and it's a way to achieve way better (more reliable, less critical errors) code, and it's much, much easier than C with ACSL/Frama, let alone separation logic plus it's about as fast as C, but alas it's considered "uncool" by C programmers.
P.S. Have a look at the steelman comparison: https://www.dwheeler.com/steelman/steeltas.htm
I'd add to that that with many modern languages the compiler can be your friend and helper. When it complains or even just warns it's helping the developer. Not so with C. Some C code being compiled without errors means next to nothing - and certainly not that the program is reasonably bug free.
No.bsdguys gripe isn't about not having a static analyzer for a language. For Pascal, for instance (like the vast majority of languages), there is no static analyzer while for C there are some (well, kinda, not really)).
Let me word my point differently: I'm in a field where I must often be able to proof (and I mean formally, not some blabla-"checker" saying it's OK) that my code is correct. But that's just a small niche. Sure, it would desirable to have all code be 100% OK, but it's not a vital necessity for 98% of all code; desirable, yes, vitally necessary, no.
The problem I'm addressing here is that we can - and should - have code that is not ridiculously poor and lousy, that it shouldn't boil down to playing lottery when we, e.g. fire up an email server.
The current state is that we have very, very little reliable and safe code but a vast majority of code that isn't simply lousy but, in fact, so utterly fucking poor that we can not even make a tenable statement about it's quality. It's SO bad and sad,
That's what we are talking about. We are talking about e.g. an email server - that wasn't produced by a retard but by a capable professional - that ran for decades on millions of machines, that was the standard in a major linux distro and that had a 1-off error - and fucking nobody knew it.
Why? Why the fuck? Because all that code is written in a language that is cool, that I like many love, but a language that makes it extremely hard if not impossible to write reliable code. Simple as that.
And when I say hard, I mean hard. "Hard" as in To this very day we still have no tool that can automatically and reliably check C code. There are billions of lines of C code out there and while we can fly to the moon and have an (insane) AI robot (Sophia) we still fucking can't automatically check those billions of lines of C code.
I'll tell you two major reasons: a) C is an ambiguously specified language, hence inaccessible to automated verification, b) the halting problem is NP and so we can't dynamically test those billions of lines of code.
That's why, to name but one example, mozilla is investing heavily into Rust. What's Rust? It boils down to "Rust is 2345th attempt to create a better C". Btw. I picked Rust as example because it addresses i.a. one particularly nasty problem, namely memory safety. Unfortunately it ignores some other important points like for instance the fact that easy readability is by far more important than ease of writing. That's not just me saying that; there are plenty studies out there showing it again and again.
Pascal is somewhere in between. It's about as easy and about as fast as C and while it is certainly not adequate for high safety scenarios it's much much much better at creating the 99% of software that need not be 100% safe but shouldn't be ridiculously lousy and basically lotteries with loaded guns.
Do I personally like Pascal, "like" as in "enjoying development with it"? No. But maybe we should start anyway to think over the "it's fun" requirement. Frankly, fun we had and lots of it - and invariably sooner or later lots of pain, too. Maybe it's about time to look from an engineers perspective at software development.