C is syntactic sugar over ASM
Really? I forgot the sugar for registers in C, can you remind me?
C for high level programmers (slides)
91–100 of 129 posts
Re: C for high level programmers (slides)
#92I was hoping this would actually tell me how to accomplish something in C. I know all about pointers and memory, but I don't know anything about the current state if C development. What libraries do people use? What are common memory management strategies? Etc.
This depends so much on what you're doing. You get entirely different answers for embedded systems, UNIX, Windows, games, and so on.
Re: C for high level programmers (slides)
#93C is a horrible language to write a compiler in. The other reasons for `Why you should learn C' are better, though.
Why? Compilation times are quite important, and writing a fast compiler is easier to achieve in C than in most other languages.
Re: C for high level programmers (slides)
#94I misread the title as "C for high level programming" and was a bit confused. Of course, long time ago, C was considered a HLL.
The presentation is quite good. I might point people to it in the future so they might at least have an idea in what dangerous place they want to venture.
Re: C for high level programmers (slides)
#95Why do presentations always get interpreted vs compiled wrong? It's not a property of a language it's a property of the runtime. For example Java is interpreted on old versions, JIT compiled on the desktop and compiled AoT in Android...
Compiled vs. interpreted is intended there to mean something a little different than runtime behaviors.
Compiled - source files are run through a compiler which produce some output file that's then run. With C or Java you run the .c or .java file. C compiles to an executable, Java compiles to byte code.
Interpreted - source is fed to an interpreter which typically turns it into some kind of representation that's immediately run with no intermediary step on the part of the user/programmer. Perl, PHP, Ruby, Python, JS, TCL, etc. are typically run this way.
The terms are inherently a little muddy, since you can compile some interpreted languages to bytecode (common in PHP, and how JRuby/Jython are often run), and in theory could write a dynamic loader for C / Java to run them as interpreted - no idea if someone has been so perverse as to do it.
The behavior of a JRE or other runtime in loading bytecode/whatever to execute - JIT, AOT, or whatever has to do with how a runtime handles bytecode that's already been compiled from source and turns it to machine code to execute. The terms show up there also, but have a different meaning.
That's not what people are typically discussing when they talk about a compiled vs. interpreted language, and the author was correctly using the terms when referring to languages to draw the distinction in what a developer does (rather than what a runtime does, which is basically irrelevant to C).
Re: C for high level programmers (slides)
#96command line utility development, writing a replacement to systemd Those don't require direct use of C, necessarily - but rather some form of FFI to POSIX and the syscall interface. Hell, if one is writing a systemd replacement, I'd encourage use of OCaml. It'd spare you lots of boilerplate because you're writing relatively high level userspace logic, anyway.
Huh, I've never actually heard of using OCaml for system programming. Interesting!
Red Hat's Richard Jones (who is also often commenting on Hacker News) does a lot of system programming in OCaml (mostly VM management-related I think):
Re: C for high level programmers (slides)
#97Why do presentations always get interpreted vs compiled wrong? It's not a property of a language it's a property of the runtime. For example Java is interpreted on old versions, JIT compiled on the desktop and compiled AoT in Android...
Compiled vs. interpreted is intended there to mean something a little different than runtime behaviors. Compiled - source files are run through a compiler which produce some output file that's then run. With C or Java you run the .c or .java file. C compiles to an executable, Java compiles to byte code. Interpreted - source is fed to an interpreter which typically turns it into some kind of representation that's imme…
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 languages have a ton of compilers written for them. Does that make them compiled or interpreted languages? How popular does compiling a language have to be for it to become compiled instead of interpreted?
It's no wonder that the parent prefers the strict definitions which lack this ambiguity.
Re: C for high level programmers (slides)
#98I 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…
Frankly, I don't use a lot of crazy libs or IDEs when writing C code. Most of my projects consist of one or two external libs and a few simple makefiles. I use Vim and clang/gcc for compiling and lldb/gdb for debugging.
As for compiler flags, the only ones I ever worry about are `-O`, `-g`, `-c`, CFLAGS and LDFLAGS.
What I've learned is that the way C includes other files/libs is extremely simple. The header files are simply a simple mapping of the code in the `.so` or `.a`. If it's a n `.so`, you can't make it a static executable and if it's `.a` you have to.
I've never worked directly with low-level microcontroller programming, and the extent of my electronics knowledge is some fiddling with arduino. When I did that I used ino (http://inotool.org/) to compile and upload code to the board.
EDIT:
Projects that have good C code include: http://suckless.org/ and the linux kernel (and other stuff by Linus Torvalds). Avoid anything with GNU (most of it's over-engineered)
Re: C for high level programmers (slides)
#99Earlier 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…
I'm a C guy, and I never "worry" that if I have to recompile a project I worked on 1 or 2 years ago that I'm going to have to fight the toolchain to get it going again. Make will be make, and it will work. I have a huge concern when I do anything in Javascript about what happens in 1 or 2 years from now when I have to modify a project I built using some Yeoman scaffolding. Is it still going to work? Will those node m…
I don't understand. You can configure your node module to use specific versions of libraries just like a C project. Surely you've heard of problems people have with dynamic linkage and their programs not working? This is why distros spend so much time getting things to work with each other - I think you're just sweeping that under the rug.
The tools you're working with aren't different on this manner - it's not like your tool will magically recode itself to work differently.
Re: C for high level programmers (slides)
#100I 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 reccomend "Programming in the UNIX Environment" by Kernighan and Pike. Partly because it was written so soon after UNIX and C themselves, it has very little of the modern 'cruft' in it. It's at the level of "cc program.c -o program". Make is fairly easy to learn, at least in its basic form. Autoconf is horrendous.
> Make is fairly easy to learn, at least in its basic form. Autoconf is horrendous.
I completely agree. Make is extremely flexible on it's own. I don't understand the need to abstract the build system to generate thousand-line makefiles that are impossible to hand edit.