C for high level programmers (slides) • Hacker News Board

Re: C for high level programmers (slides)

#121

Post by TheAceOfHearts » Mon, Jun 01, 2015, 3:38 PM UTC

voltagex_ wrote: post #50

kibibu wrote: post #33

Earlier quoted context omitted.

Javascript has the same problem, but I think its worse. At least there are platform standards in C (autotools in GNU, msbuild on Win). Trying to figure out how Grunt/Gulp/Broccoli, LESS/SASS/Stylus/Jade, Coffeescript, Uglify, Bower, Browserify, Require.js, AMD/CommonJS, NPM etc all work together is a nightmare. It's all too hard, so people added Yeoman, Brunch, or other things to generate application configs - but no…

Yep. I'm more comfortable with Make than I am with JSPM/NPM and System.js. The process to minify my javascript and CSS and then replace the paths in the HTML so my pages actually work seems to be needlessly complex. I'm seriously considering whether I can use Make for my production website builds - the only issue is Windows support.

Try out webpack. Webpack makes handling all of your assets into something trivial. I converted around 3,000 lines of Gulp files into a 200 line webpack config. (Most of which ended up being alises, and this is a reasonably big project.)

For an example of what makes it so awesome:

var img = require('./foo.png') // "/output-path/0dcbbaa701328a3c262cfd45869e351f.png"

Webpack will copy this file (foo.png) to your output folder, and rename it using the file hash, so it does cache-busting.

You don't need to use other build tools, you can just use the webpack CLI. I personally use npm scripts.

Webpack also allows you to setup aliases for modules, as well as load pretty much anything you can imagine. You wanna pull in a module that doesn't use CommonJS and instead exports a global? Webpack has global-loader. AMD is supported as well.

Oh, and this includes a sane development environment, with reload on save, as well as hot loading assets that support it. (Check out react-hot-loader: http://gaearon.github.io/react-hot-loader/, but it works with css as well.)

And you can require css files in your components, and then add the extract-text-webpack-plugin so it'll rip the css from the generated JS bundle!

Aaaaand it handles SourceMaps, so you don't have to worry about some plugins (looking at you gulp) not playing well together.

Finally, it also handles minification, either through a CLI option or in the config.

Re: C for high level programmers (slides)

#122

Post by TheAceOfHearts » Mon, Jun 01, 2015, 3:41 PM UTC

WalterBright wrote: post #30

TheAceOfHearts wrote: post #27

I think the problem with learning C is that you need to learn stuff like make, autoconf, how the compiler + preprocessors work (what do all those flags even mean!?), how making "cross-platform" stuff works, how to pull in and use "libraries", C-isms, how to test, etc. C itself is a very small and simple language, but the tooling and patterns are old and mysterious. In college I learned how to program embedded systems…

I never found C's transition from source code to hardware to be confusing. I struggle to comprehend why so many people, some longtime professional programmers, have trouble understanding what a linker does. On the other hand, I downloaded the CUDA SDK. I couldn't even figure out where the GPU compiled code even resided. I suppose I was just supposed to take it as it "just works" (and it did), but it all left me highl…

The OS is big and scary. When you're working directly with the metal, it's SUPER simple, there's no magical abstractions. But when you're using libraries and doing system calls you don't really know what's going on. Sure, you can dig into em sometimes, but it's more than a bit daunting.

Re: C for high level programmers (slides)

#123

Post by charlesL » Mon, Jun 01, 2015, 4:14 PM UTC

clarry wrote: post #118

pjc50 wrote: post #107

Earlier quoted context omitted.

As benwaffle says in adjacent comment, make is the 80% solution that works most of the time. Autoconf is the 100% solution that's supposed to work everywhere , no matter how weird or long-dead your UNIX is. In order to do that it does a vast number of compatibility tests. The result is complex enough that simple substitution of makefiles doesn't quite cut it. Of course, that imposes the cost of 100% compatibility on…

> Autoconf is the 100% solution that's supposed to work everywhere > Of course, that imposes the cost of 100% compatibility on every developer, when most would be happy to just build on today's Linux and call it a day. The reality is that when you use programs built with autotools on systems that aren't mainstream, you'll have troubles. Because the scripts aren't right and were only tested by Linux developers on Linu…

> And much of the time, I find it faster and easier to fix a broken makefile than to fix broken autohell.

Exactly. 99% of the time, a broken makefile simply has an incorrect linker path or cflag. When it's not a path, the Makefile is structured in a way that makes sense and is easy to fix. If an autoconf project is broken, I just scrap it and don't even bother trying to build it.

The other issue with autoconf is that it's not standardized. So many of the autoconf projects I've seen have shell scripts (to install it or download deps) mixed in that only add more confusion. Some of them have a configure script. Some have a configure.in, so you have to generate the configure yourself.

100% of the makefiles I've seen have a build, install and clean task. Sure, it's not required, but everybody does it. You can't say the same for autoconf.

Re: C for high level programmers (slides)

#124

Post by 72deluxe » Mon, Jun 01, 2015, 4:46 PM UTC

chrixian wrote: post #16

The thing about pointers that I don't get is why do you need the memory address of the variable? Is that the only way to get the value when you want it? Like, every variable has to have a pointer in order to make use of the variable?

Speaking from a C++ perspective, the item pointed to may not be a simple type (like an integer) but a complex object.

Copying an object around all over the place (into functions, out of them) would be expensive. It would be like copying an entire ledger every time you wanted to make a change to the ledger. Far better would be to hand the ledger around, or when looking for it ask "where is it?" and be pointed to where it is now.

It also makes it simpler to make sure all your data is in one place, which is a good thing for program design.

Re: C for high level programmers (slides)

#125

Post by 72deluxe » Mon, Jun 01, 2015, 4:47 PM UTC

velox_io wrote: post #44

This is why I like C# so much, you can go from LINQ & generics to pointers. So much versatility.

I remember someone using LINQ to do fancy things on the results of an SQL query. It was stupid. Far better would be to have written the SQL properly in the first place, instead of grabbing loads of data and doing cartwheels client-side.

LINQ is neat, of course.

Re: C for high level programmers (slides)

#126

Post by inglor » Mon, Jun 01, 2015, 6:10 PM UTC

nemo wrote: post #117

Sacho wrote: post #97

Earlier quoted context omitted.

I think the parent was correct. In your explanation you even state "an interpreter which typically...". You talk about compilers and interpreters, which aren't part of the language. The way you describe it, compiled or interpreted is a transitive property of a language, based on a popular way to utilize it. If the definitions are "inherently a little muddy", then they're not very useful. Javascript and compile-to-JS…

I think the slide was correct in expressing the idea it wanted to express using terms that are commonly used in the sense they used, while the parent was being pointlessly pedantic in wishing the terms had some strict sense that was the only true definition. Sometimes terms do have very strict definitions that are only correctly used in a limited sense. In the case of compiled vs. interpreted that's not the way thing…

No, seriously. All the lecture had to say to be correct and at least as useful is that C requires a build step unlike a lot of high level languages which don't.

Nothing about compilers vs interperters, none of that is relevant and the fact it's totally - incorrect is just icing.

This is not a terminology debating society, you're welcome to look up the definitions on wikipedia or take an introductory CS course if you're not sure what a compiler is or the difference between a language and a compiler/interpreter for it.

Re: C for high level programmers (slides)

#127

Post by fao_ » Mon, Jun 01, 2015, 6:11 PM UTC

pjc50 wrote: post #86

NhanH wrote: post #47

Earlier quoted context omitted.

Interestingly, I first started with C (although I haven't written a line of C code for a long time), and when I first move to higher-level languages, I dislike the fact that I have no idea where the file I just imported is. Moreso when I'm playing with obscure/ new language: if I can just import whatever files I wanted (rather than at package level), it seems that would be much easier to hack on the language/std itse…

I have no idea where the file I just imported is A sufficiently long include path can give you this problem anyway. I recently tripped over this when I created a "reason.h" and discovered that Windows had a file of the same name deep inside MFC.

I recently tripped over this when I created a "reason.h" and discovered that Windows had a file of the same name deep inside MFC.

It is my understanding that that would be solved by placing your file in a local directory called 'inc/' and having:

  #include "inc/reason.h"

instead of:

  #include

(or just replacing "" with ). But I have never programmed in VSC before, so I may be wrong.

Re: C for high level programmers (slides)

#128

Post by nemo » Mon, Jun 01, 2015, 7:20 PM UTC

inglor wrote: post #126

nemo wrote: post #117

Earlier quoted context omitted.

I think the slide was correct in expressing the idea it wanted to express using terms that are commonly used in the sense they used, while the parent was being pointlessly pedantic in wishing the terms had some strict sense that was the only true definition. Sometimes terms do have very strict definitions that are only correctly used in a limited sense. In the case of compiled vs. interpreted that's not the way thing…

No, seriously. All the lecture had to say to be correct and at least as useful is that C requires a build step unlike a lot of high level languages which don't. Nothing about compilers vs interperters, none of that is relevant and the fact it's totally - incorrect is just icing. This is not a terminology debating society, you're welcome to look up the definitions on wikipedia or take an introductory CS course if you'…

You're right that if the slide said C requires a build step unlike a lot of high level languages it would be correct. The terms "interpreted language" and "compiled language" have a sense in normal usage that I described, and I just verified that Wikipedia doesn't agree with you. There are no standards bodies that define formal definitions for those terms, common usage is how they are defined. All this is pointless pedantic quibbling, though, so it wasn't really worth my time, nor is it worth yours, really.

Re: C for high level programmers (slides)

#129

Post by ndesaulniers » Mon, Jun 01, 2015, 7:39 PM UTC

iyn wrote: post #116

ndesaulniers wrote: post #82

Earlier quoted context omitted.

My recommendations (I've read a lot of C books), I think you can get away with just these two: * Head First C - David Griffiths * Expert C Programming: Deep C Secrets - Peter Van Der Linden

Thanks for recommendations. BTW: just want to say that you have a fascinating blog! I've just spent last hour only skimming through some of the articles and bookmarking them for later. (Link for the lazy: https://nickdesaulniers.github.io/ )

I wrote it for readers like you!