godratio

pragmatic_hero

godratio
IF you want to become a Jedi you better learn to make your own fucking lightsaber.

You can remain a padawan for the rest of your life fine by me. Means I have the competitive advantage. Thanks.

I'm sure that in your realm of starwars fanfics everybody is awarded a golden star for effort.

I sure hope more indies buy into this idea of Jedis and Ninjas and how cool it is to write games in C (or better yet "modern" C++) and use Vulkan (totally Jedi power level) and uninstall themselves from the already crowded indie market in the process. Thanks.

Oh how I wish I could side-track those pesky little gamemaker, unity, Java, Csharp slinging padawans into writing yet another platform abstraction for getting all files in a directory.

Have them waste time writing yet another buggy, incomplete C parser to add basic reflection and meta-programming capabilities to C. Have em write all sorts of different macro-based hashmap implementations, dictionaries, stringpools, red-black trees and whatever the fuck else is there in every other programming language out there.

Did you know that ye ole' Yoda master uses Vim and GDB? You better get crackin!
We could also sucker them into creating and maintaining some sort of elaborate build system that holds together that house of cards. Ideally something with a true 1970s unix heritage, with cryptic rules and bizarre, inconsistent syntax. Like autotools and makefiles. Something hacky and nonsensical. As Unix is to C, C is to Unix.

Convince them that punching commands in VT100 emulation is peak of human-computer interface.
Because that's what "real" programmers use and that there's an unbounded explosion of productivity and power once you've mastered them.

It is not the way of the Jedi if every line of code doesn't bend their minds in eight dimensions at the same time:
1. How many cycles is this going to waste?
2. Is this undefined behavior? What does the C standard have to say about this?
3. How is this going to affect the size of the binary? Will it fit on 1.44?
4. How is this going to explode the compile times (and it is going to because it's C/C++ we're talking about)
5. Am I trashing the cache, and how many bytes i'm wasting per cache line read
6. Who owns the memory, how i'm going to allocate it, free it, etc
7. Am I corrupting the memory or having a race condition (without ever knowing for sure)
8. What would Mike Acton think (this is important)

Make em run linters and memory sanitizers, watch their hair color waiting for it all to build.
In the end it's all going to be worth it - because your textured cube will run at over 9000 FPS.

That's what makes you a true Jedi Knight!

Since I don't have to do any of that. Means I have a competitive advantage*. Thanks.

Wow. Go off on a tangent much? No one is saying do all that.
Im saying building your own abstractions.
I have seen the result of y our type of thinking. In the game industry your costing companies a lot of money and man hours.
As a side note someone who has done all that multiple times will come out a much better programmer and given the exceptions where they have bad teamwork ethics I would hire them over anyone with your mindset for game production.

If your building your own indie game... be my guest do what you think is good for you. Maybe your a rust expert and you can build a game super fast that way because your built your own abstractions and do not need a lot of performance or low level customization perfectly fine.

To summarize what I mean to be a Jedi you must build your own lightsaber , if you have not attempted to implement it your self while learning other CS concepts than you can not be a Jedi.
I am not talking about the erroneous concept of coding ninjas in my analogy I am specifically referring to mastery. Programming mastery.

Yes!!! I want to be a JEDI CAT LETS GO YOU PUSSIESSSS.

Too much "competitive advantage", and you get stuff like this:
https://josephg.com/blog/electron-is-flash-for-the-desktop/

Do we need to get hmh_bot in here? Let me remind everyone of our old adage:

Programming is not about the languages: code is a tool used to solve problems that programmers face. Some languages address certain tasks better than others, but ultimately you simply need to end up with code that hasn't wasted your users' time or your own time.

Here are some valid reasons you might want to program in C:

• Programming in C is fun
• C lets me control the machine more directly than other languages
• C is stable and won't change over time, so I know my code will last a long time
• C doesn't have very many implicit rules, so what I write in C is pretty close to the whole story about what happens when my program runs.

Here are some valid reasons you might not want to program in C:

• There are a lot of things to keep track of when controlling the machine directly, and most of them are not relevant to my specific program most of the time
• C is not type/memory/alias safe and I want to be able to make guarantees about my code's correctness
• There are a lot of things to keep track of when controlling the machine directly, and they are not all made explicit in the structure of the code so that other people can see them and be sure their changes to my code are correct
• Some other language X has syntax/library feature Y that lets me program more quickly/efficiently/enjoyably
• I need to run my code somewhere I can't prepare a compiled C binary for (e.g. web, a console you don't have a compiler for)

Here are some not-great reasons for the above positions:

• I want to learn language X so I can get the approval of my peers
• Language X is better than language Y
• I want to learn language X so I can claim some abstract "mastery" achieved
• Jobs using language X pay more*
• Jobs using language X are rarer and therefore if I know language X, I have a better chance*
• I learned language X first and don't see the need to learn anything else

*from a purely philosophical viewpoint, i.e. I believe you shouldn't structure your life and potentially sacrifice the enjoyability of programming just to game the job market -- programming jobs in general tend, regardless of language, to be a) easier to get and b) pay more than jobs in other specialized fields. Note also that I use a generic language X intentionally because these arguments are heard for languages other than C as well.

godratio
I have seen the result of y our type of thinking. In the game industry your costing companies a lot of money and man hours.

C has cost software industry gazillions of dollars. Directly and indirectly.

The monstrosity which were borne out of C, the so called C++ I'm sure has cost additional gazillions of dollars too.
I sincerely think that C and Unix are the worst calamities the software industry has ever experienced.
Collateral damage levels - unprecedented.

Just how much money and human life has C++ wasted on compile times alone? How much has C++ robbed people of joy of programming?

I believe that Java and the whole emergence of GCed languages is basically a allergious counter (over?-) reaction to how badly designed C and C++ is.

godratio

To summarize what I mean to be a Jedi you must build your own lightsaber, if you have not attempted to implement it your self while learning other CS concepts than you can not be a Jedi.

You seem to care about titles, Ninjas and Jedis and chase the abstract notion of a "good programmer". I don't.

I care about the observable, measurable event of "shipping software" a la "getting shit done".
I'd rather hire a padawan who ships, than a Jedi who ratholes on largely irrelevant technical details.

Programming mastery can only shine through shipping.

Being able to balance a red-black tree on a whiteboard doesn't really help me to ship software or get shit done.
And when it does, I will juggle AVL trees and R-B trees like a nobody's business.

I do care about arrays and strings though and convenient ways to work with them, as those are the basic building blocks of all software. Of which there is none to be found in C. Neither is there any way to build or use ADTs in any way which isn't a giant pain in the ass.

pragmatic_hero
I sincerely think that C and Unix are the worst calamities the software industry has ever experienced.

So... this is an honest question... how could things have gone differently?

Unix was itself a reaction to the mess that was Multics. A lot of people liked Multics, of course, but it tried to do everything and was irrevocably tied to the hardware that it was targeted for.

C and Unix have their problems, and some of them are quite serious problems. I think you'll get no argument from anyone here on that. They have perhaps overstayed their welcome due to a combination of historical accident and a lack of will to replace them. Nonetheless, without C and Unix, or something very much like them, each computer vendor would be shipping a different proprietary and incompatible operating system. Just look at the mobile OS/language ecosystem to see what I mean.

I guess one person's "calamity" is another person's "creative destruction".

Now I'm not accusing you of this, but there is a somewhat revisionist take on the history of operating systems which says that Unix held back innovation because to be a success, every new OS feature had to be compatible with Unix and every new language needed a C binding. There is a little bit of truth to this, but not much. On the OS side, for example, there was a lot of Unix in new research operating systems because the source code was available, it was portable, and it was well-designed enough that you could replace parts without having to start from scratch. This is essentially how BSD and Mach came to be.

It's hard to see how this could have happened without Unix or something very much like it.

As for C, once again, if it wasn't for Unix, the most popular cross-platform systems programming language would be a modern version of BCPL. Could be worse, I guess, but I'd rather have C than BCPL all things considered.

Pseudonym
As for C, once again, if it wasn't for Unix, the most popular cross-platform systems programming language would be a modern version of BCPL.
Could be worse, I guess, but I'd rather have C than BCPL all things considered.

It sounds like you're saying that if "C and Unix" didn't exist what we'd have in their place would have to be worse.
That makes no sense.

Pseudonym

pragmatic_hero
I sincerely think that C and Unix are the worst calamities the software industry has ever experienced.

So... this is an honest question... how could things have gone differently?

For starters, we could have had a language with real arrays, strings and modules.
And a saner syntax (one which is unambiguous and easier to parse).
That's not much to ask, is it?

Its not like those were novel concepts in early 1970s. Not without fault, Pascal was conceived around that timeframe, and it got surprisingly many things right.

abnercoimbre

pragmatic_hero
What Sean shows is that it is POSSIBLE to write small programs in C fairly productively after you've accumulated a whole set of tools over years and years of work and experience.

And thus avoiding the mindset that C can't be used for small tools pretty much ever. I'm talking about a certain kind of thinking that is very black and white, and of course I don't believe Todd falls in that category, but just thought I'd point out Sean's lecture.

Abner,

I ended up making a "small tool" in C just the other day for work. Perhaps this was meant to teach me a lesson?? :) My boss needed it in C or C++ rather than Python. I chose C as I am more comfortable with it than C++.

Python would always be my go-to to get things done fast, but C is solid and frankly, I do feel like with enough practice, I could bang out stuff in not too much time. To be completely honest, I was expecting the tool I wrote in C the other day (it had to do with parsing the PE file header information and scanning the file for certain bits, then making a decision) to take much longer to write, and also to be far longer than the similar Python code I wrote a week prior.

Actually, the C code didn't take that many more hours and on top of that, the program isn't a whole ton bigger at all. The nature of what I needed to do was so low-level that in fact, it was a "might as well do it in C" type of thing: Moving a file ptr around in python doesn't require many fewer lines than C if at all. In the end, I believe it comes down to a case-by-case basis. E.G. I have x days to solve y problem, and there is already a similar library in Z language OR I have to write my own and it will take G amount of time.

That all said though, I still would not run to C as my go-to "need to get shit done fast" language... FWIW, I feel that other languages have libraries that are built for this purpose. I'm not saying those are "better." And as I said before, I know that you, Andrew, Casey, Martins, and many other folks here have more experience with C than me and could probably bang something out in C a lot faster. But hey, I'm 28, I love C, I love x64 assembly, and I love coding so life's good. :)

I also appreciate the video. I love all videos related to C and learning everyone's ideas. That's why I'm proud to be a member of this community.