What do we think about JavaScript?

Like it or not, it seems like JavaScript is taking the world by storm.

Everyone needs a website nowadays so you can't escape it on the browser and through the magic of Google's JS engine, V8, JS is now being used in production and by hobbyists alike for managing HTTP servers.

I work with JS all day and it's a pretty good language. Node's a really good choice for implementing a HTTP server because it threads your application in the way that you want it to be threaded in the first place. The serial nature of the event loop also allows for certain assumptions and guarantees to be made.

But I equally find myself dealing with its absurd lack of exceptions and tendencies towards "stringing" everything out. Not to mention, deal with JSON soup is a nightmare.

I've mentioned it before, but I really dislike Javascript since it's a dynamic language, lacks object orientation, no exceptions and treats everything that doesn't exist as null or whatever. Javascript is good for nothing but an intermediate language, and it fails horribly even at that. Javascript is the bane of every web. Don't use it. It's horrible to code in and it sucks cpu cycles from simple web pages that overuses it, killing battery life.

Quote:

---

Originally Posted by Elysia

I really dislike Javascript since (it) lacks object orientation

---

But Javascript does have built-in support for object oriented programming, just that it does so without explicit classes via its odd but nonetheless valid prototype approach.

It may be valid, but it's at odds with how every other language does it. Frankly, in my humble opinion, I don't like it.

I like the language, but debugging can be frustrating.
Especially when your code is N levels deep in callbacks, which seems to be a very common style.
I really should invest time learning how to properly use the developer tools the browsers provide. That might take away some of the pain, but I don't do web stuff often enough to warrant that.

I dislike it. Strongly. In fact, I hate it. Hate as in hate, not as in dislike. But the reason I hate it is not not because I hate it. But because I hate the fact there are no alternatives to it. The client development ecosystem for the web is almost completely tied to this single language that evolves erratically through the different requirements of millions of developers while extending its library in a chaotic manner to answer the whims of whatever is the the new cool thing in web development. And we will one day pay a dear price for this complacency. Javascript is the enemy that you have to share a bed with.

Web browser vendors are ultimately to blame for this. Every time someone tries to come up with something new, they will take their sweet time to offer support (if they ever will), perpetuating the dependency on javascript and removing any motivation for new and improved languages. And for this reason, web client-side scripting is today one of the ugliest looking, chaotic and nightmarish codebases out there. Looking at a .js file is like looking at the future of a race that decided they didn't want to evolve anymore and adopted pop culture as their everlasting legacy. A bad language that never improved over time and that people just build colorful "plugins" around with colorful names that do colorful things and help finance an whole industry of trainers, educators and book writers along with their publishers. Javascript is the PHP of client-side scripting.

You asked, I answered.

Quote:

---

Originally Posted by Mario F.

I dislike it. Strongly. In fact, I hate it. Hate as in hate, not as in dislike. But the reason I hate it is not not because I hate it. But because I hate the fact there are no alternatives to it. The client development ecosystem for the web is almost completely tied to this single language that evolves erratically through the different requirements of millions of developers while extending its library in a chaotic manner to answer the whims of whatever is the the new cool thing in web development. And we will one day pay a dear price for this complacency. Javascript is the enemy that you have to share a bed with.

Web browser vendors are ultimately to blame for this. Every time someone tries to come up with something new, they will take their sweet time to offer support (if they ever will), perpetuating the dependency on javascript and removing any motivation for new and improved languages. And for this reason, web client-side scripting is today one of the ugliest looking, chaotic and nightmarish codebases out there. Looking at a .js file is like looking at the future of a race that decided they didn't want to evolve anymore and adopted pop culture as their everlasting legacy. A bad language that never improved over time and that people just build colorful "plugins" around with colorful names that do colorful things and help finance an whole industry of trainers, educators and book writers along with their publishers. Javascript is the PHP of client-side scripting.

You asked, I answered.

---

TBH, the entire stack of web technologies is a complete disaster, Javascript is just one part of it. Even if Javascript was amazing and perfect, CSS would still be horrific, HTML still terrible, and HTTP too limiting.

Everyone involved in the evolution of the web who could have stood up and said "Stop! We've gone far enough in this crazy direction!" but did not, should be deeply ashamed.

Quote:

---

Originally Posted by brewbuck

TBH, the entire stack of web technologies is a complete disaster, Javascript is just one part of it. Even if Javascript was amazing and perfect, CSS would still be horrific, HTML still terrible, and HTTP too limiting.

Everyone involved in the evolution of the web who could have stood up and said "Stop! We've gone far enough in this crazy direction!" but did not, should be deeply ashamed.

---

This is pretty much my feeling. I don't really like anything associated with webdev. It's my weakest point as far as programming goes because I try to avoid it like the plague. Dealing with the nightmare of CSS, and the Javascript differences between browsers for a few months at a previous job was enough to shy me away forever. Side note, the way divs work in HTML has never really made good sense to me. Things would be a lot better if you could do things in a GUI grid manner, as with Tkinter.

O_o

I like the Javascript language fine, and a few features which have been seriously discussed could see me moving to Javascript for most development.

However, I am specifically referring to the language. The standard library and DOM related components are, being generous, obnoxious cruft.

Soma

Web Assembly is just over the horizon, and it's likely that there will be tools that compile real languages into Web Assembly, reducing the world's dependence on JS.

I did at a professional level for almost 15 years. A time when ASP.Net was all the rage and ColdFusion this new kid on the block. When client-side cripting was practically non existing. I saw the CoffeeCup Editor taking the world by storm, followed by Dreamweaver. Moved into PHP, witnessed the birth of 3 CSS versions and the struggle to make HTML 4 a widely used standard. Witnessed the birth of Ajax and how it brought javascript from the ashes as Microsoft unwillingly contributed to its widespread use. I remember when Javascript was accused of being a poorly developed language and the major contributor to browser incompatibility. The latter has indeed changed, but people seem to have forgotten the former.

For almost 15 years, I breathed the poisonous fumes of web development, server and client side. I have no wish of going back. It would be like going back to prison.

Quote:

---

Originally Posted by phantomotap

O_o

I like the Javascript language fine, and a few features which have been seriously discussed could see me moving to Javascript for most development.

---

This is kind of how I feel.

I didn't really appreciate the beauty of JavaScript until they introduced generators and then I really fell in love with it once the library "co" was written.

Honestly, the async code that I've written looks absurdly awesome but that might also be because I've never really played with a language that supports generators, let alone full coroutines. And even then, it's not like generators or coroutines are even unique to JS, they just happened to port them over.

I like the C-style syntax and I appreciate the degrees to which you can implement functional programming concepts.

But there's very many silly things that JS does that I feel keeps it from being a true powerhouse, such as it's allowance of comparing a string to a date object or a number to a string without so much as a warning, it just evaluates to false. This leads to bugs that are incredibly hard to track down.

Quote:

---

Originally Posted by Mario F.

For almost 15 years, I breathed the poisonous fumes of web development, server and client side. I have no wish of going back. It would be like going back to prison.

---

There's pretty robust front-end frameworks that can help mitigate a lot of the front-end toxicity. Ampersand is a pretty good one. It's object-oriented and declarative. Its implementation of types isn't half-bad either and really plays well to a C++ developer's natural thinking.

But there are times that I've found myself completely eschewing the framework and just doing some jQuery stuff myself so I guess that means about as much as that does lol.

I dunno. I use it extensively for web dev.

On the plus side, I do like being able to make object and array literals. Prototype-based inheritance at first was a tricky paradigm to wrap my head around but it's grown on me.

On the down side, I don't like the weak typing and I don't like some of the downstream effects of this structure, though - mainly, how spotty IntelliSense and such tools are. I tend to spend a lot more time reading API documentation because my development environment can't always present this information to me inline as I need it. This is certainly not new; I learned development in the days before IntelliSense existed, but it's a great time-saver that I really find I miss when it's not working reliably.

Wat —
Destroy All Software Talks

I need a like button for that.

Quote:

---

Originally Posted by Yarin

Wat —
Destroy All Software Talks

---

Awesome.

Yeah, that was some of the nonsensical stuff I was alluding too earlier. It's not actually all that funny when it's a real problem in your codebase.

Okay, that's a lie. It's still funny.

Why are we doing web asm again? Are we certain we don't hate the world? The Birth & Death of JavaScript —
Destroy All Software Talks

My favorite talk of his is "A(n) Brave New World". He captures perfectly the current software development culture that has been plaguing us for 20 years or so. The tremendous lack of innovation, the false memes that have been corrupting our thinking and eroding our computer quality of life, the constant vertical growing of a software development ecosystem dependency tree that can't shave off its legacy root nodes and replace them altogether with something entirely new.

It goes to the core of why I no longer find pleasure in programming. A culture that I can no longer respect or feel I want to be a part of. Software development is a victim of its own success. As it became increasingly widespread, it became a culture of the masses; and with this, absorbed all the trappings of popular culture.

A month ago we were introduced here on CBoard to a new code editor. I immediately criticized for its lack of anything even resembling innovation. It is just another executable file no one really needs, that doesn't bring anything that we haven't already. And what we have already is nothing like we have been asking. In a few minutes Gary describes an editor that would be a dream to any developer. But it won't be made (that talk is 4 years old). It can't be made because not only it lacks the software infrastructure to support it, despite computers being more than able to render and execute all of its functionality and modern CPUs capable of handling its complexity and performance demands, but also because even if we ignored the terminal requirements and developed it for a GUI, no one is interested in making it as they keep distracting themselves with making code editors with mind numbing keyboard combos and cute syntax highlighting.

This is really a Seth Godin's world. Spending 1 or 2 years not writing a single line of code (because innovation takes thinking), just hammering your brain down coming up with a code editor that _really_ solves software development problems is just not how we do software anymore. Keyboard combos, syntax highlighting and cool dark themes is what allows us to ship our software fast and ship often. Such is the sorry state of our pop culture of software development. And so we elevate to the status of divinity, such repugnant things as the Sublime Editor. And with it, we create and worship a pantheon of false gods.

And I'm sure Seth's proud also of programming languages development over the years. We haven't improved. We have done _nothing_ to facilitate the engineering task that is software development. We ship software languages fast and ship often. They are born like mushrooms resembling all others that already exist and pretending they are better and solve our problems. But our _real_ problems stay unsolved. Because we surround ourselves precisely with all sorts of principles, building huge and complex rules on best practices and code correctness and good paradigms, forgetting that is precisely the _real_ problem of software development that we are begging to be solved. And it can only be the language that can implementing and enforce these rules. But no way that will happen. A programming language that acts responsibly towards the computer but also towards the programmer isn't going to be developed in this culture. And so programming is an absurdly difficult task and a miserable activity of constant peer checking and the consequent humiliation of public exposure to ridicule, because no one can possibly adopt all the rules.

---

I am probably not intelligent enough to have come up with those things I wish in this post. But I will never know. Now it is too late. I went too fast through academia (big mistake) and straight into the job market, where for all my sins I spent too much time strapped to poor languages and no time for sitting under a tree and thinking about what I really wanted and why what I was doing was utter nonsense. Maybe, if my early choices hadn't been so bad and I had thought more carefully about my career, I would have been discussing things like Gary's editor in the first person.

But I see myself in every fresh graduate in this day and age. Graduates completely blind to the neon lights of modern computer programming, lacking any incentive or even the realization there is a need to change the landscape of software development and that things are bad, very bad. Not great and shiny as the pop community will want them to believe.

Mario, can you please expand on some of these issues plaguing the industry? I feel like JS epitomizes a lot of the false prophets and hype. Though Node is pretty cool at times, it's not the Holy Grail people tout it to be.

Quote:

---

Originally Posted by Mario F.

In a few minutes Gary describes an editor that would be a dream to any developer.

---

Link? I can't find this talk.

Quote:

---

Originally Posted by Mario F.

And so we elevate to the status of divinity, such repugnant things as the Sublime Editor.

---

Indeed. People need to accept Vim as the one true editor.

Quote:

---

Originally Posted by Yarin

Link? I can't find this talk.

---

I couldn't find it either. I watched it a long time ago and turns out I only thought I knew its title. It's called "A(n) Whole New World": A Whole New World —
Destroy All Software Talks

Quote:

---

Originally Posted by Yarin

Indeed. People need to accept Vim as the one true editor.

---

Another piece of useless crap. Yes, you can type fast in it. Great! That will not solve many coding problems, but you can write cheap lousy novels in it faster than Stephen King can publish them. *two thumbs up*
Note: I know you was being sarcastic ;)

@Mutant: Will reply later, mate.

Quote:

---

Originally Posted by MutantJohn

Mario, can you please expand on some of these issues plaguing the industry? I feel like JS epitomizes a lot of the false prophets and hype. Though Node is pretty cool at times, it's not the Holy Grail people tout it to be.

---

I addressed two different things in my post. I think you are asking specifically about programming languages.

The landscape of software development languages hasn't changed much with the years and we haven't been given anything concretely new that isn't just a rehash of existing ideas. Programming paradigms haven't evolved. They were almost all invented back in the 60s and 70s and nothing substantially new and influential has emerged since. Granted, this is likely one one area of research with a limited domain (you can only go as far), but programing paradigms are one of the most determining factors of a language identity, which results in languages offering the same paradigm being essentially the same.

It's true that the syntax and the semantics of a language also differentiate languages. And some of these syntaxes and semantics make one language visually and structurally very distinct from another. But syntax and semantics alone don't solve the programming challenges that programming paradigms present. Every programming paradigm in software development is essentially a contract between a proposed method of solving computing problems on one hand, and the challenges that proposed method presents to the user on the other hand. There's no free lunch. No perfect solution to software development.

I accept that contract. I don't question the obvious limitations of our still infant computer technology and the impact this has on our ability to make them perform tasks. But I do question certain choices:

1) Development Tools
Lack of imagination, a certain conformism, the tendency of software developers to become copycats, a moronic shipping culture, this and more has been leading to lack of any real useful tools for software development that can mitigate or facilitate transposing the challenges offered by programming paradigms. For pete's sake, we don't need another code highlighting editor! What on earth are these people thinking. Imagine the waste that is spending 3 or 4 years of your short life building and maintaining something that introduces nothing new into the world and that is exactly the same as hundreds of others and then pretending you are actually doing something useful for others to use.

What we need is specialized tools. We need the sort of innovative thinking that brought us tools like TeamWare that inspired BitKeeper and paved the road to Mercurial and git. We need tools like syntax highlighting for sure, but they have been invented already. We need problem solvers. Tools that solve our current problems. Gary gave some examples in that video, like source file tracing in real time.

2) Engineering Programming Languages
You don't generally solve complex problems with simple tools. Complex problems require complex solutions. And unless you are working in a programming language tailored to solved complex problems, your ability to solve those problems in any other language becomes exponentially more difficult. Programming languages are being designed today as generic tools to solve a wide array of problem domains and targeting the mass market of developers; from hobbiest programmers to software engineers. What can possible go wrong with this idea?

We need engineered computer languages for software engineers. They won't be afraid of using specialized languages for specialized problems. I'm not talking of semi-specialized languages like Prolog or R. We need to cater to industries specifically, and build domain languages that can handle their specific problems. Not "force" the NY Stock Exchange to use Python, but offer the stock exchange industry a specialized language that would make them never again consider a multi-paradigm language as an actual solution to their computing needs. Multi-paradigm and domain-generic languages can never be good solutions to complex problems without a tremendous cost in development and maintenance and all the risks associated.

Would this spread too thin the programming language ecosystem and force software engineers and developers to increase even more their knowledge base? Not every representative of an industry would need to use these engineered languages, only those for whom their problems demand their use. But for them the solution to their problems would exist in the form of a much more correct tool for the task.

Remember the mantra we keep on repeating that it's of no use to compare one language to another and we should instead just use the right language for the right job? Have you ever wondered that the right tool for most tasks is in fact any of the tens of languages currently available to us, and there is in fact no such distinction as the "right language for the job"? Well, that's because we haven't been building those languages that can actually make a difference.

3) Stale culture
Languages like Javascript really represent this primitive hunter-gatherer culture in software development that is repressing research into better solutions. A programing language, which only half of it can be used, has become a centerpiece of modern software development. A language that cannot solve any problem well, as become a language that today solves a vast array of different problems on both client and server machines. A language that should have never survived past its first year due to the unanimous criticism it received, has since become a massively used language around the world despite none of its upgrades ever solved any of the criticism.

Javascript can't be used to create monolithic solutions or it will crumble under its own weight. And javascript can't be used as micro services or it will become impossible to maintain. And yet, you see it being developed either way by software developers who will gladly drink the Kool-Aid of the day. To be fair, for lack of other solutions.

Javascript is just one representative of a stale culture that on one hand pretends to be all about change when Microsoft decides to make their toolbar monocromatic, or Gnome decides to make their DE work on cellphones, while ridiculing anyone who would prefer for these non essential things to stay the same. But that at the same time is completely incapable of coming up or accepting new solutions to essential tools that have become part of the establishment. Tools like javascript or the VT-100 terminal. Provenly bad, or ancient and just plain incapacitating, tools that unnecessarily complicate our lives and just delay the adoption of better solutions.

These are the top nodes in the hierarchy of the software development ecosystem. From where all the other crap flows. And they should be replaced. But never are. And so, we are still today writing bash scripts in a verbose cryptic language, limiting a terminal window to 256 colors in the 21st century and incapable of rendering even vector images that pseudo-terminal systems like arcade machines and early consoles where doing in the 70s, or... doing whatever horrible nonsense you people do on javascript each day and that no one really needs to enjoy a modern web.

Mario, you've given me so much to think about!

Embedded domain specific languages. You mention creating languages that exist to solve one problem and one problem well. Well, that's only realistically feasible if we design a language that allows you write your own language in it. This is possible in many different languages but the overarching paradigm of the language itself can't help but bleed into the design of EDSL and this is oftentimes not a good thing. At all. But a language that helps you write EDSLs would be what you want. A language that allows you to fix it as you see fit.

I must come clean though, Mario. I'm slightly hypocritical. I agree with you but my meshing is nothing new. It's been solved before. The real goal is to just solve it faster now. But it's incredibly fun. And rewarding. Learning CUDA was one of the best things I've ever done and it's because it really shaped how I thought about programming in general. Parallelizing algorithms does not create a brand new algorithm, it just creates one that solves it faster. But, man, is it fun.

So there's value in re-implementing current technology. But there's a point of diminishing returns and I can sense that you feel like we're approaching that point. That's fair enough. I wish I was clever enough I could play a part in it but eh, I'm just gonna play with triangles.

Edit:

I laughed when I found out that the editor was a lie. I was so excited for a second too. I was like, "Oh man, I am so downloading this once this video is over." Talk about heartbreak. Someone should still implement something like that.

Quote:

---

Originally Posted by Mario F.

I couldn't find it either. I watched it a long time ago and turns out I only thought I knew its title. It's called "A(n) Whole New World": A Whole New World —
Destroy All Software Talks

---

I dunno, I disagree with quite a bit of this. Sure, there are some cool ideas there, but I think he's as guilty as anyone of doing exactly what he preaches against. Making this hypothetical editor a terminal rather than an IDE is a choice that would seem to be driven more by doing things 'the way he always does it' rather than because it's the right tool for the job. I think it's a great example of the very legacy burden he wants to get rid of.

Some of his ideas are interesting, but many of them are already commonplace in modern IDEs (support for diff visualization, dependency mapping, etc.) and some of this seems like he's pushing for niche features at the expense of day-to-day. For example, although I can get a dependency map in my IDE with a few clicks, the number of times I really have a need for one is trivially small compared to the number of times I have a need for a breakpoint in a debugger. I can't imagine using a tool that made dependency mapping slightly easier at the expense of not having an integrated debugger.

The error overlay is a genuinely cool concept. I think the even better focus is on tools to help proactively avoid errors versus making them easier to troubleshoot later, but since the latter will never catch everything for everybody, there will always need to be recourse to the former.

On shipping, I think there's often too little emphasis on it. Sure, some people push shoddy stuff out the door, but I see more projects get mired down in development hell, scope creep, or woefully overarchitected solutions (inner platform effect, etc.) because people weren't given the right level of constraints. Having target ship dates that it is expected you must meet can, in my experience, often lead to better code, not worse. Clearly there is a balance to be struck, and in the face of some kinds of issues shipping dates genuinely should be delayed, but I think not shipping fast enough is at least as common as shipping things too fast.

And, of course, you're designing a product for people to meet a need. Every day you go without shipping your product is one day when that need is not being met by you. It might also mean the need becomes met by a competitor first.

He doesn't care one bit about the editor, Cat. That's just his analogy for a different type of terminal, which is what he is actually arguing for. The editor just represents one possible type of application if we where to once and for all get move away from the VT-100 standard. If you watch his screencasts (unfortunately they come with a price tag), you'll see he is as much a GUI person as you and me, with the terminal being our goto solution for more complex administration tasks.

I agree that shipping is a complex subject. But I disagree that the industry isn't being heavily influenced by Seth's ideology. You seem to believe things are more balanced. But what I see is an alarmingly growing tendency of both the commercial and open source industries to pre-ship their products and fix the errors after launch. We've come to accept bugs and incomplete features as a normal part of production software. This in itself isn't wrong. They indeed are a normal part of production status software. But most definitely not at the present scale.

I also agree that certain markets may change the rules. In particular competitive markets. But the notion is widespread across the whole industry, not just those serving specific markets, and we even come to accept Continuous Integration as a fine practice for projects that don't or shouldn't really benefit from it. We are effectively merging the release and master branches. For what benefit, I don't know. All I see in any projects that implement CI is bug creeping, as rarely a CI project will implement proper testing (because integration tests are difficult and not for everyone, despite CI being easy to implement and for anyone).

Meanwhile there is a whole lot to be said about competitive markets, and how "competitive" they really are. In particular among the Open Source community, where a whole lot of damage is being done to FOSS code quality. I'm certainly not a shipping minimalist. Despite my speech so far probably indicating that's where I stand, it is not. I'm just calling out against the maximalist side and have yet to present what I consider a more levelled approach. I certainly am opposed to over-engineering or the idea of near-perfect releases. But there is no doubt in my mind, that for the largest part of the commercial and open source industries serving consumer-grade software, competition isn't a business driving factor and we could all have benefited from better tested software without gaining a feeling of loss because the next version took 12 more months to ship. Often, the aggravation of bugged software and incomplete features that no one can use effectively and end up just bloating the software for the next two or three versions is what drives people insane. Not the fact they couldn't do something and need to wait some more time before they can.

Quote:

---

Originally Posted by laserlight

But Javascript does have built-in support for object oriented programming, just that it does so without explicit classes via its odd but nonetheless valid prototype approach.

---

Yes, Javascript was inspired by (read: ripped off ideas from) Self, which is a pure "object oriented" programming language.

Languages such as Self and Smalltalk were invented before other languages such as C++ and Java, etc., decided to enforce the "class-based" approach to organizing objects. However, using the class based approach vs. the prototype approach has, like any other design decision, its advantages and disadvantages. Of course, its beyond the scope of this thread to go into a full discussion of these, but suffice to say that the prototype based object approach is not wrong and the class-based approach is not right. Either can be used to express the same ideas.. "Expressiveness" and "verbosity" are subjective terms, after all.

What I don't like about JS is that it snippets, once appended onto web pages execute on client servers immediately and therefore can also be used to exploit the user's system. While a certain restriction is set by modern web standards on browsers, malicious code can still be executed complying with the restrictions set.

Quote:

---

Originally Posted by Elysia

It may be valid, but it's at odds with how every other language does it. Frankly, in my humble opinion, I don't like it.

---

This is false and a very bad reason, taken alone, for anyone to dislike Javascript.

What does "every other language" entail? The typical programmer's bread-and-butter language such as C++, Java, which enforce a class-based object hierarchy?

The only reason why an enforced "class-based" approach might be better is because more programmers have been indoctrinated to this way of thinking and therefore can be more productive in the workplace. This fact, however, cannot be used as a reason to say its "at odds with every other programming language."

That said, I do think Javascript mostly sucks.. just as I think most programming languages suck.. try googling "why <programming language X> sucks" for example. You'll find a lot of weird ........ that just makes no sense embedded in Javascript's design.. In fact, I would venture to say that a language's suckiness is directly proportional to the number of people who use it. Of course, however, as a member of this board, I reserve a special place for C (and NOT C++) as the simplest language that models current hardware.

Quote:

---

Originally Posted by MacNilly

I reserve a special place for C (and NOT C++) as the simplest language that models current hardware.

---

By that logic JavaScript models the ecosystem available in a current web browser rather well.

Quote:

---

Originally Posted by MacNilly

...I reserve a special place for C (and NOT C++) as the simplest language that models current hardware.

---

I reserve C++ as the best practical language that models the current hardware. C is just too simple to meet modern needs.

Quote:

---

Originally Posted by manasij7479

By that logic JavaScript models the ecosystem available in a current web browser rather well.

---

There's no denying that for the foreseeable future, I agree.. Although I was not trying to compare C with Javascript. I think each has become more or less a domain specific language: C for systems programming (although C++ is just as good there) and Javascript for the browser.

I thought C's greatest advantage and why it is great is because it provides a nice abstraction over the assembly languages of different physical machines -- which are pretty similiar, after all, and this is what allows the abstraction to work.. I have heard that Javascript offers abstraction over different browsers.

Quote:

---

Originally Posted by Elysia

I reserve C++ as the best practical language that models the current hardware. C is just too simple to meet modern needs.

---

What does that even mean, modeling the current hardware? I understand you always take extreme sides on all things in life, a behavior you may learn to control when you decide one day to actually learn anything about programming. But at least when you take your usual extreme bias and force it down our throats, do it with something that is actually thought provoking and worth of a debate, and not another bash-on-Elysia post. You make an easy target with your bs nonsense, but it gets tiring over the years. At least surprise us with something worth our time.

On point, standard C++ is obviously not even close to model hardware. As an higher level language you shouldn't even put it in those terms. It's an abstraction, a high level abstraction, and it stays clear from the hardware systems it depends and operates on as best as it can. It's for this reason that standard C++ memory management is NOT even close to being a model of the kernel memory management, or why accessing the various hardware resources is made as transparent to the developer as it can be made in the context and semantics of the language. For that matter standard C is slightly lower level, closer to the machine if you will, because it lacks many of the semantics and language constructs that allow C++ to increase its high abstraction level; contradicting your assumption that standard C is too simple. Obviously C is a more complex language from the point of view of the developer for the reasons mentioned above. And it is for this reason among others C remains a valuable language, especially in the development of the lower layers of the operating system and many of the top layer utilities too.

And thank goodness C++ is what it is. Because you, of all people, wouldn't want a language that was nothing more than a C clone. You'd be out of any idiotic bs to shout when carrying your flag and everyone else would be left with a language they had no use for.

Quote:

---

Originally Posted by Mario F.

What does that even mean, modeling the current hardware?

---

That was a stab on "C modelling the current hardware".

Quote:

---

Originally Posted by Mario F.

At least surprise us with something worth our time.

---

You don't need to read them. This is not a forum where I have present homework, facts or research. I have no obligation to help or satisfy anyone or make any effort to do so. Don't expect that of me.

I don't know exactly what you mean by "standard C++." True, in today's world, we want to stray away from the hardware with higher-level abstractions as possible, and that sometimes just doesn't work in places like kernels. But that doesn't take away the fact that C++ can be just a better C. Replace malloc with new, use RAII, don't use exceptions, replace macros with templates and you've pretty much got just a better C. And just as close to the metal as C is. C++ was not designed to be a new Java or C#. It was designed to be close to the metal while offering high-level abstractions. And that is why it's more practical then C, because it offers more tools in the toolbox. Therefore, when you can use C++ over C, you should opt to do so. That is my opinion, and that is why I made a stab at that post.

Quote:

---

Originally Posted by Elysia

You don't need to read them. This is not a forum where I have present homework, facts or research. I have no obligation to help or satisfy anyone or make any effort to do so. Don't expect that of me.

---

This is not a forum either in which you are forced to say something stupid. Talk is cheap, and free. But you don't need to say anything. And many people will thank you when you shut up if you don't care for such things as facts or research, just because you can't stand to be quiet when in your whole ignorance you think you spotted another opportunity to bash at a programming language other than C++.

Learn to develop software and then you can talk all you want.

Quote:

---

For that matter standard C is slightly lower level, closer to the machine if you will, because it lacks many of the semantics and language constructs that allow C++ to increase its high abstraction level; contradicting your assumption that standard C is too simple.

---

O_o

I honestly can't figure out what you are on about.

You are free to agree or disagree with Elysia at your leisure, but I think you have simply misinterpreted the statement.

I think the point is that C is "too simple" because it lacks the mechanisms, the "language constructs", which are required for a "practical" language.

*shrug*

I don't agree with "too simple" or "practical", but I certainly wouldn't use C for anything unless I absolutely had to use the C language.

I'm fully aware that plenty of people have said the same thing about the C++ language, but I'm not going to give up on strong generics and RAII for the opinions of other people.

Quote:

---

Obviously C is a more complex language from the point of view of the developer for the reasons mentioned above. And it is for this reason among others C remains a valuable language, especially in the development of the lower layers of the operating system and many of the top layer utilities too.

---

o_O

The C language remains valuable because of complexity in regarding the lack of mechanisms which can express greater abstractions?

Soma

Quote:

---

Originally Posted by Mario F.

This is not a forum either in which you are forced to say something stupid. Talk is cheap, and free. But you don't need to say anything. And many people will thank you when you shut up if you don't care for such things as facts or research, just because you can't stand to be quiet when in your whole ignorance you think you spotted another opportunity to bash at a programming language other than C++.

Learn to develop software and then you can talk all you want.

---

I am not you. I can't "learn" to become your "learn to develop software." I don't know what you consider "learn to develop software." I can't live up to your standards, because I don't know where your standards are or where I am going wrong with my own standards compared to yours.

I don't butt in in conversations I don't think I have nothing to say. You have lots to say about Brexit. I have not, so I don't comment on that. But I DID feel like I could say something about a specific reply that, to me, didn't seem like something I just made up. Because within my experience, it seemed like an informed reply.

Quote:

---

Originally Posted by phantomotap

I think the point is that C is "too simple" because it lacks the mechanisms, the "language constructs", which are required for a "practical" language.

---

Didn't ever considered it that way. And still don't. The quote was "I reserve C++ as the best practical language that models the current hardware. C is just too simple to meet modern needs."
To me the second sentence is meant as a continuation of the first. Why else would it be there without explaining it further?

Anyways,

Quote:

---

Originally Posted by phantomotap

The C language remains valuable because of complexity in regarding the lack of mechanisms which can express greater abstractions?

---

Yes, because those abstractions come with a price in the footprint they leave behind.
C is arguably a more complex language because it doesn't share the abstractions C++ introduced to simplify the task of programming. But this is comparable complexity. C is just generally more complex than C++ if both languages are to code the same system. But the different footprint both languages will leave behind can have a significant impact on the decision to choose one or the other. And those decisions have been made many times before. And will keep being made.

Everything usually comes with a price. And abstractions meant to facilitate programming models can only go so far before they start imposing a penalty on the machine resources. It's fine that you wouldn't think using C unless you have no other option. Sometimes you will have no other option. And that's when you find the space the C programming language still has in the programming world.

Quote:

---

Originally Posted by Elysia

I am not you. I can't "learn" to become your "learn to develop software." I don't know what you consider "learn to develop software."

---

I did come too rough. I apologize. But frankly I am tired of hearing the opinion of someone who always has strong opinions on things that he doesn't plan to learn about or use in any kind of capacity that would actually empower him with such opinions. That's what maddens me about you and your opinions. By learning to develop, I mean learn to *actually* develop, by programming in more than one programming language and using them on a regular basis for long enough to actually be able to construct your opinions on them. It's no wonder that your opinions on things like C or Linux are always so devoid of clear and precise arguments. It's because you just can't have well formulated opinions on things you never cared to use or learn about, but still insist on never letting go a chance to bring your uninformed bias about.

I think MacNilly means rather that C is close to the hardware in the sense that you could insert assembly code or understand what the assembly would look like from C code. Elysia was just being contrarian. He might be right in a sense because many C++ compilers let you embed assembly, if you have something beautiful to run.

If he can look at a C++ program and see assembler intuitively, bravo to him, but I think it's a lie. I doubt Elysia of all people would find that useful even if he understood assembly in detail.

If that's not what you guys meant then I'm sorry, you lost me.

Quote:

---

To me the second sentence is meant as a continuation of the first.

---

O_o

Indeed.

"I reserve a special place for C++ as the most practical language because C is just too simple for modern needs."

*shrug*

Whatever.

Quote:

---

C is arguably a more complex language because it doesn't share the abstractions C++ introduced to simplify the task of programming.

---

Are you sure you'd like to make that claim?

I've seen you rant at least a few times of the, let's say, impenetrable nature of C++ generics as expressed with templates.

I admit that proper macro magic isn't exactly simple, but my deepest code makes people mad... as in looking upon the face of Cthulhu.

My point is that, unless you are simply using existing code, a project may indeed use all mechanisms offered by the C++ language.

Of course, proper macro magic is as simple to use as proper generics so complexity remains hidden if you are talking of only using existing code.

Quote:

---

Everything usually comes with a price.

---

Certainly.

Quote:

---

And that's when you find the space the C programming language still has in the programming world.

---

For me, the situation you are referencing is literally either "someone has paid me" and "an important project uses only the C language". I think that C has value because of the innumerable important projects which use the C language, and I think that C has value because a lot of brilliant minds think C has value thus continue to use the C language for new projects. In other words, I don't think C has any value because of a lack of mechanisms useful for expressing abstractions or any nearness of the metal.

Soma

Quote:

---

Originally Posted by Mario F.

C is arguably a more complex language

---

I disagree. C is a simpler language, and as a result, requires that code written in C is more complex than that written in C++. It's a fine distinction, but it's a valid one, nonetheless.

Quote:

---

Originally Posted by Mario F.

I did come too rough. I apologize. But frankly I am tired of hearing the opinion of someone who always has strong opinions on things that he doesn't plan to learn about or use in any kind of capacity that would actually empower him with such opinions. That's what maddens me about you and your opinions. By learning to develop, I mean learn to *actually* develop, by programming in more than one programming language and using them on a regular basis for long enough to actually be able to construct your opinions on them. It's no wonder that your opinions on things like C or Linux are always so devoid of clear and precise arguments. It's because you just can't have well formulated opinions on things you never cared to use or learn about, but still insist on never letting go a chance to bring your uninformed bias about.

---

You have a point, Mario. I will agree that I usually ward off technologies and languages due to personal bias because of what I hear, see or read. Other things I do have experience with. Sometimes not a lot. Sometimes a little more. I've done javascript (because I wanted to make a "web page"), and found it very lacking. I've used C (for a required college project), and found it very lacking. I've used C#, and at first I thought it was cool, but now I find it lacking. I'm sorry if my opinions come off as unbiased or made up. I usually try to avoid getting into debates for things I know little about or am biased about. But sometimes I don't always succeed, and even in topics where I have experience, I may come off in an unintended way.

I took a stab in my reply above because I find C to be a lacking language. Both C and C++ are close to the metal, and while some may consider using C++ to mean high-level, as far away from the metal as possible, C++ is also meant to be close to the metal. By limiting the subset of C++ so you, you can absolutely make C++ work with embedded systems, kernels, etc. And you still have far more practical tools in your toolbox. So that's why I said more practical.

Quote:

---

Originally Posted by whiteflags

If that's not what you guys meant then I'm sorry, you lost me.

---

You aren't too far off because I did misread McNilly reply. Had I not done so, I would have jumped first on what he said.

Quote:

---

Originally Posted by phantomotap

Are you sure you'd like to make that claim?
I've seen you rant at least a few times of the, let's say, impenetrable nature of C++ generics as expressed with templates.

---

Of course I am sure! Both languages don't share the same characteristics across their entire standard. And C++ loses it right around the moment one starts delving into meta programming. But to be fair, what language doesn't? You give the example of C macros, and just recently I was studying Python metaclasses and by the end of it, after having written just a couple of those to handle configuration scripts of a new linux distro we are trying to build, I was laughing at how all the expressiveness of the Python language had been thrown out the window.

Quote:

---

Originally Posted by phantomotap

For me, the situation you are referencing is literally either "someone has paid me" and "an important project uses only the C language". I think that C has value because of the innumerable important projects which use the C language, and I think that C has value because a lot of brilliant minds think C has value thus continue to use the C language for new projects. In other words, I don't think C has any value because of a lack of mechanisms useful for expressing abstractions or any nearness of the metal.

---

Oh, but I'm doubtful. Not of what you think, mind you. But on how correct you are. I just don't think that certain implementations are possible in C++.
You have also heard me, not so long ago, mention to someone else that C++ coders have been happily creating kernels and all sorts of other low level systems, when I was trying to defend C++ against some nut job here in the forums who was claiming... whatever it was that I don't recall anymore. But while that is no doubt true, you will always find that C delivers much better than C++ in certain conditions.

I don't doubt for a moment that a good portion of C code exists only because of its coders, and not because of an actual need for the language features. But that's true of C++ as well. In the end however there are situations in which (good) C++ code will provide the best solution to some computing problem. And the same is true of C, even if you want to believe in Stroustrup's 'C++ is a better C'.

Quote:

---

Originally Posted by Elkvis

I disagree. C is a simpler language, and as a result, requires that code written in C is more complex than that written in C++. It's a fine distinction, but it's a valid one, nonetheless.

---

Perhaps. The net effect is that C code is more complex. Which is the point I'm trying to put across.

Quote:

---

Originally Posted by Elysia

I took a stab in my reply above because I find C to be a lacking language. Both C and C++ are close to the metal, and while some may consider using C++ to mean high-level, as far away from the metal as possible, C++ is also meant to be close to the metal. By limiting the subset of C++ so you, you can absolutely make C++ work with embedded systems, kernels, etc. And you still have far more practical tools in your toolbox. So that's why I said more practical.

---

But you don't get a more practical language. That practically is in the eye of the beholder. By restricting yourself to all but the basest of the C++ standard library functions and objects, what practical features are left are simply due to your own knowledge of the language. A seasoned C programmer can find as many practical aspects in the core C language as you can in core C++. It all amounts to how well you two deal with the language semantics and its rules. But even admitting some aspects of the core C++ language are better designed (I'm thinking for instance, const-correctness, or user-defined static type system, or namespaces) these aren't game changers in the scope of general programming.

And of course, once you can open the whole of your language and can make use of it, by all means, C stops making any sense. And its only the individual know-how of people that dictates whether one will use C or C++. But I'm not here to discuss that. I am here arguing against the explicit argument that C is a simpler language that cannot answer modern computing needs.

Quote:

---

The net effect is that C code is more complex. Which is the point I'm trying to put across.

---

O_o

I wanted to address the comment first because the argument is rather different than how I interpreted your earlier post.

I agree that the ultimate result of the lacking features in C, with comparison to most languages, makes common code more complex.

You'd only need to look so far as construction in C++ versus weak resources in C to appreciate such differences.

Quote:

---

But to be fair, what language doesn't?

---

You'd find only a few languages where metaprogramming is part of the core design from the start.

The facilities fail in consistency so hard in C, C++, Python, and Javascript because concerns for metaprogramming are or were afterthoughts.

In fact, metaprogramming in C++ was basically born of a party trick unrelated to anything intended in the actual standard.

For really expressive and clean metaprogramming constructs to exist, they must have been part of a language from the beginning.

You would also, arguably, want a language which isn't somehow built on the C or C++ languages.

Quote:

---

I was laughing at how all the expressiveness of the Python language had been thrown out the window.

---

If you've done things properly though, you should have a greater expressiveness to state your requirements which is a fine purchase.

Quote:

---

I just don't think that certain implementations are possible in C++.

---

o_O

Quote:

---

But while that is no doubt true, you will always find that C delivers much better than C++ in certain conditions.

---

The only condition where I would find that C delivers any better that C++ is for those environments which only have crap C++ compilers.

I know what I'm doing in both languages, but I am never without the want for my parametric polymorphisms... even to the point I'd probably drop C++ entirely were Python to gain proper support.

Quote:

---

And the same is true of C, even if you want to believe in Stroustrup's 'C++ is a better C'.

---

You've surely heard the "Bad Code Can Be Written In Any Language" axiom?

I assert that "Excellent Code Can Be Written In Any Language".

I'm not sure what excellent Java would look like so don't hold me to that, but the point is that you are talking about domain compatible languages.

If you were discussing C or C++ versus some domain language, I'd certainly agree.

Unlike Javascript or Python, to some degree, the C and C++ languages share too much of the same surface for me to agree with you.

Soma

Quote:

---

Originally Posted by whiteflags

I think MacNilly means rather that C is close to the hardware in the sense that you could insert assembly code or understand what the assembly would look like from C code.

---

Yes, that's a large part of what I meant in my post.

By a "simple" language I mean one with less "features" as compared to more. In exchange for (possibly) increasing programmer's productivity and reducing number of lines of code to perform a task, a more complex language increases mental demand on the programmer, because he or she needs to (should!) understand how all those extra features interact in a variety of situations. It's a double-edged sword.

As far as "modeling current hardware".. C seems to me to provide the least possible complexity (in terms of features and also length of formal language specification) in a language which is capable of programming a Turing machine.. which is basically how modern hardware works, unless I am missing something. For example, functional programming languages like Scheme make an effect to NOT model the hardware that the programs will eventually run on, but instead to abstract away this dependency. On the other hand, things like Brain........ shows that a language still needs to be human-understandable to be at all practical, even though even simpler than C.

Also, I do not wish to incite any argument in this thread and I am sorry it seems to have turned out that way..

I took a crash course in Java Script a few years back and to be honest, hated it. I had to
do it for a work-related study group thing (which I won't bore you with the details of it).

I've never been a "scripting" person, so that's probably the main reason I could never quite
get my head around it. PHP however, I am sorting learning in my spare time - quite enjoying it.
JS does get some bad rep, however could the Internet really survive without it?

Quote:

---

Originally Posted by swgh

I've never been a "scripting" person, so that's probably the main reason I could never quite
get my head around it.

---

I think there is nothing really different from a "scripting" language than any other "real" programming language, other than the pejorative usage. In common parlance, the application of the term "scripting" to a programming language seems to imply its primary use as a control language to some system. There is nothing stopping Java"script", or any other "script" from being compiled directly to machine language.. also, one could even consider C as a "scripting" language for a real processor...

However, in the case of Javascript, if it was compiled directly to machine language, would likely not work as intended due to the ubiquitous and idiomatic usage of concepts such as the "window" object, etc. -- which would NOT necessarily exist in a native environment. But these dependencies need not (and probably should not) be an integral part of the language itself.

Quote:

---

Originally Posted by MacNilly

also, one could even consider C as a "scripting" language for a real processor...

---

That's actually quite true. If you think about it, C is just a thin more human Assembly language. Unless you are coding
in pure ASM, C is the lowest language to the computer metal you can get. Of course if you could program in pure
binary:

Code:

---

00100101101

---

;)

You could rule the world.

But yes, you make some good points there McNilly. :)

Quote:

---

Originally Posted by MacNilly

Yes, that's a large part of what I meant in my post.

By a "simple" language I mean one with less "features" as compared to more. In exchange for (possibly) increasing programmer's productivity and reducing number of lines of code to perform a task, a more complex language increases mental demand on the programmer, because he or she needs to (should!) understand how all those extra features interact in a variety of situations. It's a double-edged sword.

---

I think quite on the contrary, that C demands more lines of code to perform comparable tasks and by extension increases code complexity and demands more of the programmer. Although I still think that functional programming offers superior code organization than OOP, C ends up not taking advantage of that because of the extended and complex execution path it eventually forces on the user. And while C++ may introduce more boilerplate code, C isn't too far off in its own demands for code correctness, memory management or the previously mentioned macro magic. Take a look for instance on the techniques you must use in C if for some reason you need to emulate C++ namespaces.

The obvious simplicity of the language definition is only illusive. Like the apparent simplicity of the assembly language definition, this only means that the developer will be the one taking the blunt of the complexity.

I think the key thought to keep in mind when discussing a language complexity is that the abstraction ideas that make the core of any programming language today will always present the exact same level of complexity. For all languages, without exception. This is so because that complexity is inherited upstream by the system architecture and to some extent the operating system kernel. And that complexity can't go away. What languages do is decide how they will abstract that complexity. A simpler language specification means much of that complexity is not going to be abstracted away, or be thinly abstracted, and will be exposed to the programmer as a result. So a "simpler" language is more complex to code and produces more complex code.

Like distinct players sitting in front of a chess board, they will have to tackle the inherent complexity of the game that is common across them. A C programmer will bring just a few notes, A C++ programmer might come with a cheatsheet on opening moves and endings, and a Python programmer may bring an entire book on how to win the game. The burden on the players' will be different. The code inside their brains necessary to process the game will be different. The C player, who traveled light, will have the biggest headache at the end of the game. While the Python player who packed more than he needed, will likely have to think less about the game.

Quote:

---

Originally Posted by MacNilly

As far as "modeling current hardware".. C seems to me to provide the least possible complexity (in terms of features and also length of formal language specification) in a language which is capable of programming a Turing machine.. which is basically how modern hardware works, unless I am missing something.

---

Modeling is the wrong word, and one of the two words that got me here. C doesn't model the hardware, it precisely aims to not do that. C, like any other high-level language, can be many things, but not a modeling tool. Maybe I am being too pedantic, because I DO understand where you are coming from, but it's really a pet-peeve of mine. This idea that languages like C or C++ are "closer to the metal" than languages like Scheme or Java, really needs to be put in context.

All these four languages mentioned are high-level languages and they do indeed share different rungs in the abstraction ladder. But they stay an equal distance from the processor instruction set. Frankly the idea that a language like C has a better 1-on-1 map to the processor instruction set isn't good enough. It's not even correct. For one, that mapping is purely arbitrary because it depends entirely on the compiler. On the other hand that mapping isn't correct, because C code will not tell you anything truthful about stack positions, storage locations or how values are returned. Only by checking the executable will we finally get a glimpse at true and functional assembly language. But that is true of any other language. The C mapping, or that of any other high-level language for that matter that shares a similar predisposition for the so-called 1-on-1 mapping, like Go, is just and only a toy. It requires an intimate knowledge of the specific compiler, after which it will still remains largely useless for the aforementioned reasons and also because many other constructs with a common use in the language have more complex or even unpredictable mappings.

I think a better notion that a high-level language is "closer to the metal" is made by looking precisely at its specification and how far it goes in abstracting the complexity of the machine. That's where I agree with you. But not on the idea of assembly mapping.

Sorry for the long post. ugh! Where's whatsisname when we need him? Haven't seen our resident TL;DR master for quite a while... I do miss him.

So... I agree with Elysia's post that started this entire debate.

I think C is too bare nowadays to make it more practical over C++. Now that I feel like I'm finally starting to get C++, I could never go back. The things C++ allows you to do are amazing. The issue is its steep learning curve.

So, C and up are all high-level languages. I agree with Mario in that regard. So they're all logically equivalent. What really separates them is the level of their abstractions (again, as Mario noted). C is a high-level language that offers low-level abstractions. C++ offers both but if you're not doing high-level C++, it's because you were like me and coming from a C background.

I also think it's an abhorrent thing to say that functional programming yields better code structure than OOP. Namely just because making an absolution about a paradigm is an instant kiss of death and will likely shoehorn your codebase into a hole it has no business being deformed to fit into. But I think that's because Python offers some FP concepts.

And I'm certainly not saying that FP isn't incredibly powerful or useful. FP has a lot of good ideas. Functions as variables, thinking in terms of functional compositions, pushing for immutability, lazy evaluation, support for recursion (this often lowers cognitive overhead, both while writing and reading code). I'm sure there's some things that I've missed but FP is great. To a point. I think it's the point where you get into monads that FP goes on the rails and it's the reason why it fell into obscurity. I didn't really "get" monads until I read this.

And I realized that monads are literally just classes. And then I learned that classes are types. And then I got amazing at templates in C++ because it was all so simple now. Imagine how excited I was when I found out there's a proposal for a Expected monad in C++! It's similar to a Maybe only actually useful.

JS is great because the web is largely solved by FP (hence Mario's affinity for Python and the FP support it has). Someone wrote a "Validator" monad in JS which is basically C++'s Expected but marketed as, "Hey, use this to validate your forms!". And as someone who's written some decently intense client-side validation in JS, a Validator monad is the best thing to ever happen ever.

But I don't really expect FP to be widely used and understood. For one, it's marketed all wrong. And I've never seen anyone have a more straight-forward explanation of monad than, "Imagine you have this class that...". Seriously, if I see one more blurb about parallel computing in FP, I'm going to have an aneurysm because as someone that feels like they've invested a good amount of experience into threading and asynchronous reasoning, what makes FP good for parallel computing isn't exclusive to FP. At all. And let's put it this way, Nvidia didn't write their GPGPU API in Haskell, they chose C++. And C++ does it well because it supports fundamentally lower abstractions which is great because CUDA needs like another 5 years at least.

Actually I did make a mistake in that post. I meant to say procedural programming, not functional programming.

Quote:

---

Originally Posted by Mario F.

I think quite on the contrary, that C demands more lines of code to perform comparable tasks and by extension increases code complexity and demands more of the programmer... The obvious simplicity of the language definition is only illusive. Like the apparent simplicity of the assembly language definition, this only means that the developer will be the one taking the blunt of the complexity...A simpler language specification means much of that complexity is not going to be abstracted away, or be thinly abstracted, and will be exposed to the programmer as a result. So a "simpler" language is more complex to code and produces more complex code.

---

I think you must have misunderstood my previous posts, because this (spliced) quote is exactly what I have discovered to be true, and what I was trying to convey in my series of posts here. We seem to be in agreement, then, after all.

I see what you mean that trying to implement abstractions in C, which are more cleanly accomplished in a language which provides syntax for that abstraction (exception handling vs. longjmp/setjmp, object-oriented programming, etc.) , would definitely increase the demand on the C programmer as compared to the X language programmer where language X provides those features as a core part of the language. However, these features introduce extra complexity into the language which may not be needed by a low level language such as C.