5 ms·

There’s a lot of problems with C, like the fact you have to break out of case statements, or string concatenation, or overuse of the static keyword. These are a

by dreta 10y ago

There’s a lot of problems with C, like the fact you have to break out of case statements, or string concatenation, or overuse of the static keyword. These are actual problems, which C++ doesn’t even begin to try and solve, instead introducing useless features and bloat. C is still one of the few popular languages that allows you to talk to the machine directly. It’s a language that doesn’t rely on hidden run-time logic, or hidden implementation costs. It doesn’t enforce any particular programming style on you, and lets you do anything a process is capable of doing. Software engineers these days are so lost in abstractions and design patterns that they forget that at the end of the day a program is just data, and a set of operations that transform that data. There’s huge value in writing code that does everything explicitly from top to bottom, both from a readability, and from a debugability standpoint. Instead, these days, software is designed using UML diagrams and OOP concepts while pretending that objects are ideas that float in some abstract disconnected space. All in the name of concepts envisioned by people who write books instead of programming, and who never saw even a glimpse of a problem you’re trying to solve. Languages like C will never become obsolete. There’s always a new frontier of hardware that needs fast, tailored software. Few years ago that was phones, and watches, next it might be tiny implants. Anybody who thinks languages like C is obsolete should ask themselves “why was my Comodore64 more responsive than a PC i bought in 2016?”, or "why is my dual-core Android smartphone with 1GB of RAM barely usable after a year”. Modern languages and programming practices have this amazing ability to completely negate the massive progress hardware has made.

Avshalom 10y ago
>>Few years ago that was phones, ObjC and Java >>Anybody who thinks languages like C is obsolete should ask themselves “why was my Comodore64 Assembly and Basic.
- mikejmoffitt 10y ago
  Surely Basic is not responsible for the Commodore being responsive. Java was a total dog on phones for a long time, too.
  - Avshalom 10y ago
    Well C wasn't responsible for the Commodore either. And whether Java was a dog or not, thats what people went with, from your SIM card to JavaME snake games to Dalvik/ART. People looked at these resource constrained environments and went "yeah lets use Java". ETA: it's probably worth put scare quotes around "resource constrained" when talking about Android and IOS but phones were dreta's example.
    - marrs 10y ago
      and promptly went out of business when the iPhone showed up
      - Avshalom 10y ago
        a phone that launched full of ObjC and Javascript with a SIM card running Java...
        marrs 10y ago
        ObjC is a native language and a direct descendent of C, and powered the phone's built-in apps. JS was provided for 3rd party developers, who incidentally rejected it. I wasn't aware of the SIM card running Java. I guess Java was good enough for that job since I never noticed any performance issues with the iPhone, unlike my Palm Pre which was plagued with them, and had a terrible battery life.
  - e12e 10y ago
    I still remember the load times for Last Ninja - I'd prefer an ssd any day.
- dottrap 10y ago
  >>>Few years ago that was phones, > ObjC and Java To defend the parent's point, Objective-C is a pure superset of C. And there are quite a few frameworks on the Apple platforms that are pure C (not Obj-C), e.g. CoreGraphics, CoreAudio, ImageIO, OpenGL, etc.
fredsanford 10y ago
Take a look at the useless features and bloat in this video. Modern C++ isn't what you think it is. https://www.youtube.com/watch?v=zBkNBP00wJE https://www.youtube.com/watch?v=zBkNBP00wJE
- dreta 10y ago
  Could’ve easily written that in plain C. All the usage of C++ concepts like templates did, was made him write more code than necessary, and made the code harder to understand.
  - fredsanford 10y ago
    You're not worth the effort.
    - dreta 10y ago
      If i’m missing something obvious, please explain to me how using any of the C++ concepts made the code any better. You have to keep in mind that this is a very simple piece of software. I wager you that using things like templates made the code unnecessarily harder to understand. I’ll also wager that by using templates he made the code harder to scale, since any remotely complex template, just like an overused base class, eventually becomes a set of special cases, or a set of specialised templates which defeats their purpose in the first place, and makes your code a nightmare to step through. This is a typical example presented in a talk. It doesn’t reflect any large real-world software, where complex language solutions (useful ones, not the ones in C++) could actually benefit the programmer.
  - marchelzo 10y ago
    I agree completely. I couldn't believe it when he made that Frame struct and completely abused RAII just to execute some code at the beginning and end of a block. The only really big wins were the wrappers for writing to different memory locations, all of which could have been implemented in C using macros or inline functions.
- inDigiNeous 10y ago
GFK_of_xmaspast 10y ago
I used a c64 for many years in my youth, and "responsive" is not at all the way I remember it. Have you forgotten things like "the loading times from the 1541" and "geos"? (for example: https://www.youtube.com/watch?v=qpX6TIa3U1o https://www.youtube.com/watch?v=qpX6TIa3U1o and warning: soundtrack)
- retro64 10y ago
  Whoa now friend. The 1541 is a computer onto itself. The slow loading was because of Commodore’s desire to keep backwards compatibility with the VIC-20 drive, which used a buggy 6522 chip, not because the 64 couldn’t go faster. BTW, if you want to run GEOS faster, get an REU and let the DMA transfer fun begin. This is 2016 after all; you must keep up with the times :)
0xcde4c3db 10y ago
> “why was my Comodore64 more responsive than a PC i bought in 2016?” Not because of C; that's for sure. The two biggest reasons are: 1) Your Commodore 64 is doing at least a couple orders of magnitude less actual work. This has less to do with language choice than it does with a programmer who is fully in touch with the problem to be solved and can identify unnecessary work to eliminate. 2) Your Commodore 64 is effectively designed in a way that prioritizes latency over throughput. Pipelines and buffers are small-to-nonexistent. When you read the joystick port, you sample the state of that joystick at that very microsecond; you're not asking one microcontroller to ask another microcontroller to start thinking about sending the input it sampled 10 milliseconds ago. The worst-case latency from changing the video data to seeing it on screen is measured in lines, not frames (assuming a low-latency display like a dumb CRT). Virtually nothing is asynchronous. Systems aren't built that way anymore because we want to be able to push massive amounts of data through subsystems that can't all run in lockstep to one fast master clock, and that means lots of buffering and burst transfers.
- dreta 10y ago
  I don't understand why you guys hang on the fact C64 wasn't coded in C. I never said it was. I talk about C-like languages, so low-level, with little to no overhead. I understand that computers worked differently back then, and that software usually had full control over the machine, but please, don't talk to me about buffering, etc. when we're talking 6502 versus an i7, or an A8. I understand that input and output aren’t instant these days, but that’s an order of tens to hundreds milliseconds of delay. It doesn’t explain why Visual Studio takes tens of seconds to compile “Hello, World!” on a 16 core processor. Or why your Chrome tab eats 600MB of RAM. Since you want to talk about buffering and built-in input delay, here’s a comparison of text editor performance: https://pavelfatin.com/typing-with-pleasure/#windows https://pavelfatin.com/typing-with-pleasure/#windows
  - 0xcde4c3db 10y ago
    I guess what I'm getting at -- and could have communicated better -- is that this approach of "buffer/queue/cache/defer everything because it's faster right now, never mind that we might have to stall and flush the pipeline all at once later" has worked its way up the stack, with the worst-case stall growing in magnitude as the path cascades through progressively more layers and bigger buffers (cf. bufferbloat in networks [1]). Among other issues, it fools people into thinking that expensive operations are cheap. I think that pattern is far more responsible than language-imposed overhead for the weird quasi-random delays that are seen in modern systems. You can certainly connect this to popular idioms and some standard library facilities in some higher-level languages, but I think that connection is largely a historical accident rather than having much to do with the languages themselves. [1] https://en.wikipedia.org/wiki/Bufferbloat https://en.wikipedia.org/wiki/Bufferbloat

by dreta 10y ago

Avshalom 10y ago

>>Few years ago that was phones, ObjC and Java >>Anybody who thinks languages like C is obsolete should ask themselves “why was my Comodore64 Assembly and Basic.

mikejmoffitt 10y ago
Surely Basic is not responsible for the Commodore being responsive. Java was a total dog on phones for a long time, too.
- Avshalom 10y ago
  Well C wasn't responsible for the Commodore either. And whether Java was a dog or not, thats what people went with, from your SIM card to JavaME snake games to Dalvik/ART. People looked at these resource constrained environments and went "yeah lets use Java". ETA: it's probably worth put scare quotes around "resource constrained" when talking about Android and IOS but phones were dreta's example.
  - marrs 10y ago
    and promptly went out of business when the iPhone showed up
    - Avshalom 10y ago
      a phone that launched full of ObjC and Javascript with a SIM card running Java...
      - marrs 10y ago
        ObjC is a native language and a direct descendent of C, and powered the phone's built-in apps. JS was provided for 3rd party developers, who incidentally rejected it. I wasn't aware of the SIM card running Java. I guess Java was good enough for that job since I never noticed any performance issues with the iPhone, unlike my Palm Pre which was plagued with them, and had a terrible battery life.
- e12e 10y ago
  I still remember the load times for Last Ninja - I'd prefer an ssd any day.
dottrap 10y ago
>>>Few years ago that was phones, > ObjC and Java To defend the parent's point, Objective-C is a pure superset of C. And there are quite a few frameworks on the Apple platforms that are pure C (not Obj-C), e.g. CoreGraphics, CoreAudio, ImageIO, OpenGL, etc.

fredsanford 10y ago

Take a look at the useless features and bloat in this video. Modern C++ isn't what you think it is. https://www.youtube.com/watch?v=zBkNBP00wJE https://www.youtube.com/watch?v=zBkNBP00wJE

dreta 10y ago
Could’ve easily written that in plain C. All the usage of C++ concepts like templates did, was made him write more code than necessary, and made the code harder to understand.
- fredsanford 10y ago
  You're not worth the effort.
  - dreta 10y ago
    If i’m missing something obvious, please explain to me how using any of the C++ concepts made the code any better. You have to keep in mind that this is a very simple piece of software. I wager you that using things like templates made the code unnecessarily harder to understand. I’ll also wager that by using templates he made the code harder to scale, since any remotely complex template, just like an overused base class, eventually becomes a set of special cases, or a set of specialised templates which defeats their purpose in the first place, and makes your code a nightmare to step through. This is a typical example presented in a talk. It doesn’t reflect any large real-world software, where complex language solutions (useful ones, not the ones in C++) could actually benefit the programmer.
- marchelzo 10y ago
  I agree completely. I couldn't believe it when he made that Frame struct and completely abused RAII just to execute some code at the beginning and end of a block. The only really big wins were the wrappers for writing to different memory locations, all of which could have been implemented in C using macros or inline functions.
inDigiNeous 10y ago

GFK_of_xmaspast 10y ago

I used a c64 for many years in my youth, and "responsive" is not at all the way I remember it. Have you forgotten things like "the loading times from the 1541" and "geos"? (for example: https://www.youtube.com/watch?v=qpX6TIa3U1o https://www.youtube.com/watch?v=qpX6TIa3U1o and warning: soundtrack)

retro64 10y ago
Whoa now friend. The 1541 is a computer onto itself. The slow loading was because of Commodore’s desire to keep backwards compatibility with the VIC-20 drive, which used a buggy 6522 chip, not because the 64 couldn’t go faster. BTW, if you want to run GEOS faster, get an REU and let the DMA transfer fun begin. This is 2016 after all; you must keep up with the times :)

0xcde4c3db 10y ago

> “why was my Comodore64 more responsive than a PC i bought in 2016?” Not because of C; that's for sure. The two biggest reasons are: 1) Your Commodore 64 is doing at least a couple orders of magnitude less actual work. This has less to do with language choice than it does with a programmer who is fully in touch with the problem to be solved and can identify unnecessary work to eliminate. 2) Your Commodore 64 is effectively designed in a way that prioritizes latency over throughput. Pipelines and buffers are small-to-nonexistent. When you read the joystick port, you sample the state of that joystick at that very microsecond; you're not asking one microcontroller to ask another microcontroller to start thinking about sending the input it sampled 10 milliseconds ago. The worst-case latency from changing the video data to seeing it on screen is measured in lines, not frames (assuming a low-latency display like a dumb CRT). Virtually nothing is asynchronous. Systems aren't built that way anymore because we want to be able to push massive amounts of data through subsystems that can't all run in lockstep to one fast master clock, and that means lots of buffering and burst transfers.

dreta 10y ago
I don't understand why you guys hang on the fact C64 wasn't coded in C. I never said it was. I talk about C-like languages, so low-level, with little to no overhead. I understand that computers worked differently back then, and that software usually had full control over the machine, but please, don't talk to me about buffering, etc. when we're talking 6502 versus an i7, or an A8. I understand that input and output aren’t instant these days, but that’s an order of tens to hundreds milliseconds of delay. It doesn’t explain why Visual Studio takes tens of seconds to compile “Hello, World!” on a 16 core processor. Or why your Chrome tab eats 600MB of RAM. Since you want to talk about buffering and built-in input delay, here’s a comparison of text editor performance: https://pavelfatin.com/typing-with-pleasure/#windows https://pavelfatin.com/typing-with-pleasure/#windows
- 0xcde4c3db 10y ago
  I guess what I'm getting at -- and could have communicated better -- is that this approach of "buffer/queue/cache/defer everything because it's faster right now, never mind that we might have to stall and flush the pipeline all at once later" has worked its way up the stack, with the worst-case stall growing in magnitude as the path cascades through progressively more layers and bigger buffers (cf. bufferbloat in networks [1]). Among other issues, it fools people into thinking that expensive operations are cheap. I think that pattern is far more responsible than language-imposed overhead for the weird quasi-random delays that are seen in modern systems. You can certainly connect this to popular idioms and some standard library facilities in some higher-level languages, but I think that connection is largely a historical accident rather than having much to do with the languages themselves. [1] https://en.wikipedia.org/wiki/Bufferbloat https://en.wikipedia.org/wiki/Bufferbloat