Modern php is not bad actually. Still kinda slow and dangerous, but A LOT better than it used to be :')
That said, i wouldnt build a web service with php still lol
Also, JavaScript…why are you the way you are? Does anyone have advice for learning it so it makes sense? I can’t even get tutorial projects to run properly…
Because they didn’t want to train their JS developers and didn’t want to cause friction for new projects. They get to say they’re using TS, with basically none of the real advantages. (Apart from general rational error checking.)
And that probably requires not going with a tutorial. Because the JS ecosystem scorns at “simple”. Just make some HTML scaffold and use MDN to understand the DOM.
I like Douglas Crockford’s talks about the “good parts” of JavaScript. They’re old and probably a bit outdated, but he explain quite well the history and why JavaScript is the way like it is.
It clicked for me when I saw them the first time. Still hate JavaScript though.
What Crockford did was enable a lot of devs to realize there was a viable development platform built into the most prolific and open network client in the world. For that he should be commended but it should have never been taken as “this is a viable general purpose language”.
He also showed that JavaScript has more resemblance to functional programming languages rather than object oriented ones. If you try to treat it as an object oriented language like Java (like the seem to imply), you will have a bad time.
Can it even make sense tho? To me JS is an example of a not too good thing that people started too eagerly so now they’re trying to make it make sense.
I would argue that ASM isn’t “powerful”. It’s direct. You can access advanced features of a CPUs architecture with the trade off limited portability. Sometimes it’s necessary but power comes from being able to express complex control and data structures in a concise and readable amount of text.
The subjective topic of what “concise and readable” means is where the language wars come in.
When I hear powerful language, I think of languages that are good at intensive tasks like assembly, c, rust, Python (because of numpy, pandas, pyspark, cuda, etc.).
Sure, but there are good and bad frontends. JavaScript has a tendency to silently fly off the handle in mysterious ways due to the crazy type system. Python will typically fail more predictably, and is famously easy to write. I know nothing about FORTH, honestly.
if its acceptable to force javascript onto the backend and everywhere else, then why not write the frontend in rust, or anything else than can compile to wasm ?
Sorry, I’m not sure what your point is. I realize that you can almost completely avoid JavaScript, but the point I’m making is merely that there is a real technical limitation that limits the choices developers can make for front-end code, and although WASM is making great strides in breaking down that barrier (something I’ve been thrilled to see happen, but which is going much more slowly than I had hoped), the limitation is still there. Conversely, such a barrier has never existed on the backend, except in the sense that C limits what all other languages can do.
javascript is great for the frontend. not just because it’s the only choice, but it’s also a lot easier to write code for ui than say, C or rust.
however i do not see a reason why it needs to run on servers or desktop apps, bar a few cases. i know node is popular, but i think fullstack devs just like to have everything in the same language, even if it makes it harder to use and slower to run.
likewise C, rust, go, whatever, are great for backends, embedded etc, but they shouldnt be ran on in the browser, unless there is a specific reason like heavy computation with little dom interaction.
just because a barrier does not exist doesnt mean that we should write programs in a language not designed for the domain.
I’m honestly not convinced JavaScript is good even for the front-end, because it’s intentionally designed to swallow, ignore, and otherwise minimize errors; which is not helpful at all for development of any software. My point is that the only reason JavaScript is dominant in front-end development is that, prior to WASM, it was literally the only option; if that hadn’t been the case, I doubt it would have become nearly so widely used.
i actually agree, but i think its more the issue that modern websites are designed like desktop apps. having a weakly typed and flexible langauage like js is fine when youre only adding a little interactivity to an otherwise mostly functional website.
Yeah, but as far as I understand that’s not a C vulnerability. It wasn’t added. C just exposes how the underlying CPU works.
If you could avoid exposing dangerous memory quirks but still retain the same power… well, you’d have invented Rust. Rust is a better language than C, I agree with that.
Edit: Yep, just double checked. Buffers live in physical memory and have to be finite, so if you advance outside of them you’ll go somewhere else. Scanf’s not special, this is just another inherent pointer issue.
Okay, but how do you code on a CPU without directly interfacing the CPU at some point? Python and JavaScript both rely on things written in mid-level languages. There’s a difference between a bad tool and one that just has limitations inherent to the technology.
Like, to echo the meme a bit, it’s not a totally straight comparison. They have different roles.
Yes, also Rust. It wasn’t an option until recently though.
The times when C or C++ is worth it definitely isn’t always, but I’m not sure I’d class much of OS programming and all embedded and high-performance computing as small. If you have actual hard data about how big those applications are relative to others, I’d be interested.
Also, it’s a nitpick, but I’d personally say a footgun has to be unforeseeable, like literal shoe guns being added to a video game where guns were previously always visible. Once you understand pointers C is reasonably consistent, just hard and human-error-prone. The quirks follow from the general concepts the language is built on.
once you understand C++ the pitfalls of C++ are reasonably consistent
All of C++? That’s unreasonable, it’s even in the name that it’s very expansive. Yes, if you already know a thing, you won’t be surprised by it, that’s a tautology.
C is more than just pointers, obviously, but the vast majority of the difficulty there is pointers.
there are like what, 3 operating systems these days? assume those are all written entirely in c and combine them and compare that to all code ever written
Plus all previous operating systems, all supercomputer climate, physics and other science simulations, all the toaster and car and so on chips using bespoke operating systems because Linux won’t fit, every computer solving practical engineering or logistics problems numerically, renderers…
Basically, if your computational resources don’t vastly exceed the task to be done, C, Rust and friends are a good choice. If they do use whatever is easy to not fuck up, so maybe Python or Haskell.
All of C++? That's unreasonable, it's even in the name that it's very expansive.
similarly, "all of pointers" is unreasonable
"all of pointers" can have a lot of unexpected results
that's literally why java exists as a language, and is so popular
Plus all previous operating systems, all supercomputer climate, physics and other science simulations, all the toaster and car and so on chips using bespoke operating systems because Linux won't fit, every computer solving practical engineering or logistics problems numerically, renderers...
sure, and the quantity of code where true low-level access is actually required is still absolutely minuscule compared to that where it isn't
“all of pointers” can have a lot of unexpected results
How? They go where they point, or to NULL, and can be moved by arithmetic. If you move them where they shouldn’t go, bad things happen. If you deference NULL, bad things happen. That’s it.
sure, and the quantity of code where true low-level access is actually required is still absolutely minuscule compared to that where it isn’t
If you need to address physical memory or something, that’s a small subset of this for sure. It also just lacks the overhead other languages introduce, though. Climate simulations could be in Java or Haskell, but usually aren’t AFIAK.
How? They go where they point, or to NULL, and can be moved by arithmetic. If you move them where they shouldn't go, bad things happen. If you deference NULL, bad things happen. That's it.
I suppose if you treat scanf as a blackbox, then yeah, that would be confusing. If you know that it’s copying information into the buffer you gave it, obviously you cant fit more data into it than it’s sized for, and so the pointer must be wandering out of range.
Maybe C would be better without stdlib, in that sense. Like, obviously it would be harder to use, but you couldn’t possibly be surprised by a library function’s lack of safeness if there were none.
yeah i mean if you grok the underlying workings of scanf then there's no problem
i'd just argue that the problem is understanding what you need to understand is the problem with straight c, and with any language like c++ where you're liable to shoot thineself in thy foot
I’m wondering now how much you could add without introducing any footguns. I’d guess quite a bit, but I can’t really prove it. Smart pointers, at least, seem like the kind of thing that inevitably will have a catch, but you could read in and process text from a file more safely than that, just by implementing some kind of error handling.
True, but AFAIK they all sucked really bad. If you needed to make something that preformed back then you wrote in assembly.
FORTRAN might be a good counterexample. It’s pretty fast, and I’m not actually sure if it’s memory safe; it might be. But, it’s definitely very painful to work with, having had the displeasure.
That’s pure assumption and, as far as I can tell, not actually true. PASCAL was a strong contender. No language was competitive with handwritten assembly for several decades after C’s invention, and there’s no fundamental reason why PASCAL couldn’t benefit from intense compiler optimizations just as C has.
Here are some papers from before C “won”, a more recent article about how PASCAL “lost”, and a forum thread about what using PASCAL was actually like. None of them indicate a strong performance advantage for C.
Hmm, that’s really interesting. I went down a bit of a rabbit hole.
One thing you might not know is that the Soviets had their own, actually older version of C, the Адресный programming language, which also had pointers and higher-order pointers, and probably was memory-unsafe as a result (though even with some Russian, I can’t find anything conclusive). The thing I eventually ran into is that Pascal itself has pointer arithmetic, and so is vulnerable to the same kinds of errors. Maybe it was better than C, which is fascinating, but not that much better.
Off-topic, that Springer paper was also pretty neat, just because it sheds light on how people thought about programming in 1979. For example:
In the following, we shall
compare how “convenient” the languages are to code our favourite solution to a programming problem,
play the devil’s advocate, and try to list all possible things that can go wrong in a program expressed in a language.
Some of us, including myself, have reservations about the validity of the second technique for comparison, the most persuasive argument being that even though some of the features are potentially dangerous, people rarely use them in those contexts. There is certainly some truth in this, but until we have experimentally collected data convincingly demonstrating this, it is wiser to disbelieve it. Take note of the observed fact of increased difficulty in formally proving the properties of programs that use these potentially hazardous features in a safe way. This is one of the reasons behind the increased redundancy (and restrictions) of the newer languages like Alphard
I don’t see a lot of people denying that 2 is a good metric today. In fact, in the rare exceptions where someone has come right out and said it, I’ve suspected JS Stockholm syndrome was involved. Murphy’s law is very real when you not only have to write code, but debug and maintain it for decades as a large team, possibly with significant turnover. Early on they were still innocent of that, and so this almost reads like something a non-CS acedemic would write about programming.
Indeed, I had no idea there are multiple languages referred to as “APL”.
I feel like most people defending C++ resort to “people shouldn’t use those features that way”. 😅
As far as I can tell, pointer arithmetic was not originally part of PASCAL; it’s just included as an extension in many implementations, but not all. Delphi, the most common modern dialect, only has optional pointer arithmetic, and only in certain regions of the code, kind of like unsafe in Rust. There are also optional bounds checks in many (possibly most) dialects. And in any case, there are other ways in which C is unsafe.
I feel like most people defending C++ resort to “people shouldn’t use those features that way”. 😅
And yeah, I’m with you, that’s a shit argument. A language is a tool, it exists to make the task easier. If it makes it harder by leading you into situations that introduce subtle bugs, that’s not a good tool. Or at least, worse than an otherwise similar one that wouldn’t.
Without a super-detailed knowledge of the history and the alternative languages to go off of, my suspicion is that being unsafe is intrinsic to making a powerful mid-level language. Rust itself doesn’t solve the problem exactly, but does control flow analysis to prove memory safety in (restricted cases of) an otherwise unsafe situation. Every other language I’m aware of either has some form of a garbage collector at runtime or potential memory issues.
Damn the smoking at the desk must have been awful. Dont get me wrong, im a smoker and do enjoy a indoor cig every so often but sitting around it all the time cant be nice.
I know it’s wrong and that I’m going to Internet hell for admitting to it, but there’s a smell when Grandma would light her cigarette in the hot box car with the windows up that I find nostalgic to this day even though I find the concept of smoking in a car repugnant
The crazy thing is that it was so prevalent, I don’t really remember the world smelling smoky unless I went into a small room like my grandparents living room.
I didn’t notice it in places like restaurants and bars until after the bans came.
I would guess that my generation has a diminished sense of smell because of it.
I’m pretty sure I’ve done most of these at some point or another.
It really depends whether I like you or not.
Liking my users is entirely dependent on how much work you make me do, and how difficult that work becomes because of your personality.
I’ve gotten tickets that were literally “$thing is broken”, or “help! Call me!” With no information given, not even a callback number. I’ve also gotten a rambling voicemail, in which a user describes an issue with a piece of software and doesn’t identify themselves, not provide any callback information. The CID on the voicemail wasn’t available either, and since I work with several companies doing support, I couldn’t even identify the client, nevermind the specific user.
There’s also the needy users that create tickets for every prompt, dialog, message, delay… Pretty much anything that could happen at all ever, whether it affects their ability to do their work or not.
There’s also the unavailable users, they are not available ever, at any time, for any reason. I have literally gotten critical tickets which require me to access the users workstation to fix, while it is logged in as the user, and I could call less than 5 minutes after they create the ticket, and they’re busy. Email them and they have an out of the office message, or reply with something about them being in a meeting (with no information about when they will be free), or simply don’t reply at all. After a few weeks of trying to contact them to connect and resolve their very simple (but “critical”) issue and getting nowhere, close the ticket, only to be met with a flurry of emails from them about how the problem isn’t solved. Immediately call or reply and you get voicemail and silence.
Most of my users do fine, and it’s usually a minority that are troublemakers, and I want to make that clear… But the troublemakers are the driving force for me to find ways to fix pretty much every problem without ever opening their system though remote control. I can do all kinds of things from registry edits and hacks, to writing and scheduling PowerShell scripts to fix their shit every time they log in, and deploy that by a remote PowerShell command prompt, and nothing more.
Yeah William, you might be the c-whatever bullshit, but if the issue is sooo fucking critical, make five goddamned minutes for me to fix your shit or it’s not getting fixed. I don’t care if you own the goddamned planet, I can’t fix your shit without access.
There’s also the needy users that create tickets for every prompt, dialog, message, delay… Pretty much anything that could happen at all ever, whether it affects their ability to do their work or not.‘’
This could be weaponized incompetence. “Oh I keep having issues with my computer that interfere with my work, so I can’t work and IT is incompetent and can’t help me, look at all these tickets and how long IT takes. I just can’t get any work done!”
Oof, slow compile times to target, of all things, the JVM? Implicit methods? Some(null)? Function call syntax where the difference between a tuple argument and a sequence of non-tuple arguments can be determined by whether or not there’s a space before the parentheses?
There are definitely some major issues with Scala.
I think that’s good when the objective is to improve the language. One key thing that holds many languages back is that they’re stuck with historical baggage, and it can be pretty difficult to replace/remove “outdated” stuff without breaking everything.
I do not want to be stuck using Python 2, or Scala 2 (although there exist people who use Scala 2 instead of Scala 3).
Where I’m working we’re heavily using Spark, which kind of blocks us from upgrading. There seem to be ways to get Scala 3 to work, but we also have old terribly written baggage code no one understands. Just upgrading between 2.12 to 2.13 was a journey.
I agree that the slow compile times are pretty bad (maybe even deal-breakingly for large projects). I think it’s kind of necessary for a language with as powerful of a syntax as Scala though, it’s pretty absurd how expressive you can get. Maybe if it didn’t target the JVM, it’d be able to achieve way faster compile times – I don’t really see a point of even targeting JVM other than for library access (not to say that that isn’t a huge benefit), especially when it has relatively poor compatibility with other JVM languages and it’s nearly impossible to use for Android (don’t try this at home).
Even more so, I think that null handling isn’t nice – I wish it were more similar to Kotlin’s. One thing I’m really confused as to why Scala didn’t go all-in on is Either/Result like in Rust. Types like that exist, but Scala seems to mostly just encourages you to use exceptions for error propogation/handling rather than returning a Monad.
A more minor grudge I have is just the high-level primitive types in general – it’s pretty annoying not being able to specify unsigned integers or certain byte-width types by default, but if it really is an issue than it can be worked around. Also things like mutable pointers/references – I don’t actually know if you can do those in Scala… I’ve had many situations where it’d be useful to have such a thing. But that’s mostly because I was probably using Scala for things it’s not as cut out to do.
With the tuple arguments point, I get it but I haven’t found it much of an issue. I do wish it wasn’t that way and it consistently distinguished between a tuple and an argument list though, either that or make functions take arguments without tuples like in other functional languages or CLI languages (but that’d probably screw a lot of stuff up and make compile times even LONGER). I saw someone on r/ProgrammingLanguages a while back express how their language used commas/delimiters without any brackets to express an argument list.
I think an actually “perfect” language to me would basically just be Rust but with a bunch of the features that Scala adds – of course the significant functional aspect that Scala has (and the clearly superior lambda syntax), but also the significantly more powerful traits and OOP/OOP-like polymorphism. Scala is the only language that I can say I don’t feel anxious liberally using inheritance in, in fact I use inheritance in it constantly and I enjoy it. Scala’s “enum”/variant inheritance pattern is like Rust enums, but on crack. Obviously, Rust would never get inheritance, but I’ve found myself in multiple situations where I’m thinking “damn, it’s annoying that I have to treat <X trait> and <Y trait> as almost completely serparate”. It would especially be nice in certain situations with const generic traits that are basically variants of each other.
Plus, I’ve always personally liked function overloading and default arguments and variadics/variadic generics and stuff, but the Rust community generally seems to be against the former 2. I just really hate there being a hundred functions, all a sea of underscores and adjectives, that are basically the same thing but take different numbers of arguments or slightly different arguments.
The custom operators are a double-edged sword, I love them and always use them, but at the same time it can be unclear as to what they do without digging into documentation. I guess Haskell has a similar problem though, but I don’t think Scala allows you to specify operator precedence like Haskell does and it just relies on the first character’s precedence. I would still want them though.
How it goes now, though, is I use Scala 3 for project design/prototyping, scripting, and less performance-sensitive projects, and Rust for pretty much everything else (and anything involving graphics or web). Scala has good linear algebra tooling, but honestly I’ll usually use C++ or Python for that most of the time because they have better tooling (and possibly better performance). I would say R too, but matplotlib has completely replaced it for literally everything regarding math for me.
Sounds like we’re actually in agreement about most of this.
I’m okay with languages limiting their “expressive” power in order to provide stronger correctness guarantees or just limit how “weird” code looks; but this is largely because I’ve worked on many projects where someone had written a heap of difficult-to-understand code, and I doubt such limitations would be appealing if I were working strictly on my own.
I also don’t really see the appeal of Java-style inheritance, but to be honest I didn’t use Scala for long enough to know whether or not I agree that Scala does inheritance “right”.
It does make sense that Rust provides mutability in some cases where Scala doesn’t. Rust’s superpower, enabled by the borrow checker, is effectively “safe mutability.” I hope other, simpler languages build on this invention.
(Jokes aside, all programming languages have their good and bad things. Some just have more bad than good. And i say that as a C/C#/typescript/asm developer :p
Pretty much all of the command line coreutils programs I use daily are in C; cd, ls, pwd, touch, rm, etc. If I want to write some small utility I’ll usually reach for a scripting language first like bash python ruby etc, but if it needs to be small and fast I’ll use C instead.
Inertia is a mofo. I did embedded programming for industrial automation almost thirty years ago, building upon and expanding an existing nightmare of C code… and I bet there’s still some of mine running something out there to this day.
The thing with C is that it’s almost always going to be the fastest high-ish level language and it has an extremely stable ABI. Self contained code written 30 years ago will likely compile with only minor (and sometimes no) tweaks today. You’re lucky to go 3 years on C++ without something fairly big breaking due to changes in the underlying language and ABI.
This is a really good post about why C is so difficult to seriously consider replacing, or even to avoid by using a different language for certain projects: faultlore.com/blah/c-isnt-a-language/
It isn’t just a language, but it is a language - as it eventually gets around to saying, but it starts off by saying that it isn’t, then later corrects itself to say that it is, etc. I feel like the focus of this ignores the historical context of what C was written to be for - at the time there was like Assembly, BASIC, Fortran (?), other long-dead languages like was it A and/or A* or whatever, there was a B language too! (developed by Bell Labs, if Google can be trusted these days), etc. - and C was developed to be better than those. So saying that like it lacks type conversions is very much missing the point - those were not invented yet. A lawn mower also lacks those, but it’s okay bc it doesn’t need them:-) I am probably nit-picking far too many points, I suppose to illustrate that the style of the article became a hindrance to me to read it b/c of those reasons. But thank you for sharing regardless.
I don’t really like the title either, but the article does demonstrate how unfortunate it is that we’re effectively locked in to using the ABI at some level of nearly every piece of software.
That said, there definitely were languages with better type systems prior to the invention of C. Pascal is a frequently-cited example.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.